Lipur hugarfar vs lipur fyrirkomulag

https://flic.kr/p/bkcj5q

Mér finnst ítrekað að hugbúnaðarteymi einbeiti sér of vel að kerfum og missi sjónar á grundvallarreglunni. Þetta á sérstaklega við um lipur aðferðafræði. Aðferðir eins og Scrum hafa svo marga aðferðir að þeir sem eru nýir í lipurum týnast alveg. Ég skrifaði þetta upphaflega sem tölvupóst til teymisins míns til að skýra hver skoðun mín á Agile var en ég hef sent það til svo margra nú, að með ráðum Scott Hanselman er ég að breyta því í bloggfærslu.

Ég tel mig nokkuð hæfan til að veita þessa innsýn. Ég er lipur iðkandi frá dögunum þar sem Agile þróun fólst í því að nota skrúfjárn - til að taka í sundur eigin skála og búa til opna sætaáætlun!

Snemma á ferlinum vann ég hjá læknishugbúnaðarfyrirtæki. Við smíðuðum skrifborðshugbúnað til að skoða myndir sem var settur upp á skjáborði læknisins á sjúkrahúsum. Dreifingarferlið fólst í því að ferðast með geisladiska til annarrar borgar og setja upp skjáborðin og myndmiðlarana. Við vorum háð samþykki FDA, þannig að við verðum að byggja upp upplýsingar sem höfðu verið í gegnum FDA-samþykki. Þetta skapaði kjörið umhverfi fyrir ofan foss og aðferðafræði fossa. Allur sérstakur var skrifaður niður, samþykktur, undirritaður og við smíðuðum aðeins eftir þeim forskriftum og þeim forskriftum. Það var ekki fyrr en dev-teymið byrjaði að ferðast með uppsetningarteymið og fylgjast með læknum nota hugbúnaðinn okkar, að við gerðum okkur grein fyrir því að við gætum gert svo miklu betur aðeins ef við gætum talað við viðskiptavininn fyrr í hringrásinni. Við kóðuðum nákvæmar upplýsingar, og afhentum samt eitthvað sem var ekki eins gagnlegt og það gæti hafa verið. Þessi mynd sýnir nokkuð af minni reynslu.

Hvernig hugbúnaðarþróun getur farið úrskeiðis frá https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Í kringum þennan tíma heyrði teymi mitt um eitthvað sem kallast Agile Manifesto og æfingu sem kallast Extreme Programming. Í ljósi þess að það var undirritað af vopnahlésdagum iðnaðarins sem bækur sem við vorum að lesa virkilega lánuðu menn á borð við Martin Fowler og Kent Beck iðkuninni mikla lögmæti. Lið mitt af fimm tók í sundur skálana okkar, dró til okkar forsætisráðherrann (umboð fyrir viðskiptavini okkar) til að koma við hliðina á okkur, setti upp borð með vísitakort og fór til vinnu og bjó til XP þegar við fórum. Við vorum með vikulega skipulagningu og kynningar, fullt af pörun og umræðu. Ég vann í ýmsum endurtekningum og afbrigðum af þessu, í mismunandi fyrirtækjum í um það bil 15 ár. Eitt teymi virtist alls ekki fylgja neinni aðferðafræði, en það var vegna þess að allir liðsmenn voru með djúpan lipur bakgrunn, endurtekning og samvinna var sjálfgefið ástand þeirra í rekstri og þeir þurftu ekki álagsferli að halda.

Svo er Agile um opin gólfplön eða tala mikið? Ef þú ert með uppistand og uppsveiflur geturðu þá haldið því fram að þú sért lipur? Hvar passar Scrum eða TDD inn? Oft lendir fólk of fast í sérstöðu í ferlinu - Scrum eða Kanban? Tvær vikur eða viku sprettur? Ertu virkilega lipur ef þú ert ekki með snyrtingu í bakslagi? Að hafa alist upp við að þróa með virkum hætti með Agile aðferðum, ásamt öðrum hönnuðum sem eru jafn þátttakendur, þróa og aðlaga vinnubrögð, hefur gefið mér góða innsýn og þessi færsla er að bera kennsl á grundvallarreglurnar.

Að vera lipur er að geta komið til móts við þarfir viðskiptavina fljótt. Þýðir það að við skrifum kóða hraðar? Neibb. Við getum ekki slegið lög um eðlisfræði og traust fjölvirkni forrit tekur tíma að byggja upp.

Það sem við þurfum að gera er

  1. Auðkenndu nauðsynleg viðskipti vandamál sem við viljum leysa með kóða
  2. Skilaðu fræðilega lausn fljótt til að prófa tilgátuna
  3. Taktu eftir og aðlagast eftir því sem þarfir breytast, eða við lærum meira
  4. Gerðu það í samvinnu, við viðskiptavini sem er þátttakandi hluti teymisins

Allt annað sem við gerum er að gera 2 og 3 hér að ofan minna sársaukafullar - að vita hvort við erum að mæta þörfinni eins fljótt og auðið er, og ef ekki getum við breyst hratt. Ef þú hefur ákveðið að smíða (vs kaupa) ertu að skrifa sérsniðinn hugbúnað. Þetta þýðir að það hefur sérhæfðar kröfur og umhverfi.

Að fá eitthvað sýnilegt, jafnvel þó það sé lítill hluti af virkni, fyrir framan viðskiptavininn eins fljótt og auðið er, gerir okkur kleift að fá endurgjöf fljótt. Þetta er ástæðan fyrir því að ég er talsmaður þess að einbeita mér að því að byggja upp litla sneið af eiginleikanum, frá lokum til enda og fá það alla leið til framleiðslu. Segðu að þú sért að smíða síðu fyrir umboðsmenn þína til að sjá öll gögn um viðskiptavin. Í stað þess að eyða miklum tíma í að rannsaka gagnaheimildir fyrir alla síðuna og skrifa öll API-skjölin fyrst skaltu reyna að fá hlutmengi af gögnum á síðunni alla leið til framleiðslu. Þú verður að vera fær um að nota samþættingar- og dreifingaraðferðir þínar, þú getur byrjað að fá álit á umgjörð HÍ, hvernig þessi síða passar við afgang þinn af umsókninni o.s.frv. Þessum hlutum er auðveldara að laga þegar þú ert með lítið magn af kóða, öfugt til þegar þú hefur smíðað heilan API ramma.

Hér eru nokkur önnur aðferð sem eru nauðsynleg fyrir lipurð

Sprints: Þróun í tímaboxuðum lotum, gerir okkur kleift að skoða og laga og fella ný gögn með reglulegu millibili til að tryggja að við vinnum ennþá að viðeigandi eiginleikum. Hugbúnaður er ábyrgð. Við ættum aðeins að byggja upp það sem við þurfum og geta bætt við það sem þarf, þegar þess er þörf. Þess vegna er mikilvægt að skoða reglulega það sem við höfum byggt hingað til og hvert við erum að fara næst. Þetta leiðir til annars atriðis.

Í ljósi þess að við erum að skipuleggja að meta og breyta stöðugt ætti að vera auðvelt að breyta hugbúnaðinum okkar. Hvað ef viðskiptavinur byrjaði að nota forritið að þeir vildu að nokkur gögn birtust á annan hátt en upphaflega var hannað? Gætum við gert það án þess að snerta allt hitt á síðunni? Eða við þurfum að hringja í annað API til að fá gögn - gætum við gert þá breytingu á öruggan hátt? Þetta er þar sem góðir þróunarhættir og aðferðir koma inn

Einingapróf: Við höfum sjálfvirkar prófanir á ýmsum stigum svo það er öryggisnet fyrir breytingar. Það er líka mikilvægt að vera með í huga hvað einingaprófin raunverulega prófa. Einingapróf ættu að prófa rökfræði. Ef þú tekur ofangreint dæmi, að nota annað API til að fá gögn, helst ætti ekki að þurfa að breyta einingaprófunum fyrir API okkar sem þjónar gögnum við HÍ. Einingapróf eru til til að veita þér sjálfstraust til að endurvirka kóðann, sem aftur veitir þér frelsi til að skrifa aðeins það sem þú þarft núna, og hvíla þig seinna, ekki að framleiða einhver 100% umfjöllunarmat hvort sem þú getur.

CI / CD: Þetta gerir okkur kleift að stytta fjarlægðina milli skuldbindingar og afhendingar. Þetta er mikilvægt fyrir lipurð. Þegar hindranir við dreifingu eru fjarlægðar, og við getum ýtt á litlar breytingar á framleiðslu, er hætta á breytingum lækkuð til muna. Ef dreifing er leiðinlegur eru þær sjaldnar. Sjaldgæfari dreifing ýtir tonn af breytingum, snertir stórt yfirborðssvæði og eru því áhættusamari. Ef þú lærir meira um hvers vegna flutningur hugbúnaðar skiptir máli og hvaða mælikvarða á að nota til að hámarka það, þá mæli ég mjög með þessari bók eftir Nicole Forsgren.

Aðgreining áhyggjuefna: Lauslega tengdur arkitektúr er nauðsynlegur fyrir hugbúnað sem auðvelt er að breyta. Það dregur úr yfirborði breytinga. Smásjárþjónusta og ílát eru nokkrar af þeim aðferðum sem notaðar eru til að beita aðskilnaði áhyggjuefna. Það er mikilvægt að muna þetta og vera viss um að hafa aðskilnað áhyggna í huga þegar þú byggir API, íhluti og forrit.

Mundu
Auðvelt er að breyta góðum kóða

Auðveldlega er hægt að eyða betri kóða

Besti kóðinn er sá sem alls ekki var skrifaður

Það er mikilvægt að bitarnir sem þú býrð til uppfylli raunveruleikann eins fljótt og auðið er, svo að þú vitir hvernig nýju bitarnir þínir þurfa að líta út og þú eyðir ekki tíma í að gera óþarfa bita.