El bloc de Scrum.cat

Wed

07

May

2014

DevOps, acabant el que Agile va començar

El dimecres 30 d'abril es va fer una sessió a la Facultat d'Informàtica de Barcelona, organitzada per FIB Alumni, on es va parlar de DevOps com la "continuació de agile". Podeu veure aquí les transparències i el video.

0 Comments

Fri

28

Mar

2014

eduScrum - Utilitzant Scrum per l'aprenentatge

A Holanda s'ha creat eduScrum, una metodologia d'ensenyament i aprenentatge que segueix el model de Scrum. Bàsicament, el professor actua com Product Owner i marca els objectius d'aprenentatge (ítems) de un Sprint (p.e. una setmana). A partir d'aquí, els estudiants tenen la llibertat de triar quines tasques utilitzaran per aconseguir aquests objectius.

 

Aquesta metodologia inclou l'ús d'eines com la Definició de Fet (DoD) i la Definició de Divertit per facilitar la independència dels estudiants i l'eficàcia de l'aprenentatge.

 

Ho podeu consultar a: http://eduscrum.nl

 

Algú s'anima a traduir la guia al català? :-)

0 Comments

Fri

22

Nov

2013

Deute tecnic: 11 estrategies per lluitar-hi

0 Comments

Wed

23

Oct

2013

AWS Summit 2013 - Barcelona

Amazon farà una sessió demà 24 d'octubre on mostrarà la seva infrastrura Amazon Web Services, un recurs popular quan es tracta de desenvolupament àgil i de crear infraestructures de manera dinàmica.

 

Aquí teniu l'agenda.

 

8:30am to 9:30am - Registro | Welcome Coffee | Partner Expo

9:30am to 11:00am - Ponencia inaugural: Un Paseo por la Nube: El Cloud por AWS

11:00am to 12:00pm - Seguridad y cumplimiento de normativas en el Cloud

12:00pm to 13:00pm - Cloud Híbrida y Aplicaciones empresariales en AWS

13:00pm to 14:30pm - Almuerzo | Partner Expo

14:30pm to 15:30pm - Back up y recuperación de desastres

15:30pm to 16:30pm - Continuos Deployment

16:30pm to 17:30pm - Big Data & Análisis de Datos

17:30pm to 18:30pm - Cóctel de clausura | Partner Expo

7 Comments

Thu

22

Aug

2013

Gestio del deute tecnic

El concepte de deute tècnic no és gens nou, ha existit durant molt de temps amb altres noms (p.e. cost de la no-qualitat). L'interessant d'aquest nom és que, segons la meva experiència, capta molt millor l'atenció dels directors, caps i altres rols no tècnics que prenen decissions sobre els projectes de software.

 

El concepte consisteix en les eventuals conseqüències d'usar arquitectures i dissenys deficients (decisions tècnicament incorrectes) o de seguir pràctiques dolentes de desenvolupament de software ("treballar malament"), usualment materialitzades en el treball pendent que pot quedar "submergit" en un moment donat, però que s'haurà de realitzar (pagar) per poder acabar el projecte. El fi del projecte no significa liquidar el deute, doncs el manteniment de qualsevol producte amb deute tècnic s'encarirà notablement, a més de deixar una mala imatge de l'equip o de l'empresa que va fer el projecte.

 

Per una banda, les conseqüències més típiques de tenir un projecte amb deute tècnic són:

  • Endarreriments amb els lliuraments (la planificació es deixa de complir en quant emergeix el deute tècnic)
  • Productes amb qualitat dolenta per l'usuari (visible) i per aquells que l'han de mantenir (invisible).
  • Major cost de manteniment i cost total de la propietat (TCO).
  • Desmoralització de l'equip i excesiva rotació del personal.


Per altra banda, els motius més freqüents del deute tècnic poden ser:

  • Una mala planificació o pressions per avançar en el projecte sense escoltar els criteris tècnics.
  • Manca de metodologia i de comunicació a l'equip (o entre equips).
  • Males pràctiques com el "hardcoding" o els components altament acoblats.
  • Manca de proves unitàries i de proves automàtiques de regressió.
  • Manca de documentació i proves automàtiques de regressió.
  • Molts altres.


També cal tenir en compte que el deute tècnic pot tenir altres característiques:

  • Conscient: p.e. no fer proves unitàries per arribar a fer una demo interna a temps (però es faran immediatament desprès)
  • Inconscient: p.e. no fer proves unitàries perque endarrereix el projecte (fins que apareguin més errors que probablement seran més cars de solucionar).
  • De curt termini: p.e. no documentar per arribar a una fita urgent (reunió amb un altre equip) però que es liquidarà en breu.
  • De llarg termini: p.e. desenvolupar una capa de persistència per Oracle 11g només perquè no s'espera usar una altra BD en producció.

El tema dóna per molt i és millor no eternitzar-se. Podeu consultar una 

presentació molt bona del Steve McConell.

 

Espero poder presentar sobre aquest tema a la Barcelona Developers Conference 2013. Si el tema us sembla interessant, voteu-me si us plau! :-)

0 Comments

Thu

08

Aug

2013

Nova Guia Scrum, edició juliol 2013

A finals de juliol va aparèixer la revisió de la guia oficial a Scrum en anglès, que actualitza la que es va publicar el 2011. Les guies s'aniran traduint progressivament a la web: http://www.scrumguides.org

 

Els canvis són poc significatius, bàsicament:

  1. Es reforça el concepte de necessitat de transparència als artefactes del projecte i del Sprint, com a base per a la comunicació i predictibilitat.
  2. La planificació del Sprint es considera un event formal, amb les mateixes dues parts de definició funcional (requeriments) i tècnica (definició del disseny i de les tasques).
  3. Es canvia el verb per la definició progressiva del Sprint de "grooming" a "defining". També s'identifica l'estat "Ready" com aquell que té un ítem del Backlog per passar a un Sprint.
  4. Es reforça igualment el concepte de "Timebox" com temps màxim recomanat per a les reunions del Sprint, tot i que s'explicita la possibilitat de superar aquest límit si "raonablemenet" no s'arriba a temps a l'objectiu de l'event.
  5. Les preguntes del Daily Scrum incorporen el concepte de la "meta del Sprint": Què vaig fer ahir / que faré avui que ajudi a l'equip a arribar a la meta? Quins impediments té l'equip per arribar a la meta?
  6. Durant la revisió del Sprint s'emfatitza la intenció d'identificar el valor de la feina feta o de la que queda pendent, sempre prenent com referència els objectius del projecte.

 

De moment la guia de Scrum en català no s'ha actualitzat i té la bandera d'Hungria!!! Ja us avisarem en quan estigui traduïda.

 

Bon estiu!

Scrum.cat

1 Comments

Fri

24

May

2013

Tres opcions de contractacio agil

Per moure’s cap a un procés iteratiu o incremental d’execució dels projectes requereix repensar no només les pràctiques del desenvolupament del projecte sinó també el marc legal que les dóna cobertura.

            Com probablement ja sabeu, els contractes tradicionals són inflexibles per definició amb l’intenció de desplaçar l’exposició al risc en una relació amb interessos oposats. Els proveïdors estan obligats a complir la data i cost independentment dels obstacles que es trobin al projecte, mentre que als se’ls disuadeix de proposar canvis al mig del projecte (independentment del seu sentit) obligant-los a seguir farragosos processos de gestió de canvis.

            Òbviament, això és l’antítesi del desenvolupament àgil de software que es basa en una relació d’estreta col·laboració entre el proveïdor i el client que promou una compartició del risc amb opcions flexibles per facilitar els canvis a la vegada que es controla l’abast.

            Els següents models de contractació són un pas intermig cap a aquest ideal; replantegen les relacions entre proveïdor i client donant-li al client opcions per controlar l’abast i els costos com a contrapartida per establir un pacte que permeti seguir les regles de Scrum, fet que és beneficiós mútuament. En el cas dels models del Mitch Lacey de Marges i Canvis, els riscs i el coneixement latent es tracten en un projecte exploratori curt de dues setmanes que doni peu a un projecte àgil amb uns Product Backlog i Release Plans preliminars.

 

Podeu veure l'article complet aquí.

 

0 Comments

Wed

17

Apr

2013

El CodingDojo

El CodingDojo és una tècnica àgil consistent en aprendre dels altres mentre es codifica un problema, assegurant que tothom segueix el ritmoe i que el codi funciona. 

 

En aquest article de CodingDojo.org s'explica amb detall els requeriments, dinàmica i dos estils de CodingDojo, els PreparedKata i els RandoriKata.

0 Comments

Mon

15

Apr

2013

La guia de Scrum en 1 pagina

La guia de Scrum en 1 pàgina és un senzill poster (A4) que conté tots els elements bàsics per tenir Scrum (i altres pràctiques d'agile) reunits en una única pàgina.

 

Pot ser útil per aquells que no coneixen encara Scrum i volen una introducció ràpida, però com tot allò ràpid... incomplet! :-)

 

0 Comments

Thu

04

Apr

2013

La definició de fet (Definition of Done)

Article original al bloc Thinking-in-process de l'Àlex Ballarin.

 

Una visió superficial de Scrum pot donar a pensar que és una metodologia senzilla i desestructurada, pràcticament el mateix que mantenir una llista de tasques en una pissarra. És cert que Scrum és un marc de treball senzill, amb 4 events, 3 rols i 2 artefactes estàndard, però tot i així els projectes acostumen a sortir amb un grau alt de qualitat i d’uniformitat, tant a nivell tècnic com de documentació generada. No sembla contradictori? Un aspecte important a tenir en compte és la Definició de fet (Definition of Done).


Què és la Definició de fet?

La Definició de fet és un acord d’equip que conté totes les condicions que han de complir els ítems del Product Backlog que s’accepten al Sprint per considerar-los complets. Inclou els aspectes tècnics, de documentació, de proves i d’altres, de manera comuna per tot l’equip.


Cada equip crea i manté la seva pròpia Definició de fet, que acostuma a evolucionar i refinar-se tal i com l’equip va integrant, perfeccionant i automatitzant les seves pràctiques de desenvolupament. El moment habitual per revisar el cumpliment de la Definició de fet i refinar-la és la reunió de retrospectiva. Scrum no té auditories, és l’equip qui autogestiona la seva qualitat.


Quin és el valor de la Definició de fet?

El valor autèntic de la Definició de fet és el de garantir que la feina es realitza amb un nivell de qualitat uniforme, independentment del membre de l’equip que se’n faci càrrec. És l’equivalent a l’assegurament de la qualitat de la gestió de projectes tradicional.

La Definició de fet ha d’augmentar la seva exigència en tot moment d’acord a les possibilitats i capacitats de l’equip. No té sentit marcar definicions ambicioses que l’equip no pugui complir. El més important és la uniformitat i la regularitat.


Quin pot ser un exemple de Definició de fet?

Un exemple senzill i inventat pot ser el següent:

Cada història d’usuari feta ha de cumplir les següents condicions,

  1. Disseny de pantalles (wireframe) actualitzat a la wiki
  2. Test unitari Junit integrat al muntatge (Jenkins) i superats
  3. Peer-review de les proves funcionals superades
  4. Codi font documentat
  5. Wiki de disseny actualitzat
  6. Disseny explicat a la reunió tècnica setmanal

Com es pot comprovar, la senzillesa de Scrum no té relació amb la quantitat ni qualitat de les bones pràctiques de desenvolupament que un equip pugui realitzar.

 

0 Comments