Am folosit SCRUM în trei proiecte diferite în ultimii patru ani. Unul dintre avantajele SCRUM pare să fie flexibilitatea și adaptabilitatea sa, de exemplu, la schimbarea cerințelor clienților. Un alt avantaj este că managementul poate urmări cu ușurință progresul unui proiect.
Flexibilitatea SCRUM poate fi un avantaj de exemplu atunci când implementează o aplicație web, în care cerințele se schimbă foarte repede și clienții înțeleg cu adevărat ce vor după ce au văzut un prototip.
Pe de altă parte, există alte tipuri de proiecte software (de exemplu, în domeniul aerospațial industrie) în care cerințele sunt destul de fixe: primiți un document de specificație a cerințelor și trebuie să reveniți șase luni mai târziu cu software de lucru și documentație completă. Pentru acest tip de proiecte mă îndoiesc că este necesară flexibilitatea oferită de SCRUM (în sensul că nu este nevoie să construiți prototipuri și să le arătați clientului pentru a obține feedback cu privire la cerințe): mai degrabă aveți nevoie de o abordare foarte structurată și sistematică, care se repetă probabil de fiecare dată pentru fiecare proiect, cu puțin spațiu pentru surpriză.
Deci, SCRUM este considerat de susținătorii săi o metodologie de dezvoltare software cu scop general sau este considerat adecvat în special pentru anumite categorii de proiecte sau domenii de aplicații?
de exemplu, m-am uitat recent la site-ul web al unei companii producătoare de software pentru industria aerospațială și am observat că utilizează modelul V. Un susținător al SCRUM ar spune că SCRUM este mai puțin potrivit pentru acest tip de proiecte sau ar sugera mai degrabă că această companie ar trebui să încerce să treacă la SCRUM?
Notă că nu cer părerea cititorilor acestui forum, dar vreau să știu care este opinia stabilită în rândul proponentilor SCRUM: SCRUM este considerat de uz general sau mai degrabă potrivit pentru anumite clase doar de proiecte? În ultimele cazuri, pentru ce tipuri de proiecte?
Comentarii
- A se vedea stackoverflow.com / questions / 596916 / when-should-you-not-scrum și eweek.com/c/a/IT-Management/…
- Ca ” să obțină un document de specificare a cerințelor și trebuie să revii șase luni mai târziu cu software-ul de lucru ” lucru este un mit. Chiar și atunci când construiți ceva de genul unui compilator pentru un limbaj definit în mod formal (în care cerințele funcționale par a fi cu adevărat clare și fixe), trebuie să decideți și să acordați prioritate lucrurilor de implementat, există cerințe nefuncționale care trebuie discutate cu utilizatorul , și aveți mai multe grade de libertate pentru că unul trebuie să decidă cum să rezolve lucrurile. Deci, o abordare agilă are sens chiar pentru astfel de tipuri de proiecte.
- ” Deci, o abordare agilă are sens chiar și pentru astfel de proiecte. „: Deși agilitatea poate fi mai flexibilă, și alte metode sunt flexibile. Poate fi că alte metode sunt suficient de flexibile și agile sunt prea flexibile pentru anumite proiecte. Faceți doar brainstorming aici.
- ” Ca ” să primiți un document de specificare a cerințelor și trebuie să reveniți șase luni mai târziu cu software-ul de lucru ” lucru este un mit. „: Nu ‘ nu cred . În timp ce puteți schimba rapid eticheta unui buton pe o pagină web, deoarece clienții și-au schimbat părerea după ce au privit-o, nu puteți schimba la fel de ușor o parte critică a unui software avionic care controlează o parte în mișcare a unui avion. Poate că vor fi necesare modificări târzii, dar mă întreb dacă o metodă agilă este modalitatea corectă de a le gestiona sau dacă aveți nevoie de o iterație mai complexă a altei metode (de exemplu, modelul V).
Răspuns
SCRUM este o metodologie de uz general care poate funcționa bine pentru majoritatea proiectelor și a dimensiunilor echipei, dar este mai puțin utilă pentru echipele mari care fac foarte mari proiecte. Numărul mare de persoane implicate în unele proiecte face ca orice metodologie agilă să fie extrem de dificilă până aproape imposibilă, deoarece este necesară o structură mai rigidă pentru a menține ordinea. Industria aerospațială este un bun exemplu de industrie care tinde să aibă proiecte uriașe în care abordările agile nu sunt întotdeauna fezabile.
Comentarii
- Există orice informație cu privire la momentul în care un proiect este considerat prea mare pentru a putea fi realizat cu SCRUM? Luați în considerare, de exemplu, un proiect de 18 luni pentru o echipă de 15 persoane: ar beneficia o astfel de echipă de pe SCRUM sau s-ar potrivi și un alt model ca modelul V Motivul pentru care întreb este că peste 18 luni cerințele și implementarea au suficient timp pentru a se coace și a se stabiliza și poate că flexibilitatea oferită de SCRUM nu este cu adevărat necesară.Mai degrabă, aici este potrivită o abordare pe termen mediu-lung. Există vreo literatură în acest sens?
- @Giorgio timpul proiectului nu contează cu adevărat, dar 15 persoane sunt suficiente pentru a beneficia de scrumuri multiple grupuri, dar este încă în domeniul de gestionare pentru SCRUM. când managementul comunicării începe să devină un loc de muncă cu normă întreagă pentru echipa ta, este timpul să înceapă să caute un model V
- Vorbești serios? Înainte foloseam un model V și am trecut la SCRUM. De fapt, avem sentimentul că ‘ am devenit mai încetiși tocmai din acest motiv: prea multă contabilitate.
- @Giorgio, care ar fi adevărat pentru orice comutator, ești o să mă simt mai lent la început, pentru că este nou, așa cum Pierre 303 a spus că ai o idee mai bună după câteva sprinturi.
- @Giorgio – că ‘ este adevărat, o mulțime de metodologii ” agile ” sunt mai grele decât procesele grele pe care ‘ le presupun a inlocui! Evident, acest lucru înseamnă că ‘ greșesc – se presupune că agilitatea este ușoară și liberă și pare haotică pentru cei din afară. Înseamnă că echipa dvs. trebuie să fie foarte organizată și disciplinată, dar ‘ este, în general, un beneficiu. Încercați Crystal de la Alistair Cockburn (unul dintre fondatorii Agile).
Răspuns
Orice tip de proiect ! Funcționează bine atât pentru proiecte mari, cât și pentru proiecte mici.
Oamenii l-au folosit pentru a planifica nunți, mutarea unei case etc. Așadar, nici măcar doar proiecte software.
Sunt un credincios ferm că există multe operațiuni comerciale care ar putea beneficia de o abordare asemănătoare Scrum.
Comentarii
- Este opinia ta împărtășită de către propunători SCRUM, adică de autori care au codificat și promovat SCRUM?
- Da – a spus recent Cheryl Hammond ( blog.bsktcase.com ), consultant ALM cu Northwest Cadence la o discuție pe care a susținut-o intitulată ” A Scrum Masters Day In The Life: The New Visual Studio „. Puteți viziona aici: msevents.microsoft.com/CUI/…
Răspuns
Rețineți că Scrum nu este o metodologie, ci un cadru.
Scrum va funcționa cel mai bine într-un c ross-functional echipa de la 5 până la 9 dezvoltatori care lucrează la un proiect de dimensiuni medii
(de la 4 luni la mai mulți ani). Dacă proiectul dvs. este mai mare, puteți scala cu Scrum of Scrums .
Nu voi discuta aici despre aspectul transversal, ci aici ceea ce spune Ghidul oficial Scrum pentru dimensiunea echipei:
Dezvoltare optimă Dimensiunea echipei este suficient de mică pentru a rămâne agilă și suficient de mare pentru a finaliza lucrări semnificative. Mai puțin de trei membri ai echipei de dezvoltare scad interacțiunea și rezultă în creșteri mai mici de productivitate. Echipele de dezvoltare mai mici pot întâmpina constrângeri de abilități în timpul Sprint-ului, ceea ce face ca echipa de dezvoltare să nu poată livra un increment potențial eliberabil. A avea mai mult de nouă membri necesită o coordonare prea mare. Echipele mari de dezvoltare generează prea multă complexitate pentru ca un proces empiric să fie gestionat. Rolurile de proprietar de produs și Scrum Master nu sunt incluse în acest număr, cu excepția cazului în care execută și lucrările Sprint Backlog
Un sprint durează aproximativ o lună.
Sprinturile sunt limitate la o lună calendaristică. Când orizontul unui Sprint este prea lung, definiția a ceea ce se construiește se poate schimba, complexitatea poate crește și riscul poate crește. Sprinturile permit previzibilitatea asigurând inspecția și adaptarea progresului către un obiectiv cel puțin în fiecare lună calendaristică. Sprinturile limitează, de asemenea, riscul la o lună calendaristică de cost.
Cred că nu are sens să folosești un cadru bazat pe un proces iterativ cu proiecte mai mici mai mult de 4 luni. 4 luni = 4 sprinturi. De asemenea, trebuie să considerați că obțineți o viteză mai precisă după 3 sprinturi.
Acestea fiind spuse , Eu personal folosesc o versiune limitată de Scrum pentru proiecte mai mici. Dar nu poți să-i spui Scrum atunci. În acest caz particular, utilizați câteva principii de bază ale Scrum în propria dvs. implementare a cadrului.
Răspuns
pentru începători , gândiți-vă la SCRUM ca la un singur set de linii directoare pentru implementarea practicilor agile. Nu vă gândiți vreodată la aceasta ca la o „carte sfântă” a modului de realizare a proiectelor. Pentru multe proiecte în care este necesar un flux constant de sarcini, Kanbam este mai potrivit, de exemplu.
Proiectele Agile tind să cadă în cazul în care faceți proiecte care necesită o dată de încheiere fixă sau un cost fix. În timp ce puteți continua aceste proiecte folosind metode Agile, necesitatea de a planifica totul în față stabiliți dacă este probabil să atingeți ținta nu este un mod obișnuit de agil – în agilitate aveți tendința de a continua să lucrați până când rămâneți lipsit de lucruri de făcut sau nu aveți timp să faceți acest lucru. Pentru majoritatea proiectelor, acest lucru este ok deoarece cerințele se schimbă oricum în timpul proiectului.
Comentarii
- Modul în care ne simțim agili în echipa noastră este de a lăsa clientul să stabilească o prioritate pe povești (de la cel mai important la cel mai puțin important), estimăm poveștile utilizatorilor folosind cărți de poker și planificăm câte povești putem implementa până la termenul limită. Dacă ne dovedim a fi mai rapizi, programăm mai multe povești, în funcție de ceea ce urmează în lista de priorități.
- Am citit din nou răspunsul dvs. după câteva luni și este de fapt foarte luminos. +1