Așa cum am combina cu scrum XP

Cum putem combina Scrum cu XP

Faptul că Scrum și XP (eXtreme Programming) pot fi combinate în mod eficient, fără îndoială. Cele mai multe dintre discuțiile de pe internet susțin această ipoteză, și nu vreau să pierd timpul pe o justificare suplimentară.

Cu toate acestea, un lucru eu încă mai trebuie să menționez. Scrum abordează probleme de management și organizare, în timp ce XP se concentrează asupra practicii de inginerie. Acesta este motivul pentru care aceste două tehnologii funcționează bine împreună, se completează reciproc.

Astfel, mă alătur susținătorii consideră că Scrum și XP pot fi combinate în mod eficient!

Am de gând să-ți spun despre practicile cele mai utile de XP și despre modul în care le folosim în munca noastră de zi cu zi. Nu toate echipele noastre au reușit să folosească practicile XP în totalitate, dar am avut un număr mare de experimente cu multe aspecte ale combinație XP / Scrum. Unele practici XP sunt Scrum practică în mod direct relevante, de exemplu, «echipa Total», «Stai împreună», «Povestiri» și «joc de planificare». În aceste cazuri, vom rămâne doar la Scrum.

Recent, am început să-l practică într-una din echipele noastre. Surprinzător, funcționează destul de bine. Cele mai multe dintre alte echipe noastre încă nu au o mulțime de programe în perechi, cu toate acestea, încercați această practică într-una din echipele noastre pentru câteva sprinturi, sunt inspirat de ideea de a introduce pereche de programare și de alte echipe.

Aceasta este până la câteva concluzii după utilizarea pereche de programare:

• Programarea pereche îmbunătățește calitatea codului.

• pereche de programare nu crește comenzile de focalizare (de exemplu, atunci când o echipa-mate spune: „? Hei, acest lucru este cu siguranta necesar pentru acest sprint“)

• In mod surprinzator, multi dezvoltatori care sunt împotriva pereche de programare este într-adevăr nu-l practică, dar odată ce ați încercat - să realizeze rapid beneficiile.

• Programarea pereche este obositoare, așa că nu ar trebui să se ocupe cu ei toată ziua.

• modificări frecvente ale perechilor dă un rezultat bun.

• Programarea pereche contribuie într-adevăr la răspândirea cunoștințelor în cadrul echipei, accelerarea semnificativă a procesului.

• Unii oameni nu se simt confortabil de lucru în perechi. Nu este necesar pentru a scăpa de un programator bun, doar pentru că el nu-i place pereche de programare.

• Revizuirea codului - o bună alternativă pentru a asocia programare.

• Nu forțați pereche de oameni de programare. Încurajați-i să dea instrumentele necesare si lasa-te ajunge la asta.

Driven Development Test (TDD)

În cele din urmă! Test de dezvoltare Driven mai important pentru mine decât Scrum și XP împreună. Puteți lua casa mea, un televizor, un câine, ci doar să încerce să interzică utilizarea TDD! Dacă nu vă place un TDD, atunci pur și simplu nu mă lăsa aproape, altfel eu încă adus la proiect în liniște :)

Desigur TDD în 10 secunde:

Test de dezvoltare Driven înseamnă că trebuie mai întâi să scrie teste automate (care nu trece - aprox. Interpret). După ce acest lucru ar trebui să scrie doar suficient de cod pentru a face testul trecut. Apoi, trebuie să refactor, în principal, pentru a îmbunătăți lizibilitatea și codul elimina suprapunerea. Se repetă, dacă este necesar.

Câteva lucruri despre TDD:

• Test de Driven Development - nu este ușor. De fapt, se pare că demonstrează TDD programator este practic inutil - de multe ori singura modalitate eficientă de a infecta TDD lui este după cum urmează. Programatorul ar trebui să fie obligat să fie asociat cu cineva care este bun TDD. Dar, de îndată ce programator a pătruns în TDD, acesta este deja infectat și serios despre dezvoltarea un alt mod de a auzi chiar vrea.

• TDD are un impact pozitiv profund asupra proiectarea sistemului.

• Pentru a TDD a fost de a beneficia într-un proiect nou, trebuie să facă un efort mare. Mai ales o mulțime este cheltuit pe teste de integrare de „cutie neagră“. Dar aceste eforturi au dat roade foarte repede.

• Petrece timp suficient, dar pentru a face acest lucru, pentru a scrie testa a fost ușor. Adică, este necesar să se obțină instrumentele necesare pentru a instrui personalul, oferă sprijinul și crearea clasei de bază, și așa mai departe. D.

Noi folosim următoarele instrumente pentru dezvoltarea driven-test:

• JUnit / HttpUnit / jWebUnit. Suntem eyeing TestNG si seleniu.

• HSQLDB ca o bază de date încorporată în memorie (în memorie), în scopuri de testare.

• Jetty ca un web-container încorporat în memorie (în memorie) în scopuri de testare.

• Cobertura pentru stabilirea gradului de acoperire cod.

• cadru de primăvară pentru scrierea diferitelor tipuri de corpuri de testare (în m. Hr. Folosind mokov (mock-obiect) și fără, cu o bază de date externă și baza de date în memorie (în memorie) și altele. D.)

În produsele noastre cele mai sofisticate (din punct de vedere al TDD) am implementat teste automate de acceptare de către „cutia neagră“. Aceste teste sunt încărcate în memorie întregul sistem, inclusiv baze de date și web-server, și interacționează cu sistemul numai printr-o interfață externă (de exemplu, prin

Această abordare vă permite să obțineți cicluri rapide de „dezvoltare-build-test“. De asemenea, el acționează ca o poliță de asigurare, oferind încredere în succesul dezvoltatorilor de cod refactoring frecvente. La rândul său, acesta oferă simplitate si eleganta designului, chiar dacă creșterile de sistem.

TDD, și noul cod

Noi folosim TDD pentru toate proiectele noi, chiar dacă aceasta înseamnă că faza de desfășurare a mediului de lucru al proiectului va necesita mai mult timp (pentru că aveți nevoie de mai mult efort pentru a configura și menține instrumentele de testare). Este ușor de înțeles că beneficiile depășesc orice scuză pentru a nu pune în aplicare TDD.

TDD și codul existent

Am spus deja că TDD - nu este ușor, dar este foarte dificil. așa că încearcă să folosească TDD la codul, care nu a fost proiectat inițial pentru aplicarea acestei abordări! De ce? Acest subiect poate fi discutat pentru o lungă perioadă de timp, dar cred că mă voi opri. Salvați-vă gândurile pentru cartea următoare: «TDD: Notes din față»: o)

La acea vreme, ne-am petrecut mult timp încercând pentru a automatiza testarea de integrare a unuia dintre sistemele complexe, codul pe care le-am moștenit într-o stare teribil, și fără un singur test.

În cazul în care producția de fiecare lansare, am izolat o echipa de testeri, care efectuează o gamă completă de teste de regresie și de performanță complexe. Testarea de regresie a fost realizată în principal de mână, care a încetinit în mod semnificativ procesul de dezvoltare și inginerie de presă. Apoi, scopul nostru a fost de a automatiza aceste teste. Cu toate acestea, câteva luni pobivshis capul de perete, ne-am dat seama că nu am ajuns aproape de gol pe o iota.

Apoi ne-am schimbat abordarea. Am recunoscut faptul că testarea de regresie automatizată, nu ne putem permite, și întrebați-vă întrebarea: „Cum pot reduce timpul de testare“. A fost un sistem de joc, și am constatat că cele mai multe teste timp echipa a petrecut pe sarcini banale, cum ar fi stabilirea unui test al turneului, sau de așteptare pentru începerea turneului. De aceea, am creat un instrument pentru a efectua aceste operațiuni. Mici, disponibile prin apăsarea script-cheie fierbinte care fac toate lucrările pregătitoare, care să permită testere să se concentreze direct pe test.

Dar aceste eforturi au dat roade! Mintea ar trebui să fi făcut acest lucru de la început. Dar noi am fost atât de concentrat pe automatizare pe care au uitat de abordare evolutivă în care primul pas ar fi pentru a crea mediul care permite de a face testarea manuală mai eficientă.

Lecția a învățat: În cazul în care, prin testarea de regresie manuală nu poate refuza, dar doresc cu adevărat să automatizeze - ar trebui să nu mai bine să (bine, cu excepția faptului că este într-adevăr foarte simplu). În schimb, face totul pentru a facilita procesul de testare manuală. Și după aceea ne putem gândi la automatizare.

Acest lucru înseamnă că începe cu un design simplu și continuu să-l îmbunătățească, mai degrabă decât încercarea de a face totul perfect prima dată și mai mult decât orice, și niciodată nu a atins.

Cu aceasta ne confruntăm destul de bine. Dedicăm suficient timp refactoring și îmbunătățirea design-existente, și foarte rar de design detaliat pentru anii ce vor urma. Uneori putem șurub cu siguranță în sus, având ca rezultat un design săraci, astfel încât crește în restructurează se transformă într-o problemă foarte mare. Dar, în general, suntem pe deplin mulțumiți de această abordare.

În cazul în care o practică TDD, apoi, în linii mari, îmbunătățirea continuă de proiectare se obține prin ea însăși.

Integrarea continuă (integrare continuă)

Pentru a pune în aplicare integrarea continuă, am avut cele mai multe dintre produsele noastre pentru a crea o soluție destul de complicată bazată pe Maven și QuickBuild'e. Acest lucru este extrem de util și salvează o mulțime de timp. În plus, ne-a permis să o dată pentru totdeauna a scăpa de fraza clasic: „dar mi funcționează!“. Serverul nostru continuu de integrare este „judecător“ sau de referință față de care performanța este determinată de toate codul sursă. De fiecare dată când cineva salvează modificările la sistemul de control al versiunii, server de integrare continuă începe să culeagă din nou toate proiectele disponibile și conduce toate testele de pe server. Dacă ceva nu merge bine, serverul este obligat să trimită o notificare tuturor echipelor participanților. Aceste e-mailuri conțin informații cu privire la faptul că, ce schimbări au rupt adunarea, se referă la rapoartele testelor, și așa mai departe. D.

În fiecare noapte serverul construi continuu va reconstrui fiecare proiect nou și publicat pe portalul nostru intern al celor mai recente versiuni ale binarele (EAR, război, și așa mai departe. D. [5]), documentație, rapoarte privind testele, pentru a acoperi testele pentru dependențe între module și biblioteci, și multe altele o mulțime de lucruri utile. Unele proiecte sunt, de asemenea, instalate în mod automat pe serverul de test.

Pentru a face lucrurile să meargă, trebuia să-și petreacă o mulțime de timp. dar crede-mă, a meritat.

Proprietatea comună de cod (cod de proprietate colectivă)

Susținem proprietatea comună a codului, chiar dacă nu toate echipele noastre au pus în aplicare această practică. În propria noastră experiență, am văzut că programarea pereche și schimbarea constantă a perechilor crește automat nivelul de co-proprietate a codului. O echipă care au dreptul de proprietate comună a codului la un nivel ridicat, s-au dovedit a fi cea mai înaltă fiabilitate. De exemplu, niciodată nu reușesc sprintează de faptul că ei au pe cineva bolnav.

informativ spațiu de lucru

Toate echipele au acces la bord și pereții neocupate, pe care le-a făcut plăcere. În multe camere pereții sunt agățate cu tot felul de informații despre produs și proiectul. Cea mai mare problemă pe care o avem - acumularea în mod constant nedorită pe pereți. Deja gândit să aibă un rol de „servitoare“, în fiecare echipă.

Deși încurajăm utilizarea sarcinilor consiliului, nu toate echipele le-au pus în aplicare (a se vedea. P. 43, „Așa cum am echipat camera de echipa“)

Recent, am început să identifice standardele de codificare. Foarte util - nu a fost deja făcut atât de rău. Aceasta nu ia mult timp, începe cu un simplu și completat treptat. Notați doar ceea ce poate fi înțeleasă nu toate în același timp, dacă este posibil, nu uitați să facă referire la materialele existente.

Aici este un fragment mic din standardele noastre de codificare:

• Este posibil să încălcați oricare dintre aceste reguli, dar trebuie să existe un motiv bun și acest lucru trebuie să fie documentate.

• În nici un caz nu trebuie să prind excepții, fără a salva programul de stiva de apel plin (stiva urme), sau re-genera o excepție (rethrow). utilizarea log.debug acceptabilă (), pur și simplu nu pierde stiva de apel.

• Pentru a elimina o legătură strânsă între clase folosi dependența de injecție pe baza setteri (Setter Pe baza Injection) (desigur, cu excepția cazurilor în care o astfel de legare o necesitate).

• Evitați abrevieri. abrevieri bine-cunoscute, cum ar fi DAO, sunt permise.

• Metodele care returnează colecții sau rețele nu ar trebui să se întoarcă nul. Întoarcere colecții și tablouri goale în loc de nul.

ritm constant / lucru energetic

Multe cărți de dezvoltare Agile software susțin că prelucrarea prelungită duce la o scădere a productivității.

După unele experimente nu în totalitate voluntar la acest subiect, nu pot fi de acord doar cu toată inima mea!

Cam acum un an una dintre echipele noastre (cel mai mare) într-adevăr, a lucrat într-adevăr o mulțime de ore suplimentare. calitatea codului a fost teribil, iar cele mai multe ori echipa „stins incendii.“ În testere (care a lucrat, de asemenea, orele suplimentare) nu au avut nici o ocazie de a testa în mod corespunzător sistemului. Utilizatorii noștri erau furioși, iar ziarele erau gata să ne înghită.

Câteva luni mai târziu, am fost capabili de a reduce cantitatea de procesare la un nivel acceptabil. Oamenii nu mai lucrează ore suplimentare (cu excepția crize rare în proiect), și - aici e surpriza! - și productivitatea și calitatea codului îmbunătățit semnificativ.

Desigur, reducerea numărului de ore de lucru nu a fost singurul motiv pentru creșterea productivității și îmbunătățirea codului. Dar suntem siguri că acesta a jucat un rol semnificativ.

Comentarii:

format de fișier, care este folosit pentru a asambla module J2EE (aprox. interpret)