Usuari:DavidPalominoDuran/proves
 |
Aquesta és una pàgina de proves de DavidPalominoDuran. Es troba en subpàgines de la mateixa pàgina d'usuari. Serveix per a fer proves o desar provisionalment pàgines que estan sent desenvolupades per l'usuari. No és un article enciclopèdic. També podeu crear la vostra pàgina de proves.
Vegeu Viquipèdia:Sobre les proves per a més informació, i altres subpàgines d'aquest usuari |
"Fer proves amb la filosofia de les metodologies àgils.
Filosofia[modifica]
Comparat amb el desenvolupament de programari tradicional, les metodologies està destinat 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 perdria molts diners. Els diversos anys d'experiència han ajudat a donar forma a les metodologies àgils.
Adaptatiu contra Predictiu[modifica]
Les metodologies de desenvolupament existeixen en un continuu des de adaptatiu fins a predictiu.[1] 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ò dona 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 més 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 nomes serà capaç d'informar de l'objectiu principal, o una predicció aproximada de cost que tindrà.
D'altre 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.
Es pot fer un anàlisi dels riscos que a l'hora de triar entre els mètodes predictius i els adaptatius[2]. En Barry Boehm i en Richard Turner diuen que cada metodologia es pot escollir en funció d'unes característiques.
| 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 |
Desenvolupament iteratiu i Desenvolupament en cascada[modifica]
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 desenvolupament en cascada, hi ha una etapa de testejament quan s'esta acabant una de les fases d'implementació, mentre que, en les metodologies àgils i especialment en la Programació Extrema, es realitzen de forma paral·lela amb el desenvolupament del codi.
Degut a 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 desicions 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 i quan el programari s'utilitzi, i especialment si té competència, les iteracions en el desenvolupament àgil aportarant canvis.
Codi i documentació[modifica]
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ó"[3].
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.[4] Scott Ambler diu que la documentació haurià de ser amb prou feines acceptable (de l'anglès Just Barely Good Enough (JBGE)[5], ja que molta documentació serià una perdua de temps, degut a que habitualment els desenvolupadors no se'n refien d'una documentació molt detallada, perquè normalment no està sincronitzada amb el codi[4], d'altra banda molt poca documentació o una molt probre pot donar problemes per manteniment, comunicacio, aprenentatge, etc.
- ↑ Boehm, B. Balancing Agility and Discipline: A Guide for the Perplexed. Boston, MA: Addison-Wesley, 2004. ISBN 0-321-18612-5. Appendix A, pages 165–194
- ↑ Sliger, Michele; Broderick, Stacia. The Software Project Manager's Bridge to Agility. Addison-Wesley, 2008, p. 46. ISBN 0-321-50275-2.
- ↑ Rakitin, Steven R. «Manifesto Elicits Cynicism: Reader's letter to the editor by Steven R. Rakitin». IEEE Computer, vol. 34, 2001, pàg. 4. «The article titled 'Agile Software Development: The Business of Innovation' . . . is yet another attempt to undermine the discipline of software engineering . . . We want to spend all our time coding. Remember, real programmers don’t write documentation.»
- ↑ 4,0 4,1 Scott Ambler. «Agile/Lean Documentation: Strategies for Agile Software Development».
- ↑ Scott Ambler. «Just Barely Good Enough Models and Documents: An Agile Best Practice».