Nu există multe companii pe piața externalizării rusești care utilizează metodologii de dezvoltare flexibile (Agile). Toată lumea este obișnuită să lucreze la un model cascadă (Waterfall). Același lucru este valabil și pentru sectorul de dezvoltare mobilă.
Clientul are aproape întotdeauna un buget sau așteptări privind costul, precum și sarcina finală - o aplicație cu o anumită funcționalitate. Cu toate acestea, în dezvoltarea mobilă mobilă Aplicația Agile este mai justificată.
Externalizăm dezvoltarea aplicațiilor mobile, deși folosim instrumentul Agile - Pivotal Tracker (în continuare - PT). Vreau să vă spun despre experiența utilizării acesteia în acest articol.
De ce am nevoie?
Atunci când se lucrează la echipa de dezvoltare - managerul de proiect, mai mulți dezvoltatori și testere - apoi o esență (esența acestei sarcini, o sarcină, utilizatorul-poveste sau altfel) pot fi câteva state, persoana responsabilă și interpret. Prin urmare, mulți manageri clasici de sarcini nu sunt potriviți pentru sarcinile de dezvoltare contabilă.
În final, am ajuns la concluzia că esența ar trebui să aibă următoarele semnificații:
Ce pot încerca?
Piața oferă multe instrumente pentru lucrul în echipă (atât pentru echipa de birouri cât și pentru angajații aflați la distanță). Vom lua în considerare doar instrumentele pentru interacțiunea managerului, dezvoltatorului și testerului. Managerul de comunicare cu clientul, managerul cu designerul și alte pachete nu au nevoie de unelte special ascuțite, dar există practici interesante aici - într-un alt articol.
O dată vă spun că nu există loc pentru hârtie în fluxul nostru de lucru, toate instrumentele sunt doar pe computer. Practic, acum sunt oferite mai multe servicii pe modelul SaaS, dar există și soluții care pot fi instalate pe serverul dvs.
Probabil, acesta este cel mai cunoscut sistem de urmărire a sarcinilor, a discuțiilor, a dosarelor și a altora. Prin urmare, este simplu, sigur și convenabil. Excelent pentru sarcinile manageriale - liste simple de verificare, discuții, editarea în comun a textelor. Dar nu este potrivit pentru sarcini de dezvoltare.
Sarcina poate fi într-o anumită listă, poate avea un interpret, poate exista o limită de timp. Cunosc oameni care trebuie să efectueze o sarcină la o versiune anumit produs (versiunea 1.0) a scris versiunea corectă (Taxco din titlu „Vot pentru evaluare [3.4]), și liste utilizate pentru a determina starea unei sarcini (“ planificat „“ În procesul de "," Finalizat ").
Poate că pentru proiecte simple - un manager și un dezvoltator - Basecamp poate apărea, dar sistemul se prăbușește atunci când există 2-3 dezvoltatori, un tester și un manager de proiect în proiect.
O platformă bine cunoscută, pe care mulți dezvoltatori o iubesc. Este instalat pe server, este ușor de personalizat, are multe module. Pentru sarcini managerul-dezvoltator-tester pare greoi. Interfața este ascetică, iar dacă există un "creier Apple", folosirea unui astfel de instrument va deranja =)
Un monstru de la o companie care a mâncat toate animalele în instrumente de dezvoltare software. Personalizat, scalat - uneori confuz și scump, dar mulți îi plac.
Probleme GitHub
Știu că în unele cercuri TFS este popular, dar iartă-mă - mă tem chiar să mă uit acolo)
Tipii de la Themed Media au sfătuit să se uite la Asana, dar, de asemenea, nu s-au lipit.
De ce Pivotal Tracker?
de stabilire a prețurilor
PT nu este un produs gratuit, costă destul de banal și funcționează pe modelul SaaS.
Pentru 100 de dolari pe lună, aveți posibilitatea să creați un număr nelimitat de proiecte și 25 de participanți.
PT se poate integra cu Google Apps, apoi devine mai ușor să inviți angajații în proiecte și puteți atașa direct documentele din Google Drive la sarcini (de exemplu, cu logica descrisă).
PT are multe caracteristici interesante și ascunse, aproape totul este descris într-un ajutor de lungă durată - www.pivotaltracker.com/help.
Reguli generale
Nu folosim conceptul de poveste a utilizatorului așa cum este el în realitate. La noi este pur și simplu sarcină / sarcină.
În PT, există 4 tipuri de sarcini - caracteristică, bug, sarcină și eliberare. Utilizăm aceste tipuri după cum urmează:
Caracteristică - sarcini de bază pentru schimbarea sau îmbunătățirea funcționalității
Bug - număr de bug în Crashlytics sau o scurtă descriere a bug-ului
Eliberare - numele versiunii de construire (alfa, beta și rc)
Corectitudine - sarcini pentru manager care au legătură directă cu dezvoltarea sau lansarea
Eticheta purpurie este o epicã - o folosim ca numãr de versiune, la care va merge aceastã funcționalitate.
O etichetă verde este o etichetă - o folosim pentru a specifica secțiunile la care se aplică această caracteristică (de exemplu, vizualizarea pe blog).
Fiecare SARCINĂ poate conduce o discuție cu referire la ceilalți membri ai echipei (care ajung notifay), puteți adăuga orice fișiere (cel mai frecvent capturi de ecran, cum ar fi UI-bug), este posibil să se efectueze sabtaski (convenabil pentru completări-pixel perfectă).
Toate eposurile (epice) sunt stocate inițial într-o filă separată. Puteți să deschideți întotdeauna un epic cu o versiune veche a aplicației și să vedeți când a fost implementată o anumită caracteristică, precum și să planificați cu ușurință o foaie de parcurs pentru viitoarele versiuni. Fiecare epic are propriul număr unic, la fel ca și sarcina - îi puteți da întotdeauna o legătură directă.
Interfața din PT este un panou: bază - restante, gheață, curent. Noi folosim doar panoul icebox (pentru stocarea de idei și cele ale Taxco, care nu sunt incluse în nici o versiune încă) și restante (SARCINĂ aprobat pe bandă magnetică), precum și panouri, care sunt cauzate prin epopeea - acestea reflectă SARCINĂ numai la versiunea selectată. La prima vedere, cineva care nu îl utilizează pare foarte ciudat - dar apoi sunt atât de obișnuiți cu acest sistem, care este un alt ceas pur și simplu nu se poate niciodată.
Flux de lucru direct
Managerul are la dispoziție TK și foaia de parcurs în funcție de versiune. Procesul de creare a sarcinilor începe. Fiecare SARCINĂ însoțit în mod necesar Opik (în cazul în care este de a dezvolta de la zero, de obicei, versiunea 1.0) și eticheta de pe lista (folosim eticheta ca ecran, de exemplu, comanda este „echipa“ ecran, jocul este un „meci“ ecran). Toate sarcinile intră în cutia de gheață.
Apoi, sarcinile sunt mutate în Backlog. Din acest moment sunt aprobate și fiecare interpret trebuie să aibă un interpret instalat. Dacă există un dezvoltator pe proiect, atunci acest lucru nu este necesar. Dacă există mai mulți dezvoltatori, repartizarea sarcinilor se realizează prin termenul de timp al proiectului.
Fiecare sarcină are un nivel de complexitate - este un fel de valoare abstractă în puncte (este folosit pentru a calcula viteza, dar nu o folosim). Cu toate acestea, fără a seta această valoare, sarcina nu pornește. După ce dezvoltatorul începe sarcina, apasă butonul Start. La finalul sarcinii, dezvoltatorul face clic pe Finish. Următoarea stare posibilă a sarcinii este livrată. Acest lucru se întâmplă când dezvoltatorul livrează sarcina către ansamblu.
Facem adunări de vineri, au deja sarcini finalizate. În timpul desfășurării ansamblului, dezvoltatorul marchează sarcinile care vor intra în ansamblu și care pot fi preluate de managerul de proiect. Managerul poate accepta sarcina dacă consideră că sarcina se face așa cum ar trebui și funcționează sau poate lua o decizie prin specificarea motivului. După reducere, sarcina are o stare respinsă (butonul "Restart") și o puteți porni din nou.
Astfel, puteți înțelege în orice moment ceea ce face un anumit dezvoltator, ce sarcini sunt deja implementate și care vor intra în adunare, ce altceva în cutia de gheață etc. Este foarte convenabil și evident, de asemenea, ordinea sarcinilor poate fi ușor schimbată - de exemplu, în cadrul unei singure versiuni sau transferată la următoarea versiune.
După revizuirea ansamblului de vineri, managerul poate crea și autobuzele asociate cu bug-urile. În versiuni cu stadiile beta și rc, este conectat un tester, care poate crea bug-uri buggy. Apoi este și este responsabil pentru acceptarea lor sau refacerea după ce a stabilit dezvoltatorul.
Când sarcina este livrată și acceptată, devine verde și sarcina este închisă.
Dezvoltatorii preferă să precizeze în comitet în ID-ul GitHub al sarcinii, atunci când împingă, sarcina se termină automat.
caracteristici
În proiectele mari, numărul de sarcini poate ajunge până la o mie. Puteți elabora propriile dvs. principii de creare și utilizare a acestora.
În cazul unui server de construire automată, starea sarcinii pentru Delivered trebuie modificată atunci când modificările sunt aduse la depozit, deoarece asamblarea va avea loc automat. Ei bine, aici fiecare echipa are propriile caracteristici.
Pivotal Tracker are aplicații iPhone / iPad excelente (în timp ce adevărul este fără a se adapta la iOS7), există și clienți terți pentru Android. Există o integrare cu toate serviciile externe - Github, Campfire, FlowDock, HipChat, Zendesk etc.
Nu oferim clientului accesul la Pivot, dar în cazul unei astfel de cerințe în tracker, este posibil să invitați un "observator" cu drepturi "numai pentru citire".
concluzie
Prietenii noștri din AviaSales folosesc acest instrument atât în dezvoltarea serverului, cât și în departamentul de dezvoltare mobilă. Prieteni de la Bambk folosesc Pivotal pentru dezvoltarea serverului. Suntem cu toții foarte mulțumiți de faptul că există un astfel de instrument pe piață și oferă cu adevărat oportunitățile necesare. Implementarea utilizării programului Pivotal Tracker poate fi fie o mică echipă de start-up, fie o echipă serioasă de dezvoltare a unui produs sau a unei dezvoltări externe.
Articole similare
Trimiteți-le prietenilor: