Agile miselnosti in Agile mehanizmi

https://flic.kr/p/bkcj5q

Vedno znova ugotavljam, da se programske ekipe preveč osredotočajo na mehanizme in izgubijo vid nad osnovnim načelom. To še posebej velja za Agile metodologije. Metode, kot je Scrum, imajo toliko mehanizmov, da se tisti, ki so novi na agilu, popolnoma izgubijo. Prvotno sem to napisal kot e-poštno sporočilo svoji ekipi, da bi razjasnil, kakšen je bil moj pogled na Agile, vendar sem ga zdaj poslal toliko ljudem, da upoštevam nasvete Scotta Hanselmana, to spremenim v objavo na blogu.

Menim, da sem nekoliko usposobljen za to vpogled. Sem agilna vaditeljica iz dni, ko je Agile razvoj vključeval izvijač - za demontažo lastnih kabin in oblikovanje odprtega sedežnega načrta!

V zgodnji karieri sem sodeloval s podjetjem za medicinsko programsko opremo. Zgradili smo namizno programsko opremo za pregled slik, ki je bila nameščena na zdravnikovem namizju v bolnišnicah. Proces uvajanja je vključeval potovanje s CD-ji v drugo mesto in namestitev namiznih računalnikov ter slikovnih strežnikov. Zanje smo morali odobriti FDA, zato smo se morali pripraviti na specifikacije, ki so bile pod odobritvijo FDA. Tako je nastalo idealno okolje za metodologijo slapov od zgoraj navzdol. Vsi podatki so bili zapisani, odobreni, podpisani in izdelali smo samo te podatke in le te podatke. Šele ko je skupina za razvoj začela potovati z namestitveno ekipo in opazovati, kako zdravniki uporabljajo našo programsko opremo, smo ugotovili, da lahko naredimo toliko boljše, samo če se lahko s strankami pogovarjamo prej v ciklu. Šifrirali smo natančne podatke in vseeno dostavili nekaj, kar ni bilo tako uporabno, kot bi lahko bilo. Ta grafika prikazuje nekaj mojih izkušenj.

Kako lahko razvoj programske opreme zaide na https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Približno v tem času je moja ekipa slišala za nekaj, kar se imenuje Agileni manifest, in prakso, imenovano Extreme Programming. Glede na to, da so ga podpisali veterani iz industrije, katerih knjige smo aktivno brali, so ljudje, kot sta Martin Fowler in Kent Beck, tej praksi dali veliko legitimnosti. Moja ekipa iz petih je razstavila naše kabine, potegnila PM (proxy za našo stranko), da je sedel zraven nas, postavil tablo z indeksnimi karticami in šel na delo, sestavljal XP, ko smo šli naprej. Imeli smo tedenski cikel načrtovanja in demonstracij, veliko združevanja in razprav. Pri različnih iteracijah in različicah tega sem delal v različnih podjetjih približno 15 let. Zdelo se je, da ena ekipa sploh ne sledi nobeni metodologiji, ampak zato, ker so bili vsi člani skupine iz globokega agilnega ozadja, iteracija in sodelovanje sta bila njuno privzeto stanje delovanja in nista potrebovala vsiljenega postopka.

Ali je Agile o načrtih odprtega nadstropja ali se veliko pogovarja? Če imate stand-up in retros, ali lahko trdite, da ste agilni? Kam se prilega Scrum ali TDD? Pogosto se ljudje preveč ujamejo v specifike postopka - Scrum ali Kanban? Dva tedna ali en teden sprint? Če nimate zaostanka, ali ste resnično agilni? Ko sem odrasel v aktivnem razvoju z uporabo Agile metod, z drugimi razvijalci, ki se enako ukvarjajo, razvijajo in prilagajajo prakse, sem dobil dober vpogled in to delovno mesto je določiti osnovna načela.

Agile lahko hitro zadovolji potrebe strank. Ali to pomeni, da pišemo kodo hitreje? Ne. Ne moremo premagati zakonov fizike in za izgradnjo trdne večfunkcijske aplikacije je potreben čas.

Kar moramo storiti je

  1. Prepoznajte bistvene poslovne težave, ki jih želimo rešiti s kodo
  2. Hitro ponudite teoretično rešitev za preizkus hipoteze
  3. Če se potrebe spreminjajo, se prilagajamo ali prilagajamo nanje ali se še več učimo
  4. Naredite to v sodelovanju, s stranko je angažiran del ekipe

Vse drugo, kar naredimo, je, da sta zgoraj navedeni 2 in 3 manj boleči - da vemo, ali čim prej zadostimo potrebi in če se ne bomo mogli hitro spremeniti. Če ste se odločili za gradnjo (proti nakupu), pišete programsko opremo po meri. To pomeni, da ima specializirane zahteve in okolja.

Če opazimo nekaj vidnega, četudi gre za majhno podmnožico funkcionalnosti, pred stranko čim prej omogočimo hitrejše povratne informacije. Zato se vedno zavzemam za to, da se osredotočim na to, da zgradim majhen delček funkcije, od konca do konca in da to dosežem vse do produkcije. Recimo, pripravljate stran za svoje podporne zastopnike, da vidijo vse podatke o stranki. Namesto da bi porabili veliko časa za raziskovanje virov podatkov za celotno stran in najprej napisali vse API-je, poskusite pridobiti podmnožico podatkov na strani vse do proizvodnje. Uporabili boste lahko mehanizme za integracijo in uvajanje, začeli boste dobivati ​​povratne informacije o okviru uporabniškega vmesnika, kako se ta stran ujema s preostankom vaše aplikacije itd. Te stvari je lažje prilagoditi, če imate majhno količino kode, v nasprotju s tem do takrat, ko ste izdelali celoten okvir API-ja.

Tu je nekaj drugih mehanizmov, ki so bistveni za okretnost

Sprint: Razvijanje v časovno zaokroženih ciklih nam omogoča pregled in prilagajanje ter vključevanje novih podatkov v rednih presledkih, da zagotovimo, da še vedno delamo na ustreznih funkcijah. Programska oprema je odgovornost. Graditi bi morali le tisto, kar potrebujemo, in biti sposoben dodati tisto, kar je potrebno, ko je potrebno. Zato je bistveno, da redno pregledujemo, kaj smo doslej gradili in kam gremo naprej. To vodi do druge točke.

Glede na to, da načrtujemo nenehno ocenjevanje in spreminjanje, bi bilo treba našo programsko opremo enostavno spremeniti. Kaj pa, če bi stranka po uporabi aplikacije želela, da se nekateri podatki prikažejo drugače, kot so bili prvotno zasnovani? Bi to lahko storili, ne da bi se dotaknili vsega drugega na strani? Ali moramo za pridobitev podatkov poklicati drug API - ali lahko to varno spremenimo? Tu se pojavljajo dobre razvojne prakse in mehanizmi

Preizkušanje enot: Imamo avtomatizirano testiranje na različnih ravneh, tako da obstaja varnostna mreža za spremembe. Pomembno je biti tudi pozoren na to, kaj dejansko testirajo enotni testi. Preizkusi enote morajo preverjati logiko. Če vzamete zgornji primer, če za pridobitev podatkov uporabite drug API, v idealnem primeru ne bi smeli spreminjati preskusov enot za naš API, ki podatke pošilja v uporabniški vmesnik. Preizkusi enot obstajajo, da boste dobili zaupanje v ponovno kodiranje kode, kar vam daje svobodo, da napišete samo tisto, kar zdaj potrebujete, in počivate pozneje, da ne boste ustvarili kakih 100-odstotnih meritev pokritosti.

CI / CD: S tem lahko skrajšamo razdaljo med storitvijo in dostavo. To je bistveno za okretnost. Ko se odstranijo ovire pri uvajanju in lahko spodbudimo majhne spremembe v proizvodnji, se tveganje zaradi sprememb močno zmanjša. Če so uvajanja dolgočasna, so redkejša. Manj pogoste razmestitve izpodrivajo tono sprememb, ki se dotikajo velike površine in so zato bolj tvegane. Če boste izvedeli več o tem, zakaj so pomembne uspešnosti dostave programske opreme in katere metrike uporabite za njeno optimizacijo, toplo priporočam to knjigo Nicole Forsgren.

Ločenost skrbi: ohlapno povezana arhitektura je bistvena za programsko opremo, ki jo je enostavno spremeniti. Zmanjša površino spremembe. Mikroservisi in zabojniki so nekateri mehanizmi, ki se uporabljajo za ločevanje problemov. Pomembno si je zapomniti to in pri gradnji API-jev, komponent in aplikacij ne pozabite upoštevati težav.

Ne pozabite
Dobro kodo je mogoče enostavno spremeniti

Boljšo kodo je mogoče enostavno izbrisati

Najboljša koda je tista, ki sploh ni bila napisana

Bistvenega pomena je, da se biti, ki jih ustvarite, čim prej srečajo z resničnim svetom, tako da veste, kako morajo izgledati vaši novi bitji, in ne zapravljate časa za ustvarjanje nepotrebnih bitov.