Agile Experts vs Agile Manifesto

Crezi că „expertul tău local” a citit Agile Manifest? Ai? Ei bine, nu este o problemă ... dacă nu folosiți zilnic cuvântul „Agile”! Dar dacă o faci (sau expertul tău local face) ... ei bine - asta este ceva ca oamenii care vorbesc prea mult despre religie, dar nu au deschis Biblia (alertă de corectitudine politică) sau cartea sfântă la alegerea lor, încă din orele de literatură Acum 10 ani ... Nu ne plac. Pentru un motiv.

Ok, să nu comentăm alte persoane și părerile lor. Să trecem, în schimb, cu „Biblia agilă” pas cu pas.

Vor fi prezentate citate din Manifestul Agile

acest tip de bloc de text

iar comentariile noastre vor fi date în liniuță obișnuită ca aceasta. Sa mergem!

Manifestul, unul singur!

Cea mai mare prioritate a noastră este să satisfacem clientul
prin livrare timpurie și continuă
de software de valoare.

Aceasta este o idee atât de grozavă! A fost într-adevăr revoluționar în momentul în care a fost făcut! Dar executarea acestei idei este ceva mult mai greu decât ar fi putut percepe aceste câteva rânduri.

Problemă principală: Toți cei care au avut un contact direct cu clientul știu că acest punct al manifestului este cel puțin oarecum complicat.

Din păcate, clientul nu este întotdeauna sigur de ce dorește sau dorește prea multe lucruri în același timp și nu le poate da prioritate corect! Mai mult, s-ar putea ca unele dintre acele lucruri pe care le-a dorit clientul, mai târziu să nu vrea ...

Dacă lăsăm asta deoparte - punctul Manifestului își dovedește valoarea pentru succesul produsului! Dar aceste excepții NU trebuie neglijate, deoarece pot fi fatale!

Punctul următor acoperă ceva similar, să continuăm acest subiect acolo.

Bine ați venit la schimbarea cerințelor, chiar târziu
dezvoltare. Procesele agile se schimbă pentru
avantajul competitiv al clientului.

Asta e super. Însă pivotarea constantă și presiunea asupra echipei de dezvoltare fac ca produsul să fie fragil. Codificarea rapidă cu o mulțime de redirecționări ale proiectului face ca calitatea codului produsului să fie scăzută, astfel încât modificările devin mai dure. Dezvoltarea mai rațională și calmă îmbunătățește eficiența modificărilor în etapele ulterioare ale dezvoltării produsului. Suntem de acord că schimbările ar trebui să fie binevenite, dar și alte clauze contractuale / de acord ar trebui modificate proporțional! În multe cazuri, este de așteptat ca produsul să fie dislocat în același timp în care ar fi fost cazul în care nu există nicio cerință de modificări suplimentare. Nu rece.

Agilitatea este despre a fi gata pentru schimbările așteptate, și nu despre schimbarea tuturor și întotdeauna. Cei care sunt acreditați să comunice cu potențialul client / client ar trebui să negocieze de la bun început acordul realist. Adesea, 10 minute cu pix și hârtie la timpul potrivit (începutul proiectului) economisesc zile, săptămâni și chiar luni de dezvoltare (redirecționare, pivotare, schimbare) în etapele ulterioare! Această slăbire în pornirea produselor trebuie considerată neprofesională, pentru că este foarte mult! Mentalitatea „hai doar să obținem clientul, mai târziu ne vom gândi la ceva pentru a termina slujba” mentalitatea este lipsită de etică și, de cele mai multe ori, vine vorba de dezvoltatori să „salveze ziua” (lucrează ore suplimentare, lucrează în weekend, lucrează de acasă, lucrează în înconjurător stresant) ... Nu e fain. Și cu adevărat - nici măcar agil.

Livrați software de lucru
frecvent, de la a
două săptămâni până la câteva luni, cu o
preferință la termenul mai scurt.

Am doar experiențe bune cu acesta. Oferă posibilități de feedback timpuriu-testare-învățare-îmbunătățire a feedbackului. Lucruri grozave dacă conceptul Agile este aplicabil în dezvoltarea de software a tipului de produs necesar. (Nu întotdeauna este cazul, credeți sau nu.)

Oamenii de afaceri și dezvoltatorii trebuie să funcționeze
împreună zilnic pe tot parcursul proiectului.

Ok, poate nu zilnic, dar și - degetele în sus! Noi (oamenii) nu am reușit să-l distrugem în ultimii 15 ani ... Dă-ne timp.

Construiți proiecte în jurul unor persoane motivate.
Dă-le mediul și sprijinul de care au nevoie,
și ai încredere în ei pentru a termina treaba.

Acesta este locul în care majoritatea așa-numiților agiști nu reușesc să acționeze prin Manifest Agile. Adesea le lipsește respect față de persoanele care sunt, dacă nu sunt experți, profesioniști încă mai buni, având în vedere domeniul lor de expertiză, decât managerul de proiect „agil”. Acest lucru face ca managerul să se implice prea mult în munca altor oameni, ceea ce rupe „angrenajele” importante, unul câte unul. Reducerea agilității și fiabilității „mașinii” ulterioare pentru schimbare. Ceea ce este contrar.

Cea mai eficientă și eficientă metodă
transmiterea de informații către și în cadrul unei dezvoltări
echipa este conversația față în față.

Ei bine, nu putem spune nimic împotriva asta. Dimpotrivă, urât pentru asta!

Software-ul de lucru este măsura principală a progresului.

Da. Problema este că mulți dintre așa-ziși agiști nu respectă nici această clauză.

Procesele agile promovează dezvoltarea durabilă.
Sponsorii, dezvoltatorii și utilizatorii ar trebui să fie capabili
pentru a menține un ritm constant la nesfârșit.

Greu de realizat, dar bineînțeles - ghid excelent.

Atenție continuă la excelența tehnică
iar un design bun îmbunătățește agilitatea.

Din nou, din păcate, așa-numiții manageri de proiect agili deseori uită de acesta, ceea ce face consecințe grave, dacă nu fatale.

Simplitatea - arta maximizării sumei
a muncii nemaivăzute - este esențială.

Salutare, simplitate!

Cele mai bune arhitecturi, cerințe și proiectări
ies din echipele de autoorganizare.

Ave!

La intervale regulate, echipa reflectă modul în care
pentru a deveni mai eficient, apoi ajusta și ajustează
comportamentul său în consecință.

Amin!