Equips de treball remots

Cal tenir en compte la varietat d’equips remots que poden estar treballant junts en un projecte des de diferents ubicacions. Hi ha socis, proveïdors, equips de vendes, equips de desenvolupament, etc… Cada projecte podria tenir-ne més o menys, pel que és crucial tenir una estratègia què asseguri que tots estan treballant junts.

Alguns problemes potencials quan els equips estan treballant de forma remota: No sentir-se part de l’equip, no contribuir esperant instruccions, predre la perspectiva del projecte, …

Si bé res reemplaça el diàleg cara a cara, hi ha recursos per resoldre els problemes inherents als equips remots: videoconferència, missatgeria instantania, … És important assignar en la planificació del projecte pressupost i temps a mantenir contactes individuals.

El talent s’ha expandit, i ara es pot aprofitar l’experiència de tot el món, pel que val la pena l’esforç extra per aprendre la gestió remota d’equips.

Alerta: Abans d’administrar el seu equip remot, cal contractar-lo. Aquesta és realment la primera fase de la seva estratègia de gestió. Calen membres de l’equip que tenen experiència en el treball a distància i han demostrat ser disciplinats per completar les tasques amb autonomia.

Waterfall

El model de desenvolupament en cascada en el context de l’enginyeria de programari és un procés de disseny seqüencial, d’ús freqüent en els processos de desenvolupament de programari, en què el progrés flueix constantment cap avall (com una cascada) a través de les fases de concepció, iniciació, anàlisi, disseny, construcció, proves, producció/realització, i manteniment. Aquest enfocament metodològic ordena rigorosament les etapes del cicle de vida del progamari, de tal manera que l’inici de cada etapa ha d’esperar la finalització de la immediatament anterior.

Un exemple d’una metodologia de desenvolupament en cascada és seguir aquests passos: Anàlisi de requisits, Disseny del Sistema, Disseny del Programa, Codificació, Proves, Implantació i Manteniment. D’aquesta manera, qualsevol error de disseny detectat en l’etapa de prova condueix necessàriament al redisseny i nova programació del codi afectat, augmentant els costos del desenvolupament. La paraula cascada suggereix, mitjançant la metàfora de la força de la gravetat, l’esforç necessari per introduir un canvi en les fases més avançades d’un projecte. Si bé ha estat àmpliament criticat des de l’àmbit acadèmic i la indústria, segueix sent el paradigma més seguit avui dia.

Metodologia àgil (Filosofia)

Comparat amb el desenvolupament de programari tradicional, la metodologia àgil està destinada a sistemes complexos amb projectes dinàmics, on fer prediccions acurades del temps necessari de desenvolupament és molt complicat. Com a conseqüència d’això es perdrien molts diners. Els diversos anys d’experiència han ajudat a conforma les metodologies àgils.

Adaptatiu contra Predictiu

Les metodologies de desenvolupament existeixen en un continu des d’adaptatiu fins a predictiu. Les metodologies àgils formen part de les adaptatives. Un dels elements clau del desenvolupament adaptatiu és l’anomenat Rolling Wave, el qual determina objectius, però dóna flexibilitat a l’hora d’aconseguir-les, aquests objectius també estan sotmesos a possibles canvis futurs. Com més lluny es trobi, en el temps, un objectiu, un desenvolupament adaptatiu serà més imprecís sobre el que passara en aquella data. Un equip que utilitzi desenvolupament adaptatiu no pot informar sobre que farà la pròxima setmana, però si quines funcionalitats implementaran al llarg del mes següent. Si a l’equip se li demana una predicció del que tindran fet al cap de sis mesos (o qualsevol quantitat considerable de temps) l’equip només serà capaç d’informar de l’objectiu principal, o una predicció aproximada de cost que tindrà.

D’altra banda, els mètodes predictius s’enfoquen en analitzar i planificar el futur amb detall per tal de poder controlar els possibles perills futurs. En els casos més extrems, un equip que utilitzi una metodologia predictiva és capaç de dir totes les tasques que es realitzaran al llarg del projecte. Aquestes metodologies es basen en una fase inicial d’anàlisi molt detallada, ara bé, si durant el desenvolupament alguna cosa va malament, serà molt difícil canviar la direcció del projecte. Normalment aquests equips tenen una junta de control de canvis, que s’assegurara que només els canvis més importants s’afegeixin al projecte.

Desenvolupament iteratiu i Desenvolupament en cascada

Una de les diferències principals entre el desenvolupament àgil i el desenvolupament en cascada és que la fase de testing es realitza en diferents etapes. En el Model de desenvoluament en cascada, hi ha una etapa de testejament quan s’està acabant una de les fases d’implementació, mentre que, en les metodologies àgils i especialment en la Programació Extema, es realitzen de forma paral·lela amb el desenvolupament del codi.

Com que les fases de testing es realitzen a cada petita iteració, els usuaris poden provar i validar aquesta petita peça del programari. Això permet que els usuaris puguin fer millors decisions sobre el futur d’aquest programa. Tenir a cada iteració del desenvolupament la possibilitat de replantejar el camí que seguira el programa (p.e l’Scrum té com a màxim iteracions d’un mes), permet a l’equip intentar màximitzar el valor que ofereix el programa.

Aquesta planificació iterativa permet veure el desenvolupament del programari com un organisme que es va adaptant als canvis que es van produint. Sempre que el programari s’utilitzi, i especialment si té competència, les iteracions en el desenvolupament àgil aportarant canvis.

Codi i documentació

En una carta al IEEE Computer, Steven Rakitin va expressar el seu cinisme sobre el desenvolupament àgil, criticant un article que defensava el desenvolupament àgil com “un altre intent de minimitzar la disciplin de l’enginyeria del programari”, i traslladant el “Treballar en codi per sobre la documentació” a “només volem escriure codi, recorda els programadors de veritat no escriuen documentació”.

Aquest aspectes són discutits pels defensors del desenvolupament àgil, que diuen que els desenvolupadors haurien d’escriure documentació si és la millor manera d’aconseguir els objectius rellevants, però que habitualment hi ha millors maneres d’aconseguir-los que escrivint una documnentació estàtica. Es diu que la documentació haurià de ser amb prou feines acceptable (de l’anglès Just Barely Good Enough (JBGE), ja que molta documentació serià una pèrdua de temps, perquè habitualment els desenvolupadors no se’n refien d’una documentació molt detallada, perquè normalment no està sincronitzada amb el codi, d’altra banda molt poca documentació o una molt pobre pot donar problemes per manteniment, comunicacio, aprenentatge, etc.

Metodologia àgil (el què)

Les metodologies àgils o processos àgils de desenvolupament de programari (com, per exemple, XP, Scrum, DSDM, Cristal, etc.) són aquelles metodologies de desenvolupament que es basen en l’adaptabilitat de qualsevol canvi com a mitjà per augmentar les possibilitats d’èxit d’un projecte.

La majoria dels mètodes àgils intenten minimitzar el risc desenvolupant el programari en iteracions, que típicament duren d’una a quatre setmanes. Cada iteració és com un projecte en miniatura del projecte final, i inclou totes les tasques necessàries per després implementar les funcionalitats noves: planificació, anàlisi de requisits, disseny, codificació, testatge, i documentació. Mentre que una iteració pot no afegir prou funcionalitats per garantir alliberar el producte, un projecte de programari àgil pretén ser capaç d’alliberar programari nou al final de totes les iteracions. En molts casos, el programari s’allibera al final de cada iteració, especialment quan el programari és basat en la web i es pot llançar fàcilment. Malgrat tot, al final de cada iteració, l’equip reavalua les prioritats de projecte.

Els principis bàsics de la metodologia àgil són:

  • Els individus i les seves interaccions per sobre dels processos i les eines
  • El programari que funciona per sobre de la documentació exhaustiva
  • La col·laboració amb el client per sobre de la negociació de contractes
  • La resposta davant del canvi per sobre de seguir un pla tancat

Metodologies de desenvolupament

El procés de desenvolupament de programari (o cicle de vida del desenvolupament de programari) és una part del desenvolupament de programari. Es defineix com una seqüència d’activitats que han de ser seguides per un equip de desenvolupadors per generar o mantenir un conjunt coherent de productes.

Es pot definir un procés com un marc de treball que ajuda el cap del projecte a controlar-ne la gestió i les activitats d’enginyeria. Això ajuda a establir el “qui fa què, quan i com” i un mecanisme de control per veure l’evolució del projecte.

Característiques de les metodologies
Mètodes àgils Mètodes predictius Mètodes formals
Poc crítics Altament crítics Extremadament crítics
Desenvolupament sènior Desenvolupament junior Desenvolupament sènior
Els requeriments canvien sovint. Els requeriments no canvien. Requeriments limitats.
Equips petits Equips grans Els requeriments es poden modelar
Cultura que respon al canvi. Cultura que demana ordre. Alta qualitat