Ko razvijalec programske opreme zasliši novice o 'novem okviru JavaScript' ali 'novem IDE', mu ni treba postavljati več vprašanj, da bi razjasnil, za kaj gre. Če pa sliši za 'nov gibčen okvir', bo verjetno Homer-Simpsonian prikimal, pretvarjajoč se, da ve, za kaj gre, vendar bo imel eno in samo eno vprašanje: Kaj za vraga pomeni 'gibčen okvir'?

V sodobnem okolju za razvoj programske opreme vedno pogosteje slišimo besede, kot so 'gibčen', 'scrum' in 'kanban', ki jih pogosto uporabljamo neprimerno. V tem članku bom poskušal razložiti in pojasniti nekatere od teh izrazov.

Okretna

Če želite biti pametnejši v množici, uporabite besedo 'okreten' v vseh drugih stavkih, ko govorite o delovnem procesu. Ima precej širok razpon, ne obvezuje vas, da veste veliko o temi, o kateri govorite, in je res lep pridevnik ali prislov: 'gibčno razmišljanje', 'gibčen pristop', 'po agilnih načelih.' Toda kaj v resnici pomeni 'okreten'?

'Agile' se nanaša na ' agilen razvoj programske opreme , «Pristop k razvoju, ki sledi agilnim načelom. Kaj za vraga so 'okretna načela?' Poglej okretni manifest in na 12 načel agilnosti , ki postavljajo temelje gibčnega razvoja. Iz manifesta:

Posamezniki in interakcije nad procesi in orodji
Delovna programska oprema obsežno dokumentacijo
Sodelovanje s strankami čez pogajanja o pogodbi
Odziv na spremembe nad sledenjem načrtu

Agilna načela spodbujajo nenehno zagotavljanje delujoče programske opreme, tesno komunikacijo med skupinami in visoko prilagodljivost spreminjajočim se potrebam. Če pri svojem delu upoštevate te vrednote in načela, lahko rečete, da delate v gibčnem okolju. Agilen razvoj programske opreme torej ni metodologija, je le skupek različnih metodologij, okvirov in tehnik, ki sledijo istim načelom. Lahko rečemo, da je 'gibčnost' okvir za razmišljanje in odločanje.

Agile je okvir za razmišljanje in odločanje.

Toda zakaj je pri našem delu tako pomembno upoštevati ta načela?

Manifest in načela so rezultat iskanja najboljših rešitev, ki so se skozi desetletja razvijale kot odgovor na izzive razvoja programske opreme. V sedemdesetih, osemdesetih in devetdesetih letih so različni razvijalci in ekipe po vsem svetu eksperimentirali z metodami dela in pristopi k reševanju problemov, izumljali različne okvire in tehnike (kot sta scrum in ekstremno programiranje) in celo prihajali do istih ideje vzporedno. Končno se je februarja 2001 sedemnajst razvijalcev zbralo in našlo skupne imenovalce za vse te raznolike ideje in izkušnje. Tako je nastal manifest.

Agile Manifest je rezultat različnih izkušenj in praktičnih rešitev, ki so se pojavile v desetletjih.

Scrum

Če se pogovarjate o 'okretnih' metodah, ne da bi vedeli, kaj pomenijo, lahko zdrsnete in pred sogovornikom, ki pozna zadevo, rečete stvari, ki vas bodo razkrile: 'Scrum in druge agilne metodologije.'

Scrum ni metodologija , čeprav smo vsi že slišali, da se tako pogosteje imenuje kot število umorov v Igra prestolov . Scrum ne bo odgovoril na vsako vprašanje in vam ne bo zagotovil natančnega postopka za odziv na vsako situacijo, s katero se soočate. In verjetno je zaradi te napačne razlage tudi večina izvedb scrumov napačnih: ekipe ne dobijo vrednosti. Posledica tega je verjetno najbolj neumna izjava o scrumu: 'Scrum ne deluje.'

Kaj je scrum? Scrum vodnik definira scrum kot:

„Okvir, v katerem se lahko ljudje lotevajo zapletenih prilagoditvenih problemov, hkrati pa produktivno in ustvarjalno ponujajo izdelke z najvišjo možno vrednostjo.“

Torej je okvir , in tako kot kateri koli drugi okvir se lahko uporablja in se redno uporablja napačno. Učinkovita uporaba scruma ne zahteva le sprejetja strukture, ki jo je določil scrum, temveč globoko razumevanje in spoštovanje agilnih načel v celotni ekipi.

Scrum je sestavljen iz naslednjih vlog: lastnik izdelka, mojster Scrum, razvojna skupina.

Obstajajo tudi štiri Scrum slovesnosti: Načrtovanje srečanja, Dnevni Scrum, Sprint Review, Sprint Retrospective

In trije artefakti: Product Backlog, Sprint Backlog, Product Increment.

Scrum projekti so organizirani v običajne časovne okvire, ki jih imenujemo sprinti. Običajno trajajo dva tedna.

kakšnih je 5 načel oblikovanja

TO Lastnik izdelka je odgovoren za vodenje usmeritve projekta. Ko se določijo nove naloge in funkcije, jih lastnik postopka doda v zaostanek izdelka. Šprint se začne s sestankom za načrtovanje, kjer razvojna skupina iz naloge izbere naloge, ki jih bo obdelala, in načrtuje, kako jih bodo izvedli. Temu sledi razvoj, med katerim razvojna skupina uporablja zaostanke za sledenje napredku in se sestaja na dnevnem sestanku, da sinhronizira dejavnosti in po potrebi prilagodi načrt. Rezultat razvoja bi moral biti prirastek izdelka, nekaj, kar je mogoče uporabiti za izdelek in takoj sprostiti. Na koncu sprinta se prirastek izdelka predstavi lastniku izdelka na pregledu sprinta, kjer se zaostanek izdelka poveča, če so potrebne nadaljnje spremembe. Nato se celotna ekipa udeleži sprint retrospektive, kjer govori o delovnem procesu in kako ga je mogoče izboljšati.

Preprosto se je naučiti in razumeti, vendar ga je težko sprejeti. Obstaja veliko razlogov, zakaj je ta okvir lahko ali pa tudi ne primeren za projekt. Pogosto zahteva veliko sprememb, ne samo v vsakdanjem razvoju, ampak tudi v kulturnem smislu. Scrum se najbolje prilega razvoju kompleksnih izdelkov, ki trajajo dlje časa in vključujejo različne vrste strokovnjakov.

Zakaj je scrum tako priljubljen in zakaj ima prednost pred tradicionalnim modelom slapov? Preprosto povedano, ker prinaša večjo vrednost izdelku in kupcem. Pri 'težkih' metodah, kot je slap, je na pretek grozljivk, v katerih mesecev nihče ne vidi ničesar od projekta. S scrumom to ni mogoče.

Scrum je vse o vrednost ki se dostavi končnim uporabnikom. Če resnično uporabljate scrum, morate vsak sprint dostaviti nekaj dragocenega. Vrednost je mogoče izmeriti, ekipa pa je tudi prisiljena pregledati ovire in se prilagoditi, da bi v naslednji ponovitvi dosegla večjo vrednost.

Pri večini razvoja programske opreme ne gradimo nebotičnika; ni nam treba pripraviti celotnega načrta, preden začnemo, in se tega načrta držimo do konca. Razvijamo programsko opremo in se lahko med razvojem prilagodimo različnim situacijam in spremenimo zahteve izdelka. Številni razvijalci so to dolgo videli kot osmi smrtonosni greh, vendar je z vidika izdelka to velika prednost za optimizacijo predvidljivosti in nadzor tveganja. Scrum je razvit okrog te sposobnosti, njegovo izvajanje pa daje zanesljiv in učinkovit način za obvladovanje potrebnih sprememb.

V povezavi s scrumom se uporabljajo številne tehnike: načrtovanje pokra, programiranje v parih, testni razvoj (TDD), vedenjsko usmerjen razvoj (BDD) in drugi. V resnici niso del scruma, temveč bolj združljive tehnike. Ena od metod, ki se pogosto omenja hkrati s scrumom, je kanban in obstaja veliko zmede glede tega, kaj ti dve stvari pomenita med seboj.

Kanban

Ko govorite o scrumu in kanbanu, bo eno pogosto zastavljenih vprašanj iz množice: 'Kaj je bolje, scrum ali kanban?' In ne boste vedeli, kaj odgovoriti, saj je tako kot primerjati jabolka in pomaranče ali vprašati: 'Kaj je bolje, palačinke ali pivo?' Oba sta boljša.

Kanban je preprosta metoda, ki si prizadeva za pravočasno dostavo, hkrati pa ne preobremeni članov ekipe. Podobno kot scrum je v tem, da je cilj na koncu zagotoviti največjo vrednost, vendar je veliko bolj prilagodljiv kot scrum.

Skupnost za razvoj programske opreme ni izumila Kanbana. Dejansko izvira iz proizvodnih procesov v Toyoti in se široko uporablja na drugih področjih. Ni strogih postopkov, ki bi se jih morali držati, in nobenega strogega načina izvajanja in uporabe kanbana; to je nabor načel in praks, med katerimi lahko izbirate glede na svoje potrebe. Vendar obstaja ena najpogosteje uporabljenih izvedb kanbana pri razvoju programske opreme, ki vključuje uporabo a kanban deska , sestavljen iz stolpcev, ki predstavljajo faze dela in naloge.

Stolpci predstavljajo stanje naloge v razvojnem procesu. Najpreprostejši primer je sestavljen iz treh stolpcev: »Opraviti«, »V teku« in »Končano«. Torej, naloge se dodajo v »To Do«, premaknejo se v »In progress«, ko se razvoj začne, in se štejejo za »Done«, ko se premaknejo v zadnji stolpec. Seveda pa bi lahko bilo bolj zapleteno:

Zaostanek → Določitev specifikacije → Pripravljen za razvoj → Razvoj → Pregled kode → Testiranje → Razporejeno (→ Nihče ga v resnici ne uporablja → Popolnoma odstranjeno).

Vsak stolpec ima lahko pod stolpce; na primer 'Razvoj' lahko razdelimo na 'Načrtovanje' in 'Kodiranje'; »Testiranje« lahko razdelimo na »Enotno testiranje« in »Integracijsko testiranje« itd. Po potrebi so stolpci namenjeni strokovnjakom. Ekipa določi stolpce in stopnje glede na svoje potrebe. Po filozofiji „vlečenja“ naj bi naloge v delovni tok vstopile šele, ko je povpraševanje po njih takojšnje.

Namen te plošče je vizualizirajte potek dela , kar je prva ključna praksa v kanbanu. Pravzaprav je kanban mogoče sploh brez plošče! Lahko gre za preprost seznam nalog v Googlovem listu z različnimi barvami ozadja, ki označujejo stanje naloge, ali pa za Ganttove diagrame, diagrame, tabele ... Lahko celo za sklope vedrov v vaši pisarni, kjer vsak predstavlja stanje naloge in kje se kroglice uporabljajo kot naloge. Samo vizualizirajte potek dela in zagotovite preglednost celotnega procesa.

Drugo pomembno načelo je, da zmanjšajte velikost svojih prizadevanj . Poenostavljeno to pomeni, da se izogibajte večopravilnosti. To lahko pomeni zmanjšanje obsega nalog, s katerimi hkrati delate. Če imate v skupini tri oblikovalce, lahko skupina v stolpcu »Oblikovanje« nastavi največje število nalog na tri.

Tako kot scrum tudi kanban vidi ekipo kot najpomembnejšo osebo v procesu. Toda to ne predlaga vlog kot scrum, obstoječe vloge pa lahko obdržite, da se izognete spreminjanju obstoječega procesa. Enako velja za nenehno izboljševanje: Kanban vas na splošno spodbuja k nenehnemu učenju in izboljševanju, vendar ne predpiše določenega dogodka samo za ta postopek, tako kot Scrumova Sprint retrospektiva.

Katero naj uporabim?

Scrum in kanban se med seboj ne izključujeta in v resnici ne moreta primerjati. V scrumu so določene vloge, medtem ko kanban pravi: 'Za vraga, ohrani svoje trenutne vloge in odgovornosti.' Scrum vas bo prisilil, da spremenite svoj način dela; kanban vam omogoča, da začnete z obstoječim postopkom. V skrumu okvir določa jasen razpored dogodkov; v kanbanu nimaš dogodkov. Vendar imajo veliko podobnosti: oba sta vrednotna, člani ekipe so spoštovani kot 'šefi' sistema in v bistvu imajo isto poslanstvo: nenehno odstranjevati odpadke in odstranjevati ovire.

Toda vprašanje: 'Kaj naj uporabim v svojem projektu in s svojo ekipo?' je veliko bolj smiselno. Kanban ne zahteva toliko procesa in kulturnih sprememb in v večini primerov ga bo lažje sprejeti kot prepir. Scrum pa ponuja bistveno več strukture za vodenje postopka, kar lahko odpravi veliko režijskih stroškov, če so vsi na isti strani.

A lepota obeh je v tem, da nobena ni strog niz pravil. Nič vam ne preprečuje, da bi izbrali najboljše scrum elemente za vas, na primer dnevno srečanje ali pregled. Nobenega razloga ni, da v scrum ne morete vključiti kanban table.

Scrum se je izkazal za zelo učinkovit okvir, ko ga celotna ekipa dobro razume. Vendar po mojih izkušnjah težko sodelujem z nekaterimi strankami. Proces in kulturne spremembe, potrebne za pravilno izvajanje scrum-a, so lahko preveč (še posebej, če imamo opravka z nekom, ki verjame, da ustvarja nov Google!). Po drugi strani je kanban bolj prilagodljiv in ljudi ne sili k spremembam. Nekateri avtorji pravijo tudi, da je kanban dobra pot do gibčnosti in ponuja lažjo izvedbo scruma. Drugi pravijo, da bi uporaba scrum-a na koncu pripeljala do kanbana.

Resnica je, da je vsak projekt drugačen in ni enotne rešitve za vse. Kot vodja projekta morate sami določiti, kaj najbolje ustreza vaši ekipi.

dohodkov pravnih oseb in c dohodkov pravnih oseb