Metodologia determină foarte mult: componența echipei, modul de interacțiune cu clientul, ordinea de lucru și multe altele.
Atunci când alegeți o metodologie, trebuie să înțelegeți și să explicați clientului că cerințele clientului pentru proiect se vor schimba. Și cu cât tehnica este mai dificilă, cu atât este mai dificil să se facă schimbări în cerințe. În primul rând, clientul nu poate cunoaște unele dintre cerințele sale, unele dintre cerințe se pot schimba în timp, acesta este un proces obiectiv. Prin urmare, dacă un client insistă asupra unui proces dificil, atunci ar trebui să fie pregătit pentru complicația și costul procesului de dezvoltare.
Alegerea metodologiei depinde de componența echipei disponibile studioului. Dacă clientul insistă asupra unui anumit proces, atunci va trebui să caute oameni pentru el.
Cu cât este mai disponibilă echipa disponibilă din punct de vedere profesional, cu atât mai flexibilă poate fi folosită metodologia. Pentru angajații cu o înaltă calificare profesională, puteți utiliza programe XP - extreme. Studenții de ieri din modul XP vor completa proiectul cel mai simplu. Pentru foștii studenți, cu cât procesul este mai formal, cu atât mai mult va fi lucrarea. Cu astfel de angajați va trebui să aplice cascada.
Echipa slabă și un dezvoltator puternic
În primul rând. Toate cele mai formalizate și simplificate. (Ce înseamnă aceasta în ceea ce privește utilizarea, de exemplu, Bitrix cadru. Utilizarea de componente standard, utilizarea unei părți administrative standard face totul pentru oameni cât mai puțin posibil a codului scris. Editați componente, șabloane, edita vorstku, setările de schimbare, nu mai mult.)
Al doilea. Construiți procesul de dezvoltare cât mai aproape de cascadă. Un angajat neexperimentat nu poate evalua corect complexitatea problemei și poate alege metode adecvate pentru rezolvarea ei. Pentru el, un dezvoltator experimentat ar trebui să picteze totul sub forma unui plan detaliat al proiectului cu o diagramă Gantt.
Proiectul este mai bine împărțit în iterații de lungă durată (2-3 luni) pentru a reduce riscurile. Prima etapă este crearea unui site cu aspect integrat bazat pe funcționalitatea standard. Adică, tot ceea ce poate fi realizat fără locuri de muncă complexe, prezentat clientului ca urmare a primei etape.
A doua etapă și etapele ulterioare sunt o parte a unui complex complex, de mare capacitate, de exemplu un catalog mare. Acesta este creat, testat, laminat pe făcute, predat.
Puterea medie a echipei
În acest caz, este posibilă o formalizare mai mică a procesului iterativ. Nu puteți face auditul de cod, puteți face mai puține sucursale de control al versiunilor, nu trebuie să specificați setările componentelor, modulelor, puteți face iterații mai scurte (aproximativ o lună și jumătate). Pentru astfel de echipe, RUP, Agile, Kanban este potrivit.
O echipă puternică de personal permanent este un caz rar. Fit toate tipurile de procese care trebuie să fie alese în funcție de proiect. Proiectele complexe și mari pot necesita o cascadă și o echipă puternică, dar în cele mai multe cazuri, o echipa puternica de lucru pe tehnologia XP, cu elemente Agile, sau integrarea continuă Scrum. Iterațiile se pot scurta, aproximativ 2-3 săptămâni.
Cum se estimează timpul necesar și complexitatea sarcinilor
Exactitatea evaluării depinde de calitatea designului și de calificările dezvoltatorilor. De regulă, tehnologia Planning Pocker este utilizată pentru evaluare.
Tehnologia este extrem de simplă: sarcina este anunțată, discutată, iar dezvoltatorii aruncă cărțile cu timpul necesar implementării acestei sarcini. Timpul de pe carduri este indicat în numerele Fibonacci.
O mare discrepanță în estimările calendarului indică slăbiciunea echipei sau o sarcină neclare. În echipele slab este mai bine să nu se efectueze o evaluare colectivă a timpului necesar, ci să se aibă încredere în opinia unui dezvoltator puternic. Managerul nu trebuie să evalueze complexitatea sarcinilor. În acest caz, programatorii pot da cod de slabă calitate, doar pentru a prinde liniile. Dar dacă dezvoltatorul este lipsit de scrupule sau viclenie, el va încerca să supraevalueze termenul. Managerul trebuie să ia în considerare acest risc.
La evaluarea sarcinilor Planning Pocker, managerul trebuie să fie sigur că sarcina este clară pentru echipă. În caz contrar, nu poate fi estimată corect. Va fi numit fie timp supraevaluat, de teama de a nu fi la timp, fie de subestimat, din cauza subestimării complexității. În ambele cazuri, calendarul va fi în pericol de eșec, iar calitatea performanței este scăzută.
Puteți aplica modificarea Planning Pocker. când dezvoltatorii evaluează sarcina după criteriul: Simple \ Medium \ Complicated. Dacă managerul are deja o estimare dezvoltată cât va dura o sarcină de fiecare tip.
Trimiteți-le prietenilor: