Agiilne mõtteviis vs Agile mehhanismid

https://flic.kr/p/bkcj5q

Olen korduvalt leidnud, et tarkvarameeskonnad keskenduvad liiga palju mehhanismidele ja kaotavad põhiprintsiibi silmist. See kehtib eriti Agile metoodikate kohta. Sellistel meetoditel nagu Scrum on nii palju mehhanisme, et noored, kes on uudsed, kaovad täielikult. Kirjutasin selle algselt oma meeskonnale meilisõnumina, et selgitada, milline oli minu vaade Agile'ile, kuid saatsin selle nüüd nii paljudele inimestele, et Scott Hanselmani nõuandeid arvesse võttes teen selle ajaveebi postituseks.

Leian, et olen selle teadmise andmiseks mõneti kvalifitseeritud. Olen vilgas praktik nendest päevadest, kus Agile arendamine hõlmas kruvikeeraja kasutamist - oma kabinete lammutamiseks ja avatud istumisplaani koostamiseks!

Oma karjääri alguses töötasin meditsiinilise tarkvara firmas. Ehitasime piltide ülevaatamiseks töölaua tarkvara, mis installiti haiglates arsti töölauale. Kasutuselevõtu protsess hõlmas CD-dega reisimist teise linna ning töölaudade ja pildiserverite installimist. Meie suhtes kohaldati FDA heakskiitu, nii et pidime tuginema FDA heakskiidu saanud spetsifikatsioonidele. See lõi ideaalse keskkonna ülalt-alla juga metoodika jaoks. Kõik andmed kirjutati alla, kiideti heaks, kirjutati alla ja me ehitasime neid ja ainult neid andmeid. Alles siis, kui dev-meeskond hakkas koos paigaldusmeeskonnaga reisima ja kui me jälgisime, kuidas arstid meie tarkvara kasutavad, mõistsime, et saame teha palju paremini ainult siis, kui saame kliendiga tsükli alguses rääkida. Kodeerisime täpsed andmed ja edastasime siiski midagi, mis polnud nii kasulik kui oleks võinud. See graafik näitab mõnda minu kogemust.

Kuidas saab tarkvaraarendus minna valesti, leiate aadressilt https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Umbes sel ajal kuulis minu meeskond millestki, mida nimetatakse Agile manifestiks ja Extreme Programmingu praktikast. Arvestades, et selle allkirjastasid tööstusveteranid, kelle raamatuid me aktiivselt lugesime, andsid sellised inimesed nagu Martin Fowler ja Kent Beck praktikale palju legitiimsust. Minu viieliikmeline meeskond demonteeris meie kapid, tõmbas sisse PM-i (meie kliendi volikirja), et tulla meie kõrvale istuma, üles seadma indekskaartidega tahvli ja minema tööle, moodustades XP, kui mööda läksime. Meil oli iganädalane kavandamis- ja demonstratsioonitsükkel, palju sidumist ja arutelu. Töötasin selle erinevates iteratsioonides ja variatsioonides erinevates ettevõtetes umbes 15 aastat. Tundus, et üks meeskond ei järginud üldse metoodikat, kuid see oli tingitud asjaolust, et kõik meeskonna liikmed olid sügavast habras taustast, iteratsioon ja koostöö olid nende vaikimisi tööseisund ning nad ei vajanud pealesunnitud protsessi.

Nii on Agile avatud põrandaplaanide osas või räägib palju? Kui teil on ooteaegu ja tagasivaateid, kas võite väita, et olete agar? Kuhu Scrum või TDD sobib? Sageli haaravad inimesed protsessi spetsiifikast liiga palju - Scrum või Kanban? Kaks nädalat või üks nädal sprint? Kui teil pole peibutamist, kas olete tõesti agar? Olles üles kasvanud aktiivsete arendustegevuses, kasutades Agile meetodeid, teiste arendajatega võrdselt kaasatud, arendades ja kohandades tavasid, on see andnud mulle hea ülevaate ja see ülesanne on selgitada välja peamised põhimõtted.

Kiire olemine suudab klientide vajadusi kiiresti täita. Kas see tähendab, et kirjutame koodi kiiremini? Ei. Me ei saa füüsikaseadustest üle ega ümber ja tugeva multifunktsionaalse rakenduse loomine võtab aega.

Mida me peame tegema, on

  1. Tehke koodiga kindlaks olulised äriprobleemid, mida tahame lahendada
  2. Pakkuge hüpoteesi kontrollimiseks kiiresti teoreetiline lahendus
  3. Jälgige ja kohandage, kui vajadused muutuvad, või saame rohkem teada
  4. Tehke seda koostöös kliendiga meeskonna kaasatud osaga

Kõik muu, mida me teeme, on ülaltoodud 2 ja 3 muutmine vähem valusaks - teada saada, kas täidame vajaduse nii kiiresti kui võimalik ja kui ei saa kiiresti muutuda. Kui olete otsustanud ehitada (vs osta), kirjutate kohandatud tarkvara. See tähendab, et sellel on erinõuded ja keskkonnad.

Millegi nähtavaks saamine, isegi kui see on funktsionaalsuse väike alamhulk, võimaldab kliendi ees võimalikult kiiresti tagasisidet saada. Seetõttu propageerin alati keskendumist väikese lõigu üles ehitamisele ja selle tootmisele jõudmisele. Oletame, et ehitate oma tugiteenuste esindajatele lehe, kus näete kõiki kliendi andmeid. Selle asemel, et kulutada palju aega kogu lehe andmeallikate uurimisele ja kõigepealt kõigi API-de kirjutamisele, proovige kogu tootmiseni hankida lehe alamhulk. Saate kasutada oma integreerimis- ja juurutamismehhanisme, võite saada tagasisidet kasutajaliidese raamistiku kohta, kuidas see leht sobib ülejäänud rakendusega jne. Neid asju on lihtsam kohandada, kui teil on väike kogus koodi, mitte kuni olete ehitanud kogu API raamistiku.

Siin on mõned muud mehhanismid, mis on paindlikkuse jaoks hädavajalikud

Sprindid: arenenud aegruumides tsüklid võimaldavad meil kontrollida ja kohandada ning regulaarsete ajavahemike järel uusi andmeid lisada, tagamaks, et töötame endiselt asjakohaste funktsioonide kallal. Tarkvara on vastutus. Peaksime üles ehitama ainult selle, mida vajame, ja suutma vajadusel lisada ka seda, mida vaja. Seetõttu on oluline regulaarselt vaadata, mida oleme seni ehitanud ja kuhu läheme järgmisena. See viib teise punkti juurde.

Arvestades, et plaanime pidevalt hinnata ja muuta, peaks meie tarkvara olema lihtne muuta. Mis siis, kui pärast seda, kui klient on rakendust kasutama hakanud, soovivad nad, et mingid andmed kuvataks teisiti kui algselt kavandatud? Kas saaksime seda teha ilma, et puudutaksime kõike muud lehel? Või peame andmete saamiseks helistama teisele API-le - kas me saaksime selle muudatuse ohutult teha? Siit jõuavad head arendustavad ja -mehhanismid

Ühiktestimine: meil on automatiseeritud testimine erinevatel tasanditel, nii et muudatuste jaoks on olemas turvavõrk. Samuti on kriitiline olla tähelepanelik selle suhtes, mida üksuse testid tegelikult testivad. Ühiktestid peaksid kontrollima loogikat. Kui võtate ülaltoodud näite, ei tohiks andmete saamiseks teise API kasutamine ideaaljuhul nõuda meie kasutajaliidese andmeid teenindava API ühikutestide muutmist. Ühiktestid on olemas, et anda teile enesekindlus koodi uuendamiseks, mis omakorda annab teile vabaduse kirjutada ainult seda, mida praegu vajate, ja puhata hiljem, et mitte niikuinii 100% katvusmõõdikut koostada.

CI / CD: See võimaldab meil lühendada kohustuste ja kättetoimetamise vahelist vahemaad. See on paindlikkuse jaoks hädavajalik. Kui kasutuselevõtu tõkked on eemaldatud ja saame teha väikeseid muudatusi tootmises, on muutustega seotud risk oluliselt vähenenud. Kui juurutamine on tüütu, on neid harvem. Harvem kasutuselevõtt lükkab palju muudatusi välja, puudutades suurt pinda ja on seetõttu riskantsem. Kui saate lisateavet selle kohta, miks tarkvara tarnimise jõudlus on oluline ja millist mõõdikut selle optimeerimiseks kasutada, soovitan seda Nicole Forsgreni raamatut.

Murede lahusus: Kergesti muudetava tarkvara jaoks on hädavajalik nõrgalt seotud arhitektuur. See vähendab muutuste pindala. Mikriteenused ja konteinerid on mõned mehhanismidest, mida kasutatakse murede eraldamiseks. Rakendusliideste, komponentide ja rakenduste loomisel on oluline seda meeles pidada ja kindlasti pidage silmas murede lahusust.

Pidage meeles
Hea koodi saab hõlpsasti muuta

Paremat koodi saab hõlpsalt kustutada

Parim kood on see, mida polnud üldse kirjutatud

On oluline, et teie loodud bitid vastaksid reaalainele nii kiiresti kui võimalik, nii et teate, millised peaksid teie uued bitid välja nägema, ja te ei raiska aega tarbetute bittide tegemisele.