Dincolo de Sprint 0: o alternativă pentru integrarea echipelor

Scrum este cea mai populară metodologie de management de proiect din lume, cu peste 72% dintre echipe care folosesc Scrum sau un hibrid-scrum. Sunt șanse mari ca, dacă lucrați în dezvoltare web, să utilizați Scrum într-o anumită formă.

O tendință actuală în Scrum este „Sprint 0” sau vărul său mai artistic „Design Sprint”. S-a scris mult dacă acestea sunt sprinturi adevărate (nu sunt), dar s-a spus mai puțin despre motivul pentru care există, în primul rând, de ce se încăpățânează să rămână și ce alternative există.

Personal iubesc Scrum și sunt mereu în căutarea modalităților de a îmbunătăți treptat modul în care îl implementez. În acest articol, aș dori să împărtășesc metodele pe care le-am încorporat în fluxul meu de lucru și una pe care o consider utilă atunci când îmbin UX/UI și dezvoltare, precum și pentru a crea viziuni de proiect mai puternice.

Câteva definiții rapide înainte de a începe:

• Sprint 0
  Efortul inițial al unei echipe de a crea documentele de ghidare necesare pentru proiectele Scrum: o viziune, un backlog de produse și estimări de lansare a produsului.
• Design Sprint
  Efortul inițial al unei echipe de a crea un design de ghidare pentru restul versiunii.
  

De ce există Sprint 0 și Design Sprint

Este bine și bine să spui: „Sprint 0 nu este un sprint adevărat, nu o face”. Dar aceste adaptări de sprint există cu un motiv. Multe echipe le adoptă pentru că proiectul lor are o nevoie nesatisfăcută dincolo de scopul imediat al Scrum. Observația mea este că Sprint-ul 0 și sprinturile de design sunt cel mai des folosite pentru a aborda următoarele situații:

1. Lipsa unei viziuni puternice de ghidare;
2. Lipsa integrării designului în fluxul de lucru de dezvoltare.

Procesul Scrum presupune că o viziune clară a fost dezvoltată și comunicată de proprietarul produsului. Dar ridicați mâna dacă ați lucrat la proiecte în care viziunea este fie slabă, greșită, fie invizibilă. Și eu! Sprint 0 este o încercare a echipei de dezvoltare de a umple golul de viziune. Nu este cea mai rea idee, deci care este problema? Dintr-o perspectivă agilă, Sprint 0 nu este iterativ, nu folosește talentele întregii echipe și oferă rezultate nebuloase. Și înainte de a sublinia: „Hei, adevărata problemă aici este că echipele scrum nu ar trebui să facă treaba proprietarului produsului”, de fapt cred că o echipă interdisciplinară agilă este unul dintre cele mai bune medii pentru a dezvolta un mediu puternic, realist. viziune și obiective.

Propun o metodă mai agilă de construire a viziunii pe care am folosit-o cu succes în proiecte fără transfer. Voi explora ambele situații în care sunt utilizate aceste adaptări asemănătoare sprintului și voi descrie modul în care această alternativă primul sprint susține mai bine fluxul de lucru agil.

Viziunea și prototipul Sprintului

În prima situație, în care există o lipsă de viziune puternică, documentația de ghidare sau ideile sunt prea slabe pentru a începe cu adevărat un proiect Scrum. Pentru orice proces (inclusiv Scrum), aveți nevoie de direcție înainte de a începe călătoria. Agil este excelent pentru a găsi cea mai bună modalitate de a atinge un obiectiv, dar generarea viziunii inițiale nu este în domeniul său de aplicare. De fapt, din Scrum lipsește cu totul o descriere a viziunii necesare pentru ca procesul de dezvoltare să înceapă. Indiferent dacă este cu adevărat Scrum sau nu, Sprint 0 este doar o echipă web în prima linie, folosind instrumentele pe care le au, încercând să-și dea seama ce trebuie să facă înainte de a începe să o facă.

Adevăratul dezavantaj al Sprint 0 este că construirea documentului de ghidare pentru proiect în momentul în care aveți cele mai puține informații oferă o valoare scăzută procesului de dezvoltare care urmează.

Viziunile de ghidare a proiectelor care nu se aliniază cu realitatea emergentă iterativă fie trebuie să treacă prin procesul costisitor al unui alt Sprint 0, fie, mai des, pur și simplu să fie ignorate.

O alternativă mai bună este sprintul prototip: un prim sprint care implică întreaga echipă în timp ce construiește prototipul inițial în sine.

Procesul Prototype Sprint Vision

Ideile de brainstorming sunt traduse într-o fidelitate vizuală scăzută, prototip funcționând cât mai repede posibil. Prototipul este scris într-un cadru funcțional front-end HTML și CSS, adică limbajul partajat al echipei. Nu toată lumea poate înțelege o fișă de specificații sau o declarație de viziune. Toată lumea poate înțelege un site web, iar comunicarea este mai ușoară și încorporează o gamă mai largă de discipline.

Până la sfârșitul primului sprint, prototipul este gata pentru testarea inițială pe mai multe fronturi, inclusiv utilizarea generală, accesibilitatea și capacitatea de răspuns mobil. În echipele mele, aceasta este o creștere valabilă și importantă. Sprintul prototip produce, de asemenea, un stoc inițial de produse. Pe măsură ce elementele din restante sunt finalizate în sprinturile viitoare, prototipul câștigă fidelitate. Prototipul nu este un cod de folosit, ci este fundamental.

În unele proiecte, o viziune scrisă este generată pe măsură ce prototipul este produs. Dar în multe proiecte, prototipul este viziunea. Vorbește în limba comună a echipei și, desigur, nu depășește niciodată produsul.

Exemplu

Exemplul de mai jos este al unui prototip funcțional pentru o aplicație de comerț electronic, completat din schița generală din cererea de propuneri inițială. Oricât de dur este, a fost esențial în concentrarea energiilor echipei într-o direcție productivă, depășind multe potențiale distrageri și capcane pentru a se concentra pe criterii funcționale.

Un prototip inițial va duce adesea la modificări ale cerințelor, care sunt pur și simplu cele mai bune presupuneri până când nu sunt la lumina experienței utilizatorului. De exemplu, una dintre informațiile pe care le-am obținut în urma prototipului de sprint prezentat mai sus este că prețul și butonul „cumpără” erau inițial mult prea mici pe pagină. Solicitarea inițială a fost să le plaseze sub informațiile despre produs și deasupra recomandărilor, dar un prototip funcțional a arătat rapid că ierarhia nu era foarte funcțională.

O altă funcționalitate care a ieșit la iveală a fost că imaginile din galerie au fost solicitate inițial să fie mari și să întindă toată lățimea paginii. În loc să expună părților interesate motive ipotetice pentru care acest lucru nu ar funcționa, prototipul a fost capabil să demonstreze problemele într-un limbaj comun pe care întreaga echipă o înțelege. Într-o sesiune de putere cu părțile interesate, am reorganizat rapid această pagină într-o ierarhie convenită universal.

Deoarece prototipul se naște accesibil și receptiv, putem începe imediat testarea pe mai multe dispozitive și tehnologii. Deși designul (dacă se poate numi chiar așa în această etapă incipientă) este păstrat în mod intenționat la fidelitate scăzută, a fost imediat evident că mesajele de comutare de ani pe desktop a fost prea mare pe mobil și interfera cu gradul de utilizare (stânga). Am actualizat rapid prototipul pentru a folosi un comutator mai mic în antet (dreapta).

Alte câteva probleme au apărut rapid în timpul acestui sprint prototip:

• Clientul, după ce a făcut clic pe navigarea funcțională, și-a dat seama imediat că a ratat o componentă funcțională majoră din specificațiile lor: un blog. Acest lucru a afectat estimarea și momentul, dar ne-am putut ajusta rapid.
• Pentru echipa UI a fost evident că afișarea prețurilor era prea complexă și confuză. Am explorat alte posibilități împreună cu clientul și am putut să prototipăm rapid și să testăm utilizatorii mai multe soluții în timpul sprintului de prototip.

În loc ca viziunea să fie potențial un impediment sau să devină depășită de îndată ce începe dezvoltarea, într-un sprint prototip viziunea și criteriile funcționale sunt dezvoltate împreună și se sprijină reciproc. Și pentru că viziunea este generată de echipă, nu există transfer către echipă și evită cu ușurință acea perioadă riscantă în procesul de dezvoltare.

Design și prototipul Sprint

În a doua situație — lipsa integrării designului cu dezvoltarea — este adesea atunci când veți vedea un „sprint de design” folosit. Mi se pare că această direcție este chiar mai contraproductivă decât un Sprint 0. Provocările integrării designului într-un proces complex de dezvoltare sunt reale, dar un sprint de design este o abordare auto-învinsă. Sprintul de proiectare este un bandaid pentru simptom - provocarea de a construi echipe integrate - dar nu abordează problema de bază - provocarea de a înțelege și de a satisface nevoile utilizatorilor. Încărcarea frontală a designului într-un singur sprint evită provocarea integrării, dar beneficiile unui proces de proiectare integrat și incremental și fereastra pe care o deschide pentru a înțelege și a ajunge la utilizatori sunt complet pierdute.

Prototipul de sprint pe care îl folosesc în proiectele fără transfer este o alternativă productivă și complet agilă la sprintul de design. Este colaborativ și îmbină atât UI/UX, cât și dezvoltarea din primele etape ale proiectului. Chiar și cea mai experimentată echipă de proiectare poate beneficia de implicarea altor discipline și, în mod critic, se asigură că codul și obiectivele de proiectare nu sunt încrucișate.

De multe ori se așteaptă ca sprintul de proiectare să dezvolte viziunea. Aceasta este o mișcare disperată bazată pe o înțelegere vagă, dar perspicace, că procesul de proiectare este mai bine echipat pentru a genera viziune decât dezvoltare. Cu toate acestea, o viziune generată de design este un substitut slab pentru un efort real, colaborativ, la nivelul întregii echipe.

Bieții designeri sunt nevoiți să genereze un produs final pentru a demara dezvoltarea fără informațiile interdisciplinare necesare pentru a face acest efort cu adevărat valoros. Deși un designer cu cunoștințe tehnice și mai multă experiență va avea șanse mai mari să facă acest lucru corect, este totuși foarte riscant. Fără niciun produs potențial livrabil la sfârșitul fazei de testat împotriva presupunerilor continuă în dezvoltare. Dacă designul nu a atins obiectivul sau dacă specificațiile se modifică, poate duce la întârzieri mari, pe măsură ce se întoarce la echipa de proiectare. Agile este în esență un proces de management al riscului și putem face mai bine decât să începem proiectele noastre agile cu un sprint de proiectare inerent riscant.

Procesul de proiectare a prototipului Sprint

Cea mai importantă schimbare față de un sprint de design mai tradițional este că în timpul sprintului prototip, echipa trece direct de la hârtie la prototip și omite utilizarea Sketch, InVision, Photoshop sau a altor programe de layout digital. Ele acționează ca o cârjă vizuală în această etapă, parând să introducă valoare foarte repede (pentru că designerii buni fac lucruri arătoase), dar valoarea reală a unei machete de înaltă fidelitate atât de devreme este foarte scăzută, în timp ce pericolul potențial pe care îl introduce - nunta părților interesate cu soluții greșite — este mare.

Aceste instrumente sunt cele mai bune la machetele plate de înaltă fidelitate, dar prototipul inițial nu este nici de înaltă fidelitate, nici plat. Tabla albă, creionul și hârtia permit echipei să lucreze rapid ideile, fără a fi căsătoriți cu ele. Apoi introduceți această gândire într-un prototip funcțional cât mai curând posibil.

Fiecare membru al echipei, inclusiv designerii, ar trebui să se familiarizeze cu și să poată lucra la prototip direct în fazele lo-fi. Dar dacă acest lucru nu este posibil (sau este un obiectiv pe termen mai lung și trebuie să mergi mai departe acum), atunci o abordare în pereche în care un designer și un dezvoltator lucrează cot la cot este bună. Schițele pot fi descrise de către proiectant și interpretate de dezvoltator împreună, extinzând înțelegerea comună a fiecărui punct de vedere.

Exemplu

Exemplul de mai jos arată procesul nostru de distilare a unei analize aprofundate a unui site web existent direct într-un prototip funcțional. Acesta a permis ca constatările raportului să fie evaluate într-un cadru web nativ, o experiență foarte diferită de analizarea intelectuală a recomandărilor dintr-un document tipărit:

De asemenea, spre deosebire de documentul de analiză aprofundată (pe cât de util a fost), prototipul funcțional nu conține jargon și folosește un limbaj verbal și vizual comun pe care toată lumea îl poate înțelege. Deschide conversația pe afișaj vizual pentru toți membrii echipei și disciplinele.

Întrebarea noastră principală în timpul construirii acestui șablon a fost cât de multe detalii de design să includem. Pentru că aveam un document bogat și plin de analize din care să extragem, am fi putut duce prototipul mai departe. Dar, ținând cont de faptul că elementele vizuale se pot muta rapid (și neintenționat) de la sfera ideilor la sfera faptelor, am păstrat aspectul neangajant și am distilat documentul doar la elementele și sensul său esențial.

Testarea internă ne-a adus în stadiul unei soluții mai concentrate pe utilizator, trecând peste multe probleme potențiale, dar am evitat în mod conștient să luăm decizii de design rafinate atât de devreme în proces. Este important să cântărim în mod continuu toate ideile și sugestiile, inclusiv ale clientului, cu datele cunoscute și să ne amintim că fondul nostru de cunoștințe este mai mic în acest moment decât va fi în orice altă etapă a proiectului.

Un alt motiv pentru care este esențial să păstrați prototipul inițial lo-fi și să nu includeți niciun element de „design” este că acceptarea echipei poate fi deraiată de elemente vizuale irelevante care provoacă reacții viscerale neintenționate. Stam departe de culoare și nici măcar nu includem sigla clientului (folosește în schimb un spațiu liber sau o casetă gri deschis ca substituent). Conversația trebuie să fie ghidată în mod continuu către criterii funcționale cum ar fi ierarhia conținutului, accesibilitatea, gradul de utilizare, limbajul și sensul. Asigurați-vă echipa că „lucrurile distractive” vor veni, dar nu în acest stadiu incipient.

De fapt, un obiectiv important al unui prototip de sprint de succes este de a lua cât mai puține decizii inițiale de proiectare. Designul de succes este alimentat de experiența utilizatorului, așa că acordați timp cunoștințelor de proiect emergente pentru a informa interfața de utilizare.

Când este finalizat prototipul Sprint

Sprintul este finalizat atunci când prototipul și artefactele însoțitoare sunt aprobate de întreaga echipă (inclusiv client), iar prototipul este considerat gata pentru testarea inițială de utilizare și accesibilitate.

Un prototip funcțional timpuriu aduce la viață viziunea proiectului prin scară (număr de pagini, sfera de navigare și alte elemente principale ale interfeței de utilizare), complexitate viitoare (conținut substituent cu descriptori utili, posibil unele funcționalități timpurii codificate) și identificarea nevoilor (tehnologii specifice necesare). , unde vor fi implementate, orice dependențe). Deciziile privind instrumentele, mediul de lucru și stiva de coduri vor fi luate cu contribuția întregii echipe.

Atingerea acestei creșteri finalizate poate dura doar o zi pentru o echipă experimentată cu un client receptiv, dar durează de obicei aproximativ o săptămână și nu mai mult de două săptămâni. Sprinturile prototip ar trebui să se miște într-un ritm rapid și trecerea peste intervalul de timp de două săptămâni poate fi un steag roșu. Poate însemna că există alte probleme în joc.

Câteva probleme obișnuite de urmărit în timpul unui sprint prototip

Câteva probleme obișnuite de care trebuie să țineți cont atunci când implementați prototipul de sprint includ:

• Îmbrățișați valoarea fidelității scăzute și evitați accentul pe imagini. Fiți vigilenți cu privire la acest punct, deoarece echipele care sunt noi în această abordare ar putea avea nevoie de ajutor și liniștire, deoarece trec dincolo de „unde este sigla” și se concentrează pe întrebări mai profunde legate de funcționalitate și ierarhie.
• O altă fațetă a celor de mai sus, fiți vigilenți și dacă nu vă atașați de propriile idei de design/aspect. Este util să vă amintiți în timpul sprinturilor prototip că nu se generează nimic prețios și să rămâneți detașat de rezultatele finale. De asemenea, este încă un motiv pentru a păstra prototipurile minimale și, sincer, destul de urâte. Acesta servește scopului de a menține utilizatorii detașați.
• Acceptarea timpurie a procesului din partea conducerii este esențială . Pentru că întreaga echipă este implicată, clientul dvs., șeful dvs. și dezvoltatorii trebuie să sprijine și să hrănească procesul cu implicarea, creativitatea și timpul lor. Nu fi o majoretă singuratică, întreaga ta echipă trebuie să-și fluture pom-poms!
• Comunicarea slabă este călcâiul lui Ahile al tuturor muncii în echipă . Sprintul prototip nu va rezolva problemele persistente de comunicare, dar le va aduce în prim-plan mai devreme, pe măsură ce întreaga echipă se scufundă într-un flux de lucru colaborativ aproape imediat. Orice probleme de comunicare deja existente vor apărea devreme și adesea într-un sprint prototip, pe măsură ce lucrați spre consens și pentru prima creștere realizată. Utilizați oportunitatea de a îmbunătăți comunicarea și implicați întreaga echipă în găsirea de soluții.
• Alegeți cadrul corect pentru front-end . Dacă nu aveți deja unul, s-ar putea să fie nevoie să încercați diverse cadre frontale înainte de a găsi unul care să se potrivească cu fluxul de lucru al echipei dvs. Recomand să te uiți în cadre minimale precum Fomantic sau Bulma și să nu te împotmolești de clopoței și fluiere. Cu toate acestea, cadrul potrivit este întotdeauna cel care funcționează pentru echipa ta.
• Echipa UI/UX trebuie să dezvolte un nivel de confort și acces la cadrul frontal. În mod ideal, aceștia vor lucra direct pe prototip, evitând transferul inutil și nevoia de traducere de la un mediu la altul (adică de la Sketch la prototip). Dacă echipa ta front-end nu este familiarizată cu CSS și HTML, atunci o abordare pereche (cu un designer și un programator lucrând împreună la cadru) funcționează bine.
• Nu în ultimul rând, amintiți-vă că veți deveni mai buni și mai rapid ca echipă ! Rularea unui prototip productiv de sprint este o abilitate care crește odată cu practica.

Ce se întâmplă mai departe

Incrementul finalizat al primului sprint - prototipul funcțional, de joasă fidelitate - stabilește scena pentru toate sprinturile care urmează. Cu un prototip funcțional, testarea utilizatorilor pentru uzabilitate, accesibilitate și receptivitate poate începe imediat, asigurându-se că viitoarele sprinturi sunt informate de UX.

Sprintul prototipului este un început excelent pentru orice proces scrum, dar în proiectele mele, următorul nostru pas este să trecem la un flux de lucru cu două căi, în care UI/UX lucrează cu jumătate sau întregul sprint înainte de dezvoltare, făcând descoperirea și actualizarea vizuală a prototipului la reflectă noi perspective.

Prototipul se dezvoltă organic și devine din ce în ce mai rafinat, alimentat de cercetarea UX și de nevoi funcționale realiste. Aceste informații, care nu sunt disponibile în timpul sprintului prototip, apar doar treptat pe măsură ce proiectul progresează. UI/UX și dezvoltarea se alimentează reciproc în fluxurile de lucru ale celuilalt prin procesul agil cu două căi.

Nu există transfer de la design la dezvoltare care să fie construită sau o aplicație dezvoltată pentru a proiecta pe piele. În schimb, sprintul prototip implică întregul grup de la început și formează o bază solidă pentru un flux de lucru agil colaborativ pe tot parcursul proiectului.

Viziunea de ghidare care rezultă dintr-un sprint prototip nu va fi perfectă și probabil se va schimba pe măsură ce se învață mai multe, dar recunoașterea faptului că știm mai puțin la început decât în ​​orice altă fază a unui proiect este în centrul fluxului de lucru agil. Când aplicăm aceeași filozofie la apariția viziunii și designului proiectului printr-un sprint prototip, rezultatul este o creștere acționabilă realizată, artefacte cu adevărat utile, acceptare comună și un model de lucru în echipă și colaborare care poate fi susținut pe tot parcursul proiectului. .

O notă despre setările agenției

Dacă lucrați la o agenție, s-ar putea să vă gândiți că această abordare va fi o vânzare grea. Din păcate, probabil că ai dreptate. Multe agenții sunt în mod inerent lipsite de agilitate și se străduiesc activ pentru transferul total al proiectului, adesea cu aprobarea oficială și repercusiuni documentate cu atenție asupra modificărilor pe viitor. A susține un sprint prototip într-o organizație non-agilă este un non-starter: pur și simplu nu este în ADN-ul lor. Odată ce o organizație îmbrățișează echipe agile și interdisciplinare, atunci se pot gândi cu ușurință dacă sprintul prototip fără transfer le va îmbunătăți procesul.

Concluzie

Sprintul 0 și sprinturile de design abordează provocările reale cu care se confruntă multe echipe scrum: lipsa de viziune, lipsa designului integrat sau ambele. Sunt răspunsuri înțelese și logice, dar nu oferă valoare ridicată și nu contribuie la echipe puternice agile.

Înlocuirea acestora cu un prototip de sprint este o modalitate practică de a aborda dezavantajele Sprint-ului 0 și ale sprinturilor de proiectare, punând în același timp bazele unei colaborări mai puternice agile în timpul sprinturilor viitoare.

Un sprint prototip folosește talentele întregii echipe, generează viziunea necesară, are ca rezultat prima creștere a echipei și evită transferul proiectului. Prin acest proces, echipele construiesc proprietatea comună asupra viziunii proiectului și o bază mai puternică pentru cooperarea interdisciplinară în spiritul agil.

Citiți suplimentare despre SmashingMag:

• A deveni un facilitator mai bun
• Adaptarea Agile pentru echipe part-time
• Importanța retrospectivelor proiectelor
• Aduceți un proces de proiectare mai bun organizației dvs