Metodologia Clară ca Cristalul
— Simplitate și Perfecțiune
pentru Aplicații de Afaceri

În 1991, Alistair Cockburn, unul dintre coautorii Manifestului Agile, și-a propus să creeze o metodologie eficientă pentru dezvoltarea software-ului. A cercetat numeroase echipe de proiect și a studiat cazurile lor de dezvoltare.

• Metodologiile orientate pe oameni sunt mai benefice decât cele orientate pe procese.
• Metodologia ar trebui să fie adaptată la proiectul și echipa individuală - nu există o metodologie universală de dezvoltare a aplicațiilor.

​​​​​​​​​​​​​​​​​​​​​​​​​​

În 1994, el a implementat aceste idei ca consultant principal într-un proiect cu cost fix în valoare de 15 milioane de dolari, cu un personal de 45 de oameni, numit "Orange." Principiile dezvoltate de Alistair au devenit fundația pentru succesul proiectului. El a documentat această experiență în cartea sa "Surviving Object-Oriented Projects" (1997) și un an mai târziu a dezvoltat familia de metodologii Crystal.

​​​​​​​​​​​​​​​​​​​​​​​​​

1. Livrare rapidă de cod util: Trecerea de la desfășurări mari și rare de cod la publicații mai mici și mai frecvente.
2. Îmbunătățire prin reflecție: Adunarea de informații despre ce a funcționat bine și ce a funcționat prost în versiunea anterioară a software-ului pentru a îmbunătăți următoarea versiune.
3. Comunicare osmotică: Cockburn a descris percepția și schimbul de informații între dezvoltatori care lucrează în aceeași cameră ca zgomot de fond, similar cu osmoza.

​​​​​​​​​​​​​​​​​​​​​​​​

În acel an, Cockburn a publicat "Crystal Clear: A Human-Powered Methodology for Small Teams". Contribuții suplimentare la dezvoltarea CC au fost aduse de administratorul de sistem Marcel Wagemann, care a scris un eseu despre utilizarea principiilor Crystal Clear, Agile și Scrum în dezvoltarea software-ului.

Nu există o singură metodă "cea mai bună" Crystal Clear; fiecare modificare se potrivește diferitelor tipuri de proiecte. Organizația sau proiectul creează această modificare pe baza "codului genetic" al lui Crystal (reguli de utilizare de bază).

• Clear: 2 până la 8 persoane care lucrează împreună într-unul sau în birouri adiacente
• Yellow: 10 până la 20 de persoane
• Orange: 20 până la 50 de persoane
• Red: 50 până la 100 de persoane

Pentru proiecte mai mari, se folosesc culori suplimentare: Maroon, Blue și Violet.

​Codul genetic al Crystal Clear constă în:

• ​Model de joc cooperativ economic: Cockburn consideră dezvoltarea software-ului ca o serie de "jocuri" constând din invenție și comunicare, restricționate de resurse. Fiecare joc are două obiective: livrarea software-ului în acest joc și pregătirea pentru următorul joc din serie. Fiecare nou proiect necesită strategii noi.
• Prioritățile alese: Comună tuturor metodologiilor Crystal sunt două priorități: siguranța și eficiența dezvoltării.
• Caracteristici alese: Acestea îmbunătățesc prioritatea siguranței. Trei sunt de bază (livrarea rapidă și frecventă a codului, comunicarea personală, îmbunătățirea prin reflecție), iar celelalte patru sunt suplimentare: siguranța personală , concentrarea, accesul ușor la experți și un mediu tehnic de calitate cu teste automate.
• Principiile alese: Unul continuă direcția cheie de personalizare a metodologiei:

Gradul de detaliu al cerințelor software, documentele de design și planificare depinde de specificul proiectului, inclusiv gradul de interacțiune personală a echipei și daunele care pot fi cauzate de erori nedetectate.

​Procesul ciclic al Crystal Clear

​​Majoritatea proiectelor cu Crystal Clear constau în șase cicluri, definind responsabilitățile și sarcinile echipei de proiect:

1. ​Ciclul proiectului: Deși proiectul în sine este o unitate de produs, de obicei este urmat de un alt proiect care repetă ciclul. Ciclul proiectului constă din trei părți: pregătirea (întâlnirea echipei, cercetarea 360°, determinarea metodologiei), o serie de două sau mai multe cicluri de livrare, și un "ritual de finalizare". Durata: de la câteva zile până la săptămâni.
2. Ciclul de livrare: Implică recalibrarea planului de lansare a software-ului, o serie de una sau mai multe iterații care rezultă într-un cod integrat testat, livrat utilizatorilor reali, și un "ritual de finalizare". Durata: 1 săptămână până la 3 luni.
3. Iterația: Constă în trei părți principale: planificarea iterației, activitățile zilnice și ciclul de integrare, și "ritualul de finalizare" al proiectului.
4. Săptămâna/ziua de lucru: Alegerea zilei sau săptămânii ca unitate de timp a ciclului depinde de formatul și echipa proiectului. Exemple includ întâlniri săptămânale de departament, rapoarte ale liderului de echipă și seminarii "brown-bag" (discuții la prânz despre problemele proiectului).
5. Perioada de integrare: Dezvoltarea, integrarea și testarea sistemului. Unele echipe efectuează teste de construcție continue cu o mașină dedicată, în timp ce altele integrează zilnic sau de trei ori pe săptămână. Cu cât ciclul de integrare este mai scurt, cu atât mai bine. Durata: 30 de minute până la 3 zile (în funcție de experiența echipei).
6. Dezvoltarea: Scrierea și verificarea unei părți a codului. Aceasta este munca de bază a unui programator în dezvoltarea agilă. Un membru al echipei preia o mică sarcină, programează o soluție (ideal cu teste), și o verifică în configurație cu întregul sistem. Durata: 15 minute până la câteva zile.

​Strategii și tehnici ale Crystal Clear

​"Crystal Clear pur” nu necesită strategii și tehnici specifice. Totuși, am pregătit un set de metode de bază pentru a ajuta echipa să lucreze eficient la fiecare ciclu CC.

• Cercetare 360°: La începutul proiectului, echipa trebuie să înțeleagă cât de util și semnificativ este produsul și dacă poate fi creat cu resursele și tehnologiile disponibile. Proiectul este examinat în domenii precum valoarea de afaceri, cerințele, tehnologiile necesare, planul proiectului, compunerea echipei și metodologiile alese. Implementarea durează câteva zile până la 1-2 săptămâni.
• Victoria timpurie: O victorie unește echipa și îmbunătățește încrederea fiecărui membru. În dezvoltarea aplicațiilor, strategia victoriei timpurii implică găsirea primei piese de cod funcțional, adesea un element mic al funcționalității utile a sistemului. Această mică victorie ajută membrii echipei să învețe stilurile de lucru ale celorlalți, utilizatorii obțin o idee timpurie despre sistem, iar sponsorii văd capacitatea echipei.
• Schimbare incrementală a arhitecturii: Arhitectura sistemului ar trebui să evolueze pe măsură ce cerințele tehnologice și de afaceri se schimbă în timp. Strategia abordează acest aspect prin permiterea echipei să schimbe arhitectura în mod incremental fără a perturba funcționalitatea generală a sistemului. Aceeași strategie poate fi aplicată și pentru modificările funcționale din sistemul final.
• Radiatoare de informații: Afișaje plasate într-un loc unde oamenii le pot vedea în timp ce lucrează sau se odihnesc. Acestea arată informațiile necesare fără a necesita întrebări suplimentare, întruchipând regula Crystal Clear "mai multă comunicare, mai puține întreruperi".
  
  Radiatorul de informații ar trebui să fie mare, accesibil cu ușurință, simplu de utilizat și citit, și să conțină informații actualizate. Exemple includ tablouri Scrum și Kanban și un glosar de lucru care interpretează terminologia proiectului.

Tehnici populare includ:

1. ​​Formarea metodologiei: Personalizarea Crystal Clear are loc în două etape: interviuri de proiect (crearea unei mini-biblioteci de experiență organizațională care să evidențieze punctele forte și slabe ale proiectului) și un atelier de formare a metodologiei (analizând experiența pentru a îmbunătăți punctele forte și a compensa slăbiciunile). Informațiile din primul pas sunt utilizate în al doilea.
2. Atelier de reflecție: Periodic, echipa ar trebui să ia o pauză de o oră pentru a desfășura un "atelier de reflecție," discutând ce funcționează bine sau prost, ce trebuie îmbunătățit și ce poate fi făcut diferit în etapele următoare ale proiectului.
3. Planificare Blitz: Permite sponsorilor, utilizatorilor și dezvoltatorilor să creeze împreună o foaie de parcurs a proiectului cu restricții de timp.
4. Întâlniri zilnice de abonament: Întâlniri scurte pentru a determina starea, progresul și problemele proiectului. Aceste întâlniri nu sunt pentru discuții, ci doar pentru identificarea problemelor. Rezultatele sunt înregistrate într-un manager de sarcini online sau pe un tablou Kanban fizic.
5. Programare în pereche: În acest proces, două persoane lucrează la o sarcină de programare pe un singur dispozitiv. Programarea în pereche este adesea criticată pentru eliminarea abordărilor individuale față de sarcini și pentru cerința unei relații interumane de înaltă calitate în cadrul echipei de proiect. O tehnică alternativă, "slide-by-slide," implică două persoane care stau suficient de aproape pentru a vedea ecranele celuilalt dar lucrează la sarcini diferite pe stații de lucru separate. Acest lucru corespunde conceptului de "interacțiune osmotică."

Lecturi recomandate despre Crystal Clear

Din păcate, există foarte puțină literatură despre Crystal Clear, și nicio lucrare specializată în ucraineană până în 2017.

​Resursele cheie pentru studiul Crystal Clear includ:

• ​"Crystal Clear: A Human-Powered Methodology for Small Teams" de Alistair Cockburn: Cartea esențială pentru înțelegerea metodologiei din partea creatorului său. Conține numeroase studii de caz, exemple și mini-ghiduri despre implementarea elementelor individuale ale Clear într-o organizație.
• "Pair Programming Illuminated" de Laurie Williams: O analiză detaliată a uneia dintre tehnicile Crystal Clear, programarea în pereche. Cartea oferă sfaturi practice despre utilizarea PP în dezvoltarea software-ului.
• "Agile Software Development: The Cooperative Game" de Alistair Cockburn: Explică conceptul de dezvoltare software ca un "joc cooperativ de invenție și comunicare." Cockburn dezvoltă ideile din Crystal Clear în această carte, pe care le formalizează ulterior în "Crystal Clear: A Human-Powered Methodology for Small Teams."
• Website-ul oficial al creatorului Crystal Clear: Deși nu este o carte, oferă o bogăție de informații, inclusiv interviuri, diagrame, articole de blog și discuții despre metodologie. Singurul dezavantaj este designul neprietenos al site-ului.

​

Multe așa-numite metodologii "cele mai bune" sunt respinse de echipele de proiect pentru că sunt prea complexe, intruzive și greoaie.