Lühidalt

Teie vastutate oma ettevõtte uusima ja parima algatuse elluviimise eest, mis muudab „Widgets Internationali“ nägu igaveseks. See on tarkvaraprojekt, mis kaasab ja köidab teie kliente, muudab teie kolleegide elu lihtsamaks ja teenib ettevõttelt miljoneid tulusid. Seal on palju ootusärevust, innukust, põnevust ja ootusi. Peate selle võimalikult kiiresti ära tegema, et teie ettevõte saaks hakata sellest kasu saama. Ettevõtte edasine edu sõltub sinust. Kõik pilgud on suunatud sinule. Sa ei saa läbi kukkuda.

Alguses mõtlete endamisi: „Äge, ma olen väljakutsega valmis. Teeme selle asja korda! ' Peatute hetkeks, astute tagasi ja mõtlete endamisi: 'Olgu, siis kuidas me seda teeme?' Hakkate rääkima oma kolleegide ja eakaaslastega. Veedate aega parimate tavade otsimiseks tarkvaraarendus ja projekti juht tehnikaid, kuid võimalusi ja lähenemisviise on lugematu arv. Lühendeid ja metoodikaid on palju. Märkimisväärsed tõusevad tippu. Kahtlus hiilib sisse. Kumba peaksime kasutama? Kuidas tagada edu? Mis siis, kui ma teen valesid otsuseid?

Tarkvaraprojektide haldamisel on hämmastav valik võimalusi, mida toetavad hulgaliselt arvamusi. Toanurgast kostvad hääled sosistavad: 'Proovige seda nii teha'; teised hüüavad: 'See on ainus viis seda teha'; ja ülejäänud ainult vinguvad: 'Ära sa sellega üldse hakkama saa, lihtsalt mine edasi.' Tegelikult räägivad kõik need hääled mingit tõde. Kuid oluline on välja selgitada, mis sobib teie vajadustele, meeskonnale, ettevõttele ja klientidele.

Stseeni määramine

Oli aeg, kui tarkvaraprojektide juhtimine istus otse ühes kolmest laagrist. Seal olid rasked raamistikud, mis võimaldavad teil teha otsuseid selle kohta, kuidas te täidate ja mida teete, pakkudes samas struktuuri kontrolli ja valitsemise säilitamiseks. Oli retsepteerivaid järjestikuseid metoodikaid nagu juga see sundis teid kavandama pikki projekte, mõistma kõiki oma nõudeid ja pühenduma neile, kavandama ja allkirjastama keerukad süsteemid, kirjutama palju koode ja seejärel testima (kõik enne, kui teie klient seda esimest korda näeb). Ja lõpuks, vähem ettekirjutavad, kuid korduvad tarkvaraarenduse elutsüklid ( SDLC ), mis soodustavad kiiret prototüüpimist või suuremate süsteemide kavandamist, ehitamist ja järkjärgulist tarnimist, kusjuures mõlemad hooned on üksteise peal.

Vilgas tarkvaraarendus Agile projektijuhtimine sündis juga puudulikkusest ja iteratiivse lähenemisviisi kasutegurist tarkvara edastamisel. Nad saavad oma juured jälgida 1950ndatest, mõttejuhtimisest 70ndatel, küpsusest 90ndatel ja lapsendamisest 00ndatel. 2001. aastal lõi rühm praktikuid ja eksperte programmi Vilgas manifest , mille eesmärk oli määratleda 4 väärtust ja 12 juhtpõhimõtet, mis püüavad kehastada Agile tarkvaraarenduse vaimu ja soodustada selle arengut. Ja see on kindlasti arenenud.

Nüüd pole lihtsalt millegi agaraks nimetamine eriti kasulik. See sõna tähendab isegi tarkvara kontekstis erinevatele inimestele või organisatsioonidele erinevaid asju. Seal on palju tahke, määratlusi, rakendusi ja tõlgendusi. Iga keha, kes Agile'i omaks võtab, üritab sellele anda oma definitsiooni.

Lihtsalt millegi agiilseks nimetamine pole eriti kasulik. Piiksuma

Piisab sellest, kui öelda, et vilgas tarkvaraarendus ja projektijuhtimine on seotud käitumiste, raamistike, tehnikate ja kontseptsioonide rühm, mis soodustab põhimõtteliselt õige töötava tarkvara tarnimist võimalikult varakult ja võimalikult sageli.

on scala raske õppida

Mainisin juba varem, et tarkvara arendamisel või projektijuhtimisel rakendatav Agile võib olla erinev. Lühidalt öeldes hoolitseb Agile tarkvaraarendus suurepärase tarkvara väljatöötamise eest tavapärases äris (BAU) või projekti kontekstis. Agile projektijuhtimine hoolitseb seevastu keerukate projektide, sealhulgas (kuid mitte ainult) tarkvara elluviimiseks vajaliku juhtimise ja kontrolli eest.

Saadaval on palju Agile tarkvaraarendusmeetodeid, näiteks Scrum , Kanban , XP ja Lean tarkvaraarendus . Kuid nagu ragbi mäng on midagi enamat kui rämps, on seda ka Agile. Eraldi ei käsitle need väledad paradigmad kogu projektijuhtimise elutsüklit, mis on vajalik keerulistes projektides, nagu juhtimine, ressursside hankimine, rahaline, selgesõnaline riskijuhtimine ja paljud muud olulised projektijuhtimise kontseptsioonid. Nende jaoks võiksite kaaluda Vilunud VKEd või PRINCE2 Agile - mõelge sellele kui 'juhitavale agiilsusele'.

Miks peame olema väledad?

Juba ammu hulkusime mööda maad, et koguda toitu ja peavarju, et ellu jääda. Need olid lihtsad vajadused, kuid üsna väledad. Mõni aeg hiljem kasvasid ja õitsesid riigid ja majandused Tööstusrevolutsioon . See oli juhtimise ja kontrolli sünd ning väleduse kaotus. Nüüd oleme Infoajastu või revolutsioon , kus ettevõtted palkavad teadmistega töötajaid. Teadmistöötajad olete teie, teie partnerid ning teie kolleegid ja eakaaslased, kes püüavad luua suurepäraseid lahendusi klientide, äri, sotsiaalsetele, majanduslikele ja maailma probleemidele. Teadmistöötajad rakendavad analüüsi, teadmisi, põhjendusi, mõistmist, asjatundlikkust ja oskusi sageli lõdvalt määratletud ja muutuvate vajaduste jaoks. Need ettevõtted ja töötajad vajavad meetodeid ja tehnikaid, millele vanad tööstusajastu protsessid ja protseduurid ei vasta. Vilgas toetab interaktsioone.

Praktiliselt ükski tarkvaraprojekt ei saa alguses enesekindlalt paika panna ja teada kõike, mida see vajab väärtusliku töötava tarkvara muutusteta tarnimiseks. Muudatused pakuvad projekti edule nii võimalusi kui ka riske. Haldamata võimalused võivad tähendada erinevust suurepärase ettevõtte ja ägeda ettevõtte vahel. Haldamata risk tekitab katastroofe ja hävinguid. Agile haldab muutusi.

Agile'i kasutuselevõtt võimaldab teil reageerida muutuvatele või uutele nõuetele. See annab arendusmeeskondadele volituse olla eksperdid ja langetada otsuseid, mida toetab kaasatud, usaldav ja teadlik ettevõte. See võimaldab teil pakkuda klientidele seda, mida nad tegelikult tahavad. Lõppkokkuvõttes paneb see teie ja teie organisatsiooni juhtima kvaliteetset ja väärtuslikku tarkvara, mis täidab klientide vajadusi ja ootusi, tarnimise, pakkudes samal ajal teie investeerimisdollarite tasuvust võimalikult varakult. Vilgas loob väärtust.

Agile'i omaksvõtmine maksab. See ei tule tasuta. Tarkvara edastamiseks Agile lähenemisviisiks muutmine võib olla raske tee. Kui aga sisestate agiilse filosoofia sisemusse, astute ettevaatlikult, kaasate õige suhtumisega õige meeskonna, lõhute asjad, muudate selle saavutatavaks ja realistlikuks ning vastate tagasisidele, saate kasu. Agile rõhutab koostööd.

Järgnevas loetletakse mõned eelised, mida võite oodata:

• Kiirus turule
• Varasem tulu teenimine
• Regulaarse tegeliku väärtuse edastamine
• Kaitse teie investeeringule
• Kuupäev, kuupäev, kuupäev
• Parem toote kvaliteet
• Hallatavad ootused
• Suurem klientide rahulolu
• Kõrgema sooritusega meeskonnad
• Parem nähtavus edusammude osas
• Ettearvatavus, läbipaistvus ja enesekindlus
• Juhitav risk

Edu pole lõplik, ebaõnnestumine pole surmav: loeb jätkamise julgus.

Võib-olla pole Winston Churchill seda tegelikult kunagi öelnud, kuid ma arvan, et see on üsna hea Agile'i kokkuvõte. Me teame, et Agile on enamiku projektide jaoks parim samm edasi. See julgustab teid püüdlema edu poole, kuid me kordame ja jätkame selle jätkamist. Agile julgustab sind ebaõnnestuma, kuid ebaõnnestub varakult ja liigu edasi. Tasu toob julgus jätkata ja luua õige lahendus, mis põhineb teie kliendi teabel.

Peaksite meeles pidama, et saate Agile'i kohandada vastavalt oma vajadustele. Kasutage oma ettevõttele sobivat meetodit ja juhtimist. Olenemata sellest, kust alustate, ole truu kasutatava meetodi sisule, kontekstile ja vaimule - hoidke seda vanillisena. Kui te alles alustate, õppida . Kui olete seda mõnda aega teinud, aru saama . Kui sa muutud ägedaks, kohaldada . Ja kui teie ettevõte ja teie projektid on keerulised ja üksteisest sõltuvad, valitsus . Aja jooksul saate teie ja teie meeskonnad välja selgitada, mis teie ettevõttele kõige paremini sobib.

Teostatavus

Nii et nüüd mõtlete: 'Olgu, ma saan aru. Kuidas ma alustan? Kust ma alustan? ' Noh, kõigi heade asjadega alustame algusest. Ja Agile puhul küsitakse endalt: 'Millist ärilist väärtust ma tahan pakkuda?' Lõppude lõpuks võtame seetõttu ette ettevõtte väärtuse loomiseks projekte. Selleks, et teha kindlaks, kas projekt on väärt ettevõtlusväärtuse saamiseks, peate mõistma, kas see on teostatav.

Visioon

Kas teie projekt peaks prognooside kohaselt suurendama tulusid, sisenema uuele turule, hankima rohkem kliente, parandama klientide taju või hõlbustama teie tuvastatud probleemide jaoks elu? Seda silmas pidades saate öelda oma visiooni.

• Teie visioon võib pärineda erinevatest allikatest - teie enda julge käivitamine levinud probleemi lahendamiseks, ärijuhtimisstrateegia, teie tegevjuhi lemmikloomade projekt, konkreetne tootemeeskond või isegi teie kliendi vajadused.
• Proovige oma kingade juurest samm tagasi astuda ja „näha”, kuidas tulevik teie uue toote või teenusega klientide käes välja näeb.
• Kaasake oma sidusrühmi - tegevjuht, tootepoiss ja kliendid. Töötage see ära, ärge proovige seda eraldi. Väljakutse eeldused ja argumentide kinnitamine.
• Kirjutage see üles, hoidke lühidalt. Keskenduge ettevõtte väärtusele.
• Täpsustage seda seni, kuni olete kõik nõus, et visioon kõlab kõigiga ja vastab levinud tõlgendusele, mis ütleb, kuhu te suundute.
• Teie nägemus, kui see kehtib, muutub harva. Kuidas te sinna jõuate, kindlasti.

Inimesed ei osta seda, mida te teete või kuidas te seda teete. Nad ostavad selle, miks te seda teete. See loob emotsionaalse ühenduse teie ettevõtte ja klientide vahel. Visioon aitab seda illustreerida.

Kas see on teostatav?

Teostatavus on vähemalt paar tooni. Tavaliselt tahate mõista, kas teie visioon teie ettevõtte ja klientide helgemast tulevikust on nii tehniliselt teostatav kui ka see, et teie ettevõte on selle elluviimiseks teostatav.

• Kui teie visioon on teha kõikjal maailmas reisimine vähem kui tunni jooksul, võib teil tekkida probleem tehnilise teostatavusega. Kuna teadus, füüsika ja tehnoloogia pole sellele unistusele veel järele jõudnud, ei pruugi teie tehniline lahendus olla elujõuline mujal kui teoorias. Lisaks, kui teie lahendus oleks uus, läheks see a-ideest kaugemale minimaalselt elujõuline toode (MVP).

• Toote tehnilise otstarbekuse testimiseks kaaluge selle avastamist prototüübi Discovery projektis edasi või käivitage piik projekti varases staadiumis. Millist meetodit kasutada, saate teada mõeldes lahenduse ulatusele või keerukusele.

  „Mõned parimad teadmised, mille minu meeskonnad on tehnilise teostatavuse mõistmisel omandanud, on tulnud piigi sooritamisest. Ja sageli võidab see kõige lihtsama lahenduse! '

• Teiseks kaalutletavaks otstarbekuse varjundiks on see, kas teil, teie meeskonnal või ettevõttel on oskusi ja motivatsiooni selle toimimiseks. Näiteks, kui oskate oma laste sünnipäeval kodus torte küpsetada, on see armas. Kuid kui soovite sellest muuta ettevõtteks, mis müüb maailma parimaid kooke, peate mõistma, kas suudate selle mastaapseks muuta, tegeleda nii ettevõtte kui ka tootmisega, hallata levitamist ja täitmist ning hoolitseda klienditeeninduse eest.
• Seda tüüpi nägemine võib olla pikas perspektiivis saavutatav. Kuid praegu võib-olla mitte. Nii et mõõtke see tagasi, mõelge väikesele, võtke väike tükike, mis näeb välja realistlik, ja keskenduge parima võimaliku väiksema eesmärgi saavutamisele. Kui see õnnestub teie kliente kaasama ja rõõmustama, laske neil rohkem tagasi tulla ja oma sõpradele rääkida, siis suurendage seda sealt, kasutades oma kliendi tagasisidet oma teejuhina ja kompassina.
• Samuti peate teadma, kas teie projekt on eelarve ja ajagraafiku osas teostatav. Kas teie ettevõte saab endale lubada selle projekti elluviimist? Kas ajakava on saavutatav? Aeg ja raha on kaks Agile projekti kolmest fikseeritud piirangust. Meie eesmärk on täita kindla aja jooksul ja kindla eelarve piires.
• Toote kvaliteet viitab lõpptootele, mida teie kliendid kasutavad, ja inseneripraktikatele, mida teie meeskond kasutab suurepärase, kindla ja usaldusväärse tarkvara edastamiseks. Kvaliteet on ka midagi, mida me lühidalt ei muuda. Kvaliteedikriteeriumid võivad seevastu muutuda. Kui te ei kavatse Ferrarit ehitada, ei pruugi see toodet kvaliteetselt tajuda. Kui te ei ehita kosmoserakette, võivad tootmise osas lubatud tolerantsid olla palju suuremad. Pange varakult sobiv toon ja ootus.

Nüüd olete kinnitanud, et teie unistus on enamat kui šokolaadifänn, proovige oma eeldusi testida ja inimestele tõestada, et sellesse ettevõtmisse tasub investeerida.

Selgitus

Nüüd, sõltuvalt teie oludest, on õigustus erinevas vormis. Kuid sisuliselt soovite tõestada, et see projekt vastab klientide edukriteeriumidele, on eduvõimalustega, annab väärtust ja on taskukohane.

• Esitage oma eeldused kliendi vajaduste põhjal ja kinnitage need. The Lean Startup annab suurepäraseid juhiseid selle tuvastamiseks ja tõestamiseks, et teie toode on teie klientidele vajalik ja loob väärtust.

• Kirjutage, testige ja kinnitage oma äriplaan. Nüüd ei tundu see midagi sellist, nagu teie pank või teie äri- ja finantsmajor teile käskis toota. Ärge kasutage neid - need on enne tindi kuivamist aegunud. Selle asemel vaadake Ärimudeli lõuend . See on sisuliselt lühikese vormiga äriplaan, mis hoiab teie tähelepanu väärtuspakkumisel, klientidel, tuludel ja kuludel. Kasutage seda valideerimiseks, kui teil on toimiv ettevõte.

  'Eirasin seda nõu üks kord ja kirjutasin pikka aega pika traditsioonilise 50-leheküljelise äriplaani. See ei viinud mind kuhugi. Kõik minu tehtud eeldused olid alusetud ja kõiki minu tehtud prognoose ei saanud kinnitada. See oli valus ja kallis kogemus, mis õpetas mind seda enam kunagi tegema. ”

• Kui olete küpses ettevõttes ja projektide portfellid viiakse läbi keerulises keskkonnas, võib osutuda vajalikuks finantsmudelid. Kui peate, siis tehke seda alles siis, kui olete ülaltoodud tõestanud.
• Kui olete oma MVP üles ehitanud, võib tekkida vajadus luua traditsioonilisem äriplaan - näiteks kui peate oma ettevõtte konkureerivate projektide ja ressursside portfelli rahastama või valima. Kuid see on äriplaan, mis põhineb ülaltoodud tööriistadel ja on sellest informeeritud. Ka see on kergem.
• Igal juhul kasutage neid tööriistu elavate, hingavate esemetena. Kasutage neid oma teejuhina ja kellamänguna. Need pole kunagi staatilised. Viidake neile ja vaadake neid üle, kui teie projekt või ettevõte areneb.

Kui teil on oma põhjendus olemas ja kõik sidusrühmad on pardal, olete tules.

Teostatavusetapp viiakse tavaliselt läbi üks kord teie projekti elus. Võib juhtuda, et vaatate projekti visiooni ja teostatavuse uuesti läbi, eriti kui teie andmed, kliendid, turg või ettevõte seda näitavad. Vähemalt on need kogu aeg teie suunatuled.

Algatus

Vinge. Otsus on tehtud, projektil on roheline tuli ja olete valmis ehitama. Noh, peaaegu. Ma tean, et mõtlete: 'Kas olete juba, tõesti? Kui me seda nüüd ei tee, ei tee me seda kunagi. Laseme selle saate teele! ' Kuid mõelge sellele - Agile pole midagi muud kui varajase väärtuse andmine ja sageli klientide rõõmustamine. Parim alus edu saavutamiseks on võtta aega, et välja selgitada parim viis projekti elluviimiseks.

Meeskond

Spordis saate oma meeskonnamängu üle mõeldes ära tunda põhirollid, mis võimaldavad meeskonnal nii toimida. Traditsiooniliselt leiate mänedžeri, kapteni ja ülejäänud meeskonna. Peale selle leiate treenerid, füsiod, toitumisspetsialistid ja valiku abipersonali. Aga kui vaadata ragbi mängu, siis meeskonnas on meeskond: mängijad, kes moodustavad nühkima . See pakk koosneb määratud mängijatest, kelle ülesanne on pall tagasi võita ja mängu jätkata. Kui mängus on pall, töötavad kummagi poole mängijad ilma ühegi juhita ühtse üksusena võimalikult koostöös, kommunikatiivselt ja tõhusalt, et pall tagasi oma valdusesse saada. Inspireeris just ragbi mäng Jeff Sutherland nimetada oma tarkvaraarenduse metoodikat 'Scrum'.

• Scrum pole ainus tarkvaraarendusmeetod Agile playbookis. Kuid see kirjeldab kõige paremini agiilset kontseptsiooni ja käitumist meeskonnatööna, indiviidide motiveerimisel, usaldussuhete loomisel, enesekorrastamisel, sulane-juhtimine , suhtlemine, läbipaistvus ja koostöö.
• Teie meeskond moodustatakse suuresti olude sunnil, milles te end tabate arendajad teile kättesaadav. Mõni, ükski või kõik neist võivad olla agiilsed erineval määral tuttavad. Võiksite palgata uue meeskonna või partneri kolmanda osapoole juurde.
• Vaja on ka teisi rolle, kuid arutame neid hiljem.
• On öeldud, et kui teie vorm on teie arendustiim, siis olete valinud oma tehnoloogia. Sõltuvalt sellest, kust koondate oma meeskonna, on neil konkreetsed oskused. Nii et mõelge hoolikalt läbi, kuidas te oma arendustiimi moodustate ja kas peate enne oma reisi sellesse punkti jõudmist tegema tehnilise hindamise.
• See viib meid funktsionaalsete meeskondade juurde. Meeskonnad töötavad kõige paremini siis, kui nad töötavad koos, kui üksikisikud astuvad tööle, et neid teha, hoolimata nende tiitlist. Proovige luua meeskond, kes on isemajandav, ja isikud, kes võtavad endale rohkem kui ühe rolli.
• Ehitage keskkond, kultuur ja suhtekeskus - koht, kus meeskond saab toimetada, piirangutest või piirangutest koormamata. Andke meeskonnale vahendid, inimesed, ressursid ja ruum, et olla tõhus ja tulemuslik.
• Hoidke meeskonna suurust kuni seitsme või kaheksa. Kui teil on vaja veel palju arendajaid, jagage meeskond mitmeks uueks meeskonnaks. Seejärel võib iga meeskond vastutada antud funktsionaalse piirkonna eest. Kui teil on mitu meeskonda mitmes kohas, kaaluge Scrum of Scrumi hoidmist. Ja kui neid on keerulistes keskkondades palju, kasutage Agile'i projektijuhtimist.
• Tagage, et meeskonnal, ettevõttel, sidusrühmadel ja isegi klientidel oleks juurdepääs üksteisele. Veenduge, et nad suhtlevad ja teevad koostööd, ning eemaldage kõik, mis takistab edenemist. Igapäevane suhtlus on parim vaevus projekti vaevuste vastu. Kui inimesed räägivad, saavad nad asjad tehtud.

Meeskonda saab tarkvara edastamiseks kokku panna mitmel viisil.

Projekti lühidalt

Teostatavuse etapis mõtlesite välja oma projekti 'miks' ja suurendasite oma enesekindlust oma käivitusega edasi liikumiseks või said jätkamiseks toetuse. Projekti lühikokkuvõte on elav dokument, mis ühendab 'miks' koos 'mis' ja 'millal' ja 'kes'. See on 'elamine', sest edenedes võivad teie teadmised, mõistmine ja tee muutuda. Kui jätate selle dokumendi üks kord kirjutatuks ja selle juurde ei pöörduta, siis lihtsalt suunate oma mõtted ajahetke. Agiilses maailmas võib teie ajahetke viide muutuda varakult nädalas või isegi iga päev, seega on oluline seda värskena hoida.

• Suurepärane tööriist projekti lühikokkuvõtte säilitamiseks ja säilitamiseks on midagi, mida Jonathan Rasmusson nimetab oma raamatus 'algtekiks' Vilgas samurai . Siit leiate suurepäraseid nõuandeid selle tagamiseks, et kõik teie projektist huvitatud, mõjutatud või sellega seotud inimesed oleksid samal lehel.
• Suurim vaenlane projektide elluviimisel on ebaselge, ebajärjekindel või lihtsalt erinev arusaam sellest, mis projekt on ja millised 'nõuded' peavad olema täidetud. Kui isegi ühel olulisel sidusrühmal on teie tegemistest erinev arusaam või vaade, võivad tagajärjed olla olulised.
• Hea projekti lühikokkuvõte annab teada:
  1. Sidusrühmade ja meeskonnaliikmete ühine ja kokkulepitud ootus.
  2. Projekti mõistmine, sama mõistmine kõigi osapoolte vahel.
  3. Eesmärk, visioon, eesmärk, ulatus ja projekti kontekst.
• Teil on otstarbekuse kohta kogutud ülevaate jaoks palju head teavet. Projekti lühikokkuvõte aitab teil otsitavatele küsimustele määratleda ja vastused leida. See toob kokku sidusrühmad, teie eesmärk , kõrgetasemeline ulatus, riskid, sihtlahendus, eelarve, ajakava, ootused ja prioriteedid.

Kolleeg peatas mind korra koridoris ja küsis, kust ta saaks projekti jaoks projekti lühikokkuvõtte. Ma ütlesin: 'Me ei vaja lühikest ülevaadet, me oleme väledad'. Ta näis segaduses, nagu kahtlustaks mu mõistlikkust või autoriteeti. Tal oli õigus seda teha.

Enne jätkamist veenduge, et olete kõik samale lehele jõudnud, töötage see välja, esitage keerulised küsimused ja kinnitage see kuhugi, kus inimesed saavad peatuda, lugeda, kommenteerida ja aidata seda üle vaadata.

Kultuur ja tööviisid

Teate, kuidas teie ettevõte töötab ja selle kultuuri, kuidas talle meeldib asju ajada. Agile võib oma olemuselt proovile panna mõned neist tööviisidest, mida teie ettevõte on aastate jooksul välja töötanud. Ärge oodake, et Agile rakendatakse ja kõik võtavad selle juba algusest peale armastavalt vastu. Mõni inimene võib seda segadusse ajada ja vaadata ainult hirmu ja hirmuga. Mõni inimene võib avalikult keelduda sellega tegelemast. Need on väljakutsed ja arusaamad, millest peate üle saama. Kuid oma esimestel päevadel ärge liikuge Agile pulgaga vehkides kedagi, kes seda ei kuula. See ei suurenda usaldust, lapsendamist ega seotust.

Fännasin ükskord suurte vanasõnadega pulkade lehvitamist ja see teenis mulle palju negatiivset ajakirjandust. Keerasin selle ümber, kuid mitte enne, kui olin esmalt märkimisväärset valu kannatanud.

Lapsendamise teele asudes tallake ettevaatlikult, lugupidavalt ja empaatiliselt. Kui tegelete vana kriuksuva traditsioonilise ettevõttega, pole see võib-olla parim viis kogu ettevõtte joondamiseks. Alustage väikselt ja pälvige järk-järgult austust ja tunnustust. Alustage ainult oma meeskonnast. Kui hakkate pakkuma kiiremat tarkvara, mis on kvaliteetsem kui kunagi varem, hakkavad inimesed seda märkama ja tahavad tulla teie mängu mängima. Kui nad seda teevad, paku neile palli, võtke kohvi välja ja hõlbustage oma uude maailma. Aita neid.

Nüüd, kui nad teavad, mis projektiga on tegemist ja teie Agile'i lapsendamise plaanid on kokku lepitud, laske meeskonnal otsustada, kuidas nad soovivad käituda ja meeskonnana tegutseda.

• Suunake oma meeskonda tuvastama väledad mõisted, tehnikad, käitumisviisid ja raamistikud, mis teie arvates sobivad teie kollektiivsete vajadustega.
• Võtke oma meeskonnaliikmetelt taotlusi selle kohta, millised nõuded neil on, et aidata neil võimalikult hästi toimida. Mõni neist taotlustest saate kohe lahendada. Teised võivad vajada eelarvet või abi väljastpoolt. Tehke mis võimalik, et see teoks saaks.
• Need on teie esimesed sammud tõeliseks sulaseks-juhiks saamisel.
• Kaaluge mõne sobiva koolituse korraldamist nende kontseptsioonide ja tehnikate osas, mille teie meeskond valib. See on parim viis tagada, et kõik teie meeskonnaliikmed, isegi sidusrühmad, on samal lehel ja saavad sama sõnumi. Tehke koostööd tarnijaorganisatsiooniga, kes saab nende pakkumisi vastavalt teie vajadustele kohandada.
• Ole ettevaatlik. Keegi ei saa olema vilgas ninja pärast seda, kui mõni päev on õpitoas õppinud, kuidas agaraks saada. Teie tee on pikk. Sõna “muutunud” on üsna määrav. Alles siis, kui Agile tõeliselt omaks võtate, näete selle väärtust. See peaks teid erutama. Kui see teid erutab, siis minge ka teisi.
• Nüüd, kui teie meeskond on mõistetes ja tehnikates kokku leppinud, nende soovid on täidetud ja on agiilsel koolitusel, pöörake oma meeskonna tähelepanu endale ja sellele, mida nad ootavad teilt, ettevõttelt ja üksteiselt.
• Määratlege mõned tööviisid (WoW) meeskonnas ja meeskonna poolt, mis aitab luua usaldust, suhteid ja ootusi. WoW ei ole Sõda ja rahu . See peaks olema lühike ja täpne, seitsme kuni kümne täppidega lause vahel. Need laused ütlevad selgelt, kuidas inimesed koos käituvad, suhtlevad, teevad koostööd, toetavad, toimetavad ja toimivad. Samuti peaks olema kirjas, mida meeskond ettevõttelt ootab.

• Agile on sama palju mõtteviisi kui juhtpõhimõtteid ja kontseptsioone. See aitab teil areneda oma käitumise, mõtlemise, läbirääkimiste pidamise, suhtlemise, suhtlemise, esinemise ja täiustamise viisis. See tugineb motiveeritud isikutele, kes toetavad üksteist ühise eesmärgi saavutamiseks koos. On Aafrika vanasõna:

Kui soovite kiiresti minna, minge üksi. Kui soovite kaugele minna, minge koos. Piiksuma

Nüüdseks peaks teie meeskond olema ülipõnev, pingestatud ja motiveeritud. Nüüd kaasake neid oma kasutajalugude mahajäämusega veelgi.

Mahajäämus

Ärge mõelge kahtluse alla, et teie projekt on seotud ebakindlusega. Te ei saa täpselt teada, mida on vaja oma klientidele õige toote ehitamiseks nii varajases elus. Te ei saa pilkavalt pilku heita kristallkuulile ega ennustada tulevikku.

Teie nõuded vastavad „mahajäämusele” või „toote mahajäämusele”. Agile soosib lühikeste, jõuliste avalduste kirjutamist, mis haaravad „nõude” olemust. Mahajäämus on lihtsalt pikk kirjete loend, kusjuures iga kirje määratleb kasutajalooks ühe, eraldiseisva nõude. Ja nüüdsest alates kasutame sõna kasutajalugu, mitte 'nõuet'. Tõenäoliselt küsite 'miks?' See on hea küsimus. Igavesti näib, et kliendi jaoks tarkvaraprojektis vajalike funktsioonide või tahkude märkimist on alati nimetatud nõudena. Sellel sõnal on tõlgendus, millel pole Agile'is väärtust. Oxfordi sõnaraamat määratleb selle järgmiselt:

Asi, mida on vaja või mida tahetakse. Või asi, mis on kohustuslik ; vajalik seisund .

Ja kahjuks, kui määratleme, milline peaks olema meie lahendus, märkides, et asjad on 'kohustuslikud', satume lõpuks hätta. Liiga lihtne on öelda, et kõik need kasutajalood on kohustuslikud. Kui me seda seisukohta võtame, on meil oht, et ajakava ja eelarve ületatakse, püüdes kogu antud ulatust täita. Pole probleem öelda, et selle toote jaoks on vaja neid lugusid, et lahendus oleks elujõuline, tahame lihtsalt vältida selle konkreetse sõna tõlgendamist.

• Kirjutage lugusid alati a isik . Persona esindab lahenduse kasutajat või sidusrühma. Enne mahajäämuse alustamist on hea see isik välja arendada.
• Selles etapis kirjutage ainult lühikesed ja lihtsad avaldused, mis soovitavad põhimõtteliselt meeldetuletust kasutajaloo kohta sügavama vestluse pidamiseks, kui on õige aeg.
• Päris inimesed mõtlevad ülesannetes, mis neil on eesmärgi saavutamiseks vaja teha. Kirjutage oma lood personaalperspektiivist ja tehes vajalikust.
• Te ei pea kirjutama täielikku mahajäämust - kirjutage lihtsalt nii palju, kui arvate, et teie kliendid vajavad teie toote elujõulisust.
• Hiljem avastate toote eluea jooksul, et kasutajalood muutuvad, muutuvad enam-vähem oluliseks või saab täielikult kustutada. Sageli vabastamine, tagasiside saamine ja prioriteedi hindamine teavitab sellest käitumisest.
• Ärge kirjutage lugusid eraldi. Kaasake oma meeskond, sidusrühmad ja isegi kliendid. Lugusid saab projekti igal ajal uuendada, kuid neid tuleks vältida, kui nende arendustöö on alanud.
• Mõnda teie lugu võib pidada eeposeks. Need on suured lood, mis hõlmavad palju ja jaotatakse tarneajale lähemal väiksemateks lugudeks.
• Kaaluge INVESTEERI mudel, kontrollnimekiri hea kasutajaloo kvaliteedi kinnitamiseks.
• Kõik saavad mahajäänud loo lisada. See tuleks asetada alaossa või spetsiaalselt loodud parklasse. See lisatud lugu aitab kiiresti arutada meeskonna ja ettevõttega. Kui ettevõte ja meeskond seda toetavad, saab seda siis hinnata ja prioriseerida
• Samuti võite kaaluda neid süsteemi osi, mis on kõige riskantsemad. Kui teil on kasutajalugu või funktsioon, mis on keeruline, uus või tehniliselt tundmatu, seadke need tähtsuse järjekorda oma mahajäämuse ülaossa. Nii ei püüa te oma toote väljakutsuvaid ja kriitilisi osi tarnida vaid mõni nädal enne esimest väljaandmist.

Kui teil on mahajäämus, mis vastab teie vajadustele, saate selles olevaid lugusid hinnata, järjestada need prioriteetsuse järjekorda ja koostada väljaandmiskava.

Kõrgel tasemel hindamine ja prioriteetide määramine

Kõrgel tasemel hinnang on teie mahajäämuse suuruse määramise protsess. Kui suur on projekt ja millist väärtust see annab? Prioriteetide seadmine on protsess, mille käigus otsustatakse, millised lood on teie jaoks kõige olulisemad, toote elujõulisus ja teie klientide huvid. Soovime tarnida kõige kõrgema väärtusega esemeid kõige varem, et pakkuda ettevõttele suurimat väärtust, saada kliendilt tagasisidet ja mitte pisiasju higistada. Väljundiks on järjestatud mahajäämus, mis on järjestatud prioriteedi järgi ja sobivalt suurustatud.

• Kõige väärtuslikumaks peetakse tipus olevaid lugusid. Soovime tarnida kõige väärtuslikumad esemed võimalikult varakult.
• Suuruse määramiseks ja hindamiseks on palju tehnikaid, kuid siinkohal soovite lihtsalt saada loo suurusest hea soovitusliku tunde.
  • Kasutage t-särgi suurust, suhtelist suurust, ideaalseid päevi või jutupunkte.
• Ka sel hetkel pole teil kogu saadaolevat teavet ja see on okei. Lihtsalt jookse sellega.
• Kaasake oma ettevõtte sidusrühmad või tootejuht, kui teil on, ja meeskond, kes seda tööd teeb.
• Soovime neid, kes kavandavad, arendavad ja testimine töö selle suuruse järgi, sest parimad inimesed, keda hinnata, on eksperdid.
• Meeskond võib hakata lugusid jagama väiksemateks osadeks. Kui see juhtub, kirjutage üksikasjalikumad, kuid diskreetsed lood.
• Samuti võib meeskond hakata lugusid järjestama, sest loomulikult peavad mõned asjad enne teisi jõudma, et toetada tehnoloogiat või antud kasutaja teekonda.
• Teie ja meeskonna vahel võite hakata ka mahajäämuses leidma auke, mis vajavad täitmist. Täitke need augud lihtsalt uute lugudega ning hinnake ja seadke prioriteedid vastavalt vajadusele.
• Prioriteetide määramine on kõige hõlpsam MoSCoW analüüsi abil. MoSCoW on lihtne tehnika, mis aitab teil otsustada, millised lood peavad teie toote edukaks saamiseks olema.
• Enne hindamise algust võite teha prioriteedipassi. Teatud elementide suuruse määramine võib aga määrata ka otsuse prioriteedi ja ettevõtte tegeliku väärtuse kohta. Nii et mängige üksteisest prognoosimist ja prioriteetide seadmist, kuid ärge selle pärast tülitsege!
• Ükski lugu ei saa olla sama oluline kui teine. 1. järgu lugu on olulisem või väärtuslikum kui 2. järgu lugu.
• Loo olulisuse või väärtuse demonstreerimiseks on suurepärane võimalus sellele rahalise väärtuse lisamine. Kui näiteks arvatakse, et lugu A toob 5000 dollarit lisatulu ja lugu B võib meelitada 100 dollarit, on lugu A väärtuslikum. Samamoodi, kui lugu C päästab ettevõtte rohkem kui lugu D, on lugu C väärtuslikum.
• Kui olete oma mahajäämust suurendanud, jääb teile number. Kui jõuame planeerimise väljaandmiseni, aitab see number meil mõista, kui palju meie meeskond suudab antud aja jooksul pakkuda.

Pidage meeles, et te ei pea kõiki oma kasutajalugusid teadma. Ärge unustage ka seda, et kõiki lugusid pole vaja edastada enne, kui klient teie toodet näeb. Sa tahad jääda väledaks - ja see tähendab ainult vajadusel vajaliku loomist, võimalikult vähe raiskamist ja klientide vajaduste ja turutingimuste muutustele reageerimist. Teekaart aitab teil oma toodet välja panna ja järgmise 3, 6, 9 ja 12 kuu eesmärke planeerida.

Teekaart ja lugude kaardid

TO teekaart on täpselt nii, nagu see kõlab, pakub see sama, mis riigi teekaart. See kirjeldab linnade suhtelist asukohta (või teie puhul funktsioone) üksteise suhtes ja marsruute, mida saab kasutada linnast A linna B või funktsiooni X ja funktsiooni Z jõudmiseks. See ei ütle teile, millist marsruuti te kasutate peaks võtma või kuidas peaksite sinna jõudma. See ei ütle teile, millist transpordiliiki kasutada, kuid see võib illustreerida kiirteele või rongile sõitmise võimalusi.

Linnas on palju teid, hooneid, parke, teenuseid ja rajatisi. Kõik linna omadused. See kehtib ka teie toote tegevuskava kohta. Sellel tasemel näitab teie tegevuskava peamisi eesmärke või verstaposte, mis tuleb saavutada. Eesmärk on loogiline teemade, funktsioonide ja kasutajalugude rühmitamine, mis on kokku pandud kuluvaates, mis näitab käegakatsutavat väärtust. Tarkvaratoote tegevuskava jagab seda seisukohta ja edastab teie kavatsuse. See ei pruugi teile näidata, kuidas ja millal funktsioone tarnitakse; ainult eesmärkide ja funktsioonide suhteline väärtus teile ja teie ettevõttele.

Üks suurepärane viis tegevuskava demonstreerimiseks on jutukaart . See tööriist näitab kliendi poolt hinnatud prioriteetide seadmist. See paneb paika teie toote selgroo ehk olulised ehituskivid. Kõndiv luustik ripub selgroo küljest ja illustreerib funktsioone, mis muudavad selle MVP-ks. Kõik muud funktsioonid on need, mis lisavad süsteemile lisaväärtust ja tähtsust. Jutukaart paneb omadused üksteise suhtes suhteliselt asendisse ja on suurepärane visuaalne tööriist.

kuidas kasutada bootstrapi 3

Väärib märkimist, et pärast lugude kaardistamise harjutuse tegemist võib tekkida vajadus teie mahajäämust täpsustada. See ilmneb siis, kui lood on jagatud mitmeks looks, määratletud üleliigsetena, vastloodud või kõrgema või madalama prioriteedina, kui seni arvati. Jutukaart on veel üks artefakt, mida vaadatakse ja muudetakse pidevalt.

Algatamise etapp viiakse tavaliselt läbi üks kord teie projekti elus. Paljud teie loodud tööriistad ja dokumendid vaadatakse aga läbi ja muudetakse kogu projekti vältel.

Väljalaske planeerimine

'Lõpuks,' kuulen teid nutmas, 'lõpuks on plaanis.' Noh, te olete sisuliselt planeerinud kõik teostatavuse ja algatamise etapid; me lihtsalt ei nimetanud seda selliseks. See on tõend iteratiivsest või kohanemisvõimelisest planeerimisest - kunst on planeerida ainult piisavalt, et saavutada oma vahetuid ja väärtuslikke eesmärke. Hiljem näeme rohkem adaptiivse planeerimise kohta, kuid praegu on meie keskmes väljaandmise planeerimine.

Teie vabastamiskava võivad hästi määratleda välised sündmused. Võib-olla on mõni mess, kus soovite oma rakendust demonstreerida, või saavad kliendid jõulude eel teie rakendust kasutades kõige rohkem kasu. Need on ajaskaala sündmused, millega teie eesmärgid võivad olla joondatud. Tõenäoliselt plaanite edastada kasutajalugusid või funktsioone, mis on nende sündmuste hõlbustamiseks kõige mõistlikumad. Kui pole väliseid kuupäevi, mida peaksite arvestama, võite lihtsalt minna funktsioonide prioriseerimise ja varaseima pakkumisega, mis on kõige mõistlikum ja pakub klientidele kõige rohkem väärtust.

• Kui lõite algatusel jutukaardi, aitab see teie väljaandmisplaani juhtida. Selle abil saate tuvastada oma MVP - minimaalse funktsioonikomplekti, mis annab teie toote teie klientide kätte, hakkab teenima tulu, saama tagasisidet ja hankima rohkem kliente.
• Jutukaart aitab teil välja selgitada ka tulevasi väljaandeid. Kuid pidage meeles, et õppides, tagasisidet saades, kontrollides ja kohanedes võivad tulevased versioonid muutuda. Nii et ärge planeerige väga üksikasjalikult.
• 12-kuulise perioodi jooksul võib teil olla kaks kuni neli väljalaset. Ärge tehke vähem, sest teie esimene väljaanne on teie MVP ja saab teie ukse vahele, pärast mida soovite korrata ja vabastada tavalise tsükli jooksul rohkem funktsioone ja veaparandusi. Ärge tehke enamat, kui te ei suuda hästi ja teil on pideva tarnimise haldamiseks palju agiilseid tehnikaid ja tööriistu.
• Iga väljaanne on ajakast, mis on jaotatud väiksemateks kordusteks. Iteratsioon on ajakast. Ajakast on Agile'is üks olulisemaid juhtimismeetmeid.
• Väljalaske suuruse määramiseks toimige järgmiselt.
  • Jagage väljaandmise ajakast kahega. See annab teile mitu kordust. Nii et kui teil on 12-nädalane väljaanne, saate kuus kahenädalast kordust.
  • Seejärel eemaldage kaks iteratsiooni - reserveerite ühe „sprint 0” korduseks ja teise „vabastamise” iteratsiooniks. See annab teile neli arengukordust.
  • Tehke oma meeskonna ja tooteomanikuga koostööd, et täita iga kordus lugudega, alustades mahajäämuse ülaosast ja lõpetades. Kui meeskond arvab, et nad on täitnud korduse piisavalt lugudega, mida nad saavad kahe nädala jooksul realistlikult oma võimekuse põhjal saavutada, korrake järgmist iteratsiooni. Igas iteratsioonis leidmiseks kasutage väljaandmiskava ja jutukaarti.
  • Järgmist väljalaset veel ei plaani. Teete seda praeguse versiooni lõpus.
  • Võtke kõigi oma iteratsioonide kasutajalood ja lisage lugude suurused. Nii et kui teie 1. kordusel on 25 lugu, kuid 2., 3. ja 4. kordusel on vastavalt 10, 45 ja 65 punkti, peate refrakteerima. Sihtige igas iteratsioonis võrdne arv jutupunkte. Sellest saab teie eeldatav kiirus - iga korduse jaoks täidetud väärtusliku kraami kogus.
• Võimalik, et meeskond pole varem koos töötanud. Nad töötavad peaaegu kindlasti uue probleemi või toote kallal. Esimesest päevast alates ei esine nad kõige paremini. Sel põhjusel võib teie kiirus esimestel sprintidel olla kõikuv. Kuid kui meeskond rahuneb, peaks see stabiliseeruma. Kasutage neid andmeid oma väljalaskeplaani muutmiseks, mis omakorda aitab teil toodet planeerida teadaoleva kiiruse ja enesekindlusega.
• Vajadusel jagage lood väiksemateks tükkideks ja muutke nende suurust.
• Teie vabastamiskava, eriti projekti ja uue meeskonna elu alguses, on alati ainult juhend. Ärge suhtuge sellesse kui kohustusesse ega garantiisse, et kõik või need täpsed lood edastatakse plaanipäraselt. Kui teie meeskond küpseb, saab töö tehtud ning suureneb usaldus ja enesekindlus, nii kasvab ka teie plaanide täpsus.
• Ärge kunagi sundige oma meeskonda pühenduma rohkemale, kui neile sobib. Usaldage nende otsust ja asjatundlikkust.
• Tulevased väljalaske kavandamise harjutused on lihtsamad, sest võtate väljalaske suuruse, korrutate korduste arvu oma meeskonna kiirusega ja täidate väljaandmise kava lugudega, mis liituvad kiirusega, korrutatuna korduste arvuga.

Vaatleme seda näitena. Kui lähete restorani sööma, siis te ei telliks kõiki menüüs olevaid asju ja eeldaksite, et sööte kõik ühe istungiga. Te ei saaks seda kõike kunagi süüa, te ei pruugi endale lubada kulusid, teil on toidust kõrb ja restoran võib sulgeda, kui sööte 19 käigust viiendat! Te ei pruugi lahkuda õnnelikust kliendist, restoran ei pruugi teid leida suurepäraseks kliendiks ja kogemus on ümberringi halb. Tõenäolisem on see, et kui teile meeldib restoran, siis sellepärast, et nautisite seal kunagi ühte armsat sööki. Otsustate minna tagasi ja nautida mõnda muud sööki. Ütlete oma sõpradele, et käite seal sageli. Loo moraal on:

• Plaanige väljalaskeid väikeste tükkidena.
• Mõelge oma võimekusele.
• Ärge võtke enamat, kui suudate realistlikult saavutada.
• Vaadake plaani sageli üle, et näha, mida saate muuta ja parandada.
• Planeeri, täida, kontrolli, õpi, kohanda, kordama .

Väljalaske planeerimine toimub sageli tarkvaraprojektis. Iga uus väljaanne nõuab väljaandmisplaani. Väljalaskekava saab projekti käigus igal ajal ümber teha. Lihtsalt hoolitsege selle eest, et mitte üle pingutada ja langeda zombiseeritud planeerimispsühhoosi. Väljalaske planeerimise lõpus soovite valmistuda esimeseks korduseks, kuhu me õnnelikult edasi läheme!

Toote kordused

Teie meeskond on paigas, nad on motiveeritud, teil on kaasatud ettevõte, teie esialgne planeerimine on tehtud - olete nüüd valmis oma unistusi üles ehitama.

Me rääkisime varem mõnest tööriistast, tehnikast ja kontseptsioonist, mida Agile tellib. Juba on palju ressursse, mis teevad suurepärast tööd Agile tarkvaraprojekti elluviimise aluste rajamisel. Valige üks, hoidke seda vaniljes ja kasvage oma väledaks teekonnaks. Alustuseks õige Agile tarkvaraarenduse metoodika üle otsustamisel saadud trauma lühendamiseks soovitaksin kasutada Scrumi. Ja ainult Scrum. Kiusatus on kasutada teiste metoodikate elemente. Ärge seda veel tehke. Salvestage selline muudatus, kuni olete 6 või 12 kuud Scrumi elanud ja hinganud. Seejärel, kui olete otsustanud, et see üksi teie jaoks ei toimi või soovite meeskonnana küpseda, tutvustage pidevalt uusi meetodeid, tehnikaid või raamistikke.

Ma valin Scrum kui uue meeskonna Agile kasutuselevõtu soovitatav lähenemisviis, kuna sellel on kõik põhitõed sisse ehitatud. See on väga populaarne ning sellel on palju kvaliteetseid kogukondi ja ressursse veebis, raamatutes või koolitusruumis. See teenib teid hästi ka kõige väiksematele meeskondadele. Selle postituse ülejäänud osa on pühendatud tarkvara edastamise mõnede oluliste aspektide arutamisele, mida teie, teie meeskond ja sidusrühmad peaksid alati meeles pidama.

Kohanduv planeerimine

Agile projekti planeerimine on pidev protsess. Me teeme esialgse esialgse planeerimise, täpselt nii palju, et mõista, mida me antud punktis teame. Meie esialgsed plaanid on lõdvalt määratletud ja puudulikud. Ja siis kordame oma planeerimist, kohaneme uue teabega, planeerime üksikasjalikumalt vahetult enne tarne alustamist, reageerides muutuvale ulatusele. See on üks viis raiskamise minimeerimiseks - panustame planeerimisse vaid siis, kui seda vaja on.

• Meeskond ja ettevõte või selle teadlik ja volitatud esindaja, näiteks tootejuht, kavandavad aktiivselt koostööd - meeskond, sest nad on eksperdid, kes toimetavad, ja tootejuht, sest need on eksperdid, kes saavad ettevõtte vajadusi suunata.
• Kasutajalugude hinnangud on vähem täpsed, seda kaugemale neid arendatakse. Näiteks meelitavad eeposed ligi kõrgetasemelisi hinnanguid, mis põhinevad paljudel tundmatutel. Hästi määratletud ja detailsed kasutajalood, mida hinnatakse vahetult enne sprindi algust, on palju täpsemad.
• Hinnangu skaalasid, mida saate kasutada, on palju. Kasutage tehnikat, mis tundub teie meeskonnale kõige õigem ja planeerimise õige etapp - lairiba delphi, pokkeri planeerimine , ideaalne aeg, suhteline suurus, jutupunktid või t-särgi suurused.
• Loo suuruse järgi sobib üks suurus tõesti kõigile. Kõigi lugude suurus peaks olema sama tehnika ja need peaksid hõlmama kõiki elemente, nagu kujundus, arendus, testimine ja taastamine. Kui tulete sprindi iteratsiooni kavandama, võib luua teatud ülesandeid, mis kõik aitavad kaasa loo valmimisele.
• Planeerimisel arvestage alati riski, tundmatute, välismõjude, oma meeskonna võimekuse ja pidevalt paraneva kiirusega.
• Kui sprindiks võetud kasutajalugusid ei lõpetatud, ei pikenda me ajakasti. Need lõpetamata või alustamata asjad pannakse tagasi mahajäämusesse ja viiakse järgmisele sprindile.
• Kavandage alati etteantud eesmärgi saavutamiseks kõige vähem vajalik summa. Tehke kindlaks tunnuste kärpimise tehnikad. Vähendage raiskamist ja leidke tegelik väärtus, mida saab teie ajaliselt piiratud ressursside abil reaalselt pakkuda.

Loo loomine

Lugusid arendatakse täpsemalt siis, kui neid vajate. Teil pole vaja täielikke loo selgitusi funktsioonide kohta, mille esitamine on kuue kuu kaugusel. Nende alguses kirjutamine võib raisata jõupingutusi, kui see vajadus kaob. Kirjutage oma lood kuni kaks kordust, enne kui neid vaja läheb. Eelistatav on selle ajaraami vähendamine ühele sprindile.

Võtame stseeni seadmiseks aega sprindis 0. Kahe nädala pärast alustate arendamist. Nüüd on aeg võtta mahajäämuse ülaosast piisavalt lugusid, mis võiksid toimuda 1. sprindil. Kui te pole kindel oma kiiruses, võite võtta 10-15% rohkem. Neid ühekaupa saab nüüd laiendada tõeliselt väärtuslikeks dokumentideks, millel on stsenaariumid, vastuvõtukriteeriumid ja traadiraamid. Kui traadiraame pole veel loodud, on aeg seda teha. Nende kandidaadilugude ülevaatamisel võite leida, et need tuleb lahterdada. Võib-olla olid need eeposed, mida ei saanud kuidagi sprindis lõpule viia. Kui jagate lugusid, hindage neid meeskonnaga uuesti.

TO hea lugu järgib järgmisi reegleid: - Kirjutatud ühises formaadis, nt NAGU TAHAN. - Sisaldab vastuvõtukriteeriume, millele lugu peab vastama, et seda saaks ettevõttele sisselogimiseks vastuvõetavaks pidada. - kasutab keelt, mida ettevõte ja teie kliendid mõistavad. - järgib INVESTi mudelit. - Sisaldab kõiki tõendavaid dokumente arendaja, disaineri ja testija teavitamiseks: traadiraamid, tehnilise projekti ülevaade, muud varad. - Vastab teie standardsetele kriteeriumidele 'valmis'.

Sprintimine

Sõltumata sellest, kas nimetate seda sprindiks, iteratsiooniks või ajakastiks, on teie Agile projekti iga järkjärguline edastamine ajaliselt piiratud. Ajakast ei lühene ega pikene. Keskenduge alguses kahenädalastele kordustele. Võib juhtuda, et 1, 3 või 4 nädalat sobib teie ärimudeliga paremini. Kui olete pikkuse valinud, ärge seda enam muutke. Soovite säilitada regulaarset kadents või jätkusuutlik tempo. See tähendab, et meeskond ja ettevõte keskenduvad tavapärase tarkvara tarnimisele, ilma et oleks vaja pööraseid ületunde, et töö ära teha ja vabastada iga kahe nädala tagant potentsiaalselt vahetatavad lisatasud.

• Väikeste sammudega töötamisel on tohutu kasu. See tähendab, et keskendute ainult kättetoimetamise lähitulevikule ja uue sisendi, tagasiside ja õppimisega saate muutustele reageerida lühikese iteratiivse tsükli jooksul.
• Väljalaske alguses sooritage sprint 0. See võimaldab meeskonnal, ettevõttel ja teie projekti väljalaskmisel end üles seada ning seab mõtteviisi edukaks edastamiseks. Joonistage välja põhiline tehniline raamistik ja arhitektuur, mis toetab väljalaske alust. Seadistage keskkonnad, kontod ja tööriistad. Tehke piike raskete või tundmatute probleemide mõistmiseks. Kujundage oma kasutajalood valmisolekuks sprindiks 1. Sprint 0 seisneb ettevalmistuses.
• Väljalaske ajal jätkake mahajäämuse täpsustamist. Kui mõistate rohkem või õpite midagi uut, võivad teie prioriteedid muutuda, uued nõuded avaneda ja see, mis teie arvates oli varem suurepärane omadus, võidakse täielikult eemaldada.
• Ärge alustage tööd, millel pole võimalust sprindi jooksul lõpule viia. Kui see ei õnnestu, jagage see väiksemateks tükkideks. Ja ärge alustage uut tööd, kui varem alustatud tööd pole lõpetatud. Te ei loo väärtust, alustades palju asju, mida ei saa pidada täielikuks. Lisaks vältige konteksti vahetamine . See on ühe ülesande alustamine, häirimine, teise alustamine ja kõige problemaatilisem ka kumbagi täitmata jätmine.
• Piirake meeskonna poolelioleva töö mahtu korraga. Näiteks kui teil on kolm arendajat ja üks testija, võite seada WIP-piirangu arendajatele ja testerile.
• Ärge kunagi lisage sprindile rohkem tööd pärast selle kavandamist. Ärge kunagi peatage sprinti poolel teel. Erandid on järgmised:
  • Kui esinesite oodatust kiiremini, kaaluge järgmise loo mahajäämuse ülaosast võtmist, kui see on sobivalt ette valmistatud.
  • Kui sprint töötab nii halvasti, et ei jõua lõpule. Tavaliselt juhtub see ainult seal, kus on toimunud mõne kirjelduse katastroof.
  • Kui sprindi eesmärki ei saa ettevõtte koheste muutuvate vajaduste tõttu enam toetada.
• Kui tühistate sprindi, siis tehke seda nõtkelt, võtke aega uuesti fokuseerimiseks ja alustage uut sprinti nagu teeksite seda teistki.
• Väljalaske lõpupoole kaaluge lõpliku vabastamise sprinti. Uusi funktsioone pole kirjutatud, mõningaid vigu saab puhastada ja teha ettevalmistusi, et oma toote uus versioon klientidele tegelikult välja anda. See ei tähenda, et te ei saaks vahepeal klientide järkjärgulisi väljalaskeid teha - lihtsalt see on kontrollitud, mõõdetud ja jätkusuutlik väljalaskemehhanism.
• Väljalaske lõpus võite kaaluda ühe nädala sprinti. Selles sprindis võite koos meeskonnaga teha mõned uued ideed või välja mõelda mõne uue tehnoloogia. Need on suurepärased tööriistad, mis ärile kasuks tulevad ning see annab meeskonnale teatava ülevaate mõtlemiseks ja loovuseks. See pole mõeldud lollimiseks ja loob ikkagi väärtust. Samamoodi vajavad kõik puhkust. Sel ajal puhkus aitab vabanemise keskel hoida hoogu ja kiirust heas vormis.

Määratletud Valmis

On väga oluline määratleda, mida 'tehtud' tegelikult tähendab. Teie projekti elu jooksul on palju variante „valmis” - mida tähendab „teha” loo, väljaande või kogu projektiga. Kõik taandub sellele, mida teie, teie meeskond ja ettevõtted peavad täielikuks õigeks kvaliteeditasemeks, et rahuldada saatmisvalmidust.

Teie meeskonna jaoks on „valmis” loo määratlus umbes selline, nagu kogu kood oleks täielik, eelretsenseeritud, vastaks määratletud aktsepteerimiskriteeriumidele, testitud üksus, UAT’ed ja teie koodi hoidlasse. Et võimaldada loo edasiandmist disainerilt arendajale testijale, peab ahela järgmine inimene aktsepteerima „tehtud“ määratlused. Teie toote omanikul on ootusi, mida see nende jaoks tähendab, et vabastada toote juurdekasv teie klientidele. Igal juhul peavad kõik olema teadlikud sellest, mida 'tehtud' tähendab, ja olema vastutav osapool selle tähenduse täitmise tagamisel. Määratlege oma määratlus 'valmis', edastage see, leppige selles kokku ja arendage seda edasi. Valmis.

Pidev mõõtmine

Kui te ei saa seda mõõta, ei saa te seda hallata. Sama kehtib ka paranduste kohta. Vajadus koguda agiilsesse projekti empiirilisi andmeid on peaaegu sama oluline kui verevoolu läbimine veenides! Kuidas teada saada, mida on vaja hallata, parandada või parandada, kui andmeid pole? Noh, lihtsalt öeldes, tuginete kõhutundele ja põhjendamatutele oletustele, mis lagunevad luubi all üsna kiiresti. Ja sõltuvalt sellest, kes kontrollimist teeb, võib see olla üsna ebamugav koht. Seega veenduge oma projekti algusest peale, et teate, kuidas kavatsete edusamme demonstreerida ja milliste meetmetega teised teie edu vaatavad.

Õnneks on Agile laetud kasulike tööriistade ja tehnikatega. Esimene asi, mida teha, on minna tagasi Agile Manifesti juurde, tippida järgmised sõnad oma lemmiktekstisse, puhuda need kuni 96pt-ni, printida ja rakendada kõigile vaatamiseks seinale:

Töötav tarkvara on edasimineku esmane mõõdupuu Piiksuma

Teie suurim tõestatav jõud tarkvara edastamisel on näidata seda töötavatele inimestele, tehes seda, mida ta peaks tegema. See mitte ainult ei rõõmusta teie kliente, vaid teenib teie meeskonnale suurt austust ja määrib rattad ettevõtte kaudu suuremaks vastuvõtmiseks.

Siin on mõned muud tööriistad:

• The igapäevane püsti tõusmine : Sellel tseremoonial on mõned variatsioonid, kuid sisuliselt on see, et kõik meeskonnaliikmed räägiksid üksteisega silmast silma: hoidke seda lühikesena, hoidke keskendununa ja hoidke seda kergena. Kui midagi vajab pikalt arutelu, parkige see pikemaks vestluseks pärast püstiolekut. Kui takistused on tõstatatud, kirjutage need üles nagu lugu, lisage need oma mahajäämusse ja pöörduge nende poole. Kõik, mis teie meeskonda takistab, aeglustab nende arengut ja on demonstreeritav väiksema kiirusega ning ootustele mittevastava tarkvaraga.
• Kiirus : On ajalooline tööriist. See on natuke sarnane nende rahaliste hoiatustega, mis teile saadetakse ja mis väidavad, et varasemad tulemused ei taga edasisi tulemusi. Kuid Agile'i puhul loodame saavutada meeskonna kiiruse, mis on sujuvalt sujuv. Kiirus võimaldab meil prognoosida tulevasi tulemusi ja enesekindlust oma plaanides. Võib juhtuda, et teie kontrolli all ei ole mõjutusi, mis võivad vähendada antud sprindi väljundipunktide arvu. Kui see juhtub, saate tõenäoliselt taastuda. Ärge kunagi kasutage kiirust pulgana, millega oma meeskonda võita; see ei võida teile ühtegi teenet. Üks on kindel, et esimese 2–4 sprindi kiirus on ebakorrektne. Kuid kuskil selle aja jooksul peaksite nägema järjepidevust ja stabiilsust. Kui teie kiirus kõigub äärmusest teise, on teil probleem, mille peate oma meeskonnaga lahendama.
• Põlemisdiagramm: nüüd on see edusamm mõõdukas. Sel põhjusel ei ole ma andnud linki, et rohkem teada saada - peate ise uurima ja kokku leppima meeskonna ja ettevõttena, mis teile sobib. Põhjus on okkaline? Noh, mitte üks sealne ressurss ei räägi sama lugu! Üks asi, milles kokku lepiti, on see, et see näitab sprindi või väljalaske jooksul, kuidas te oma ajakasti vastu astute. Kui seda hooldatakse iga päev, näitab see, kas olete õigel teel või kaldute kõrvale. Mõned meeskonnad tähistavad seda, kui palju väärtust loodakse luua, sagedamini kui teised, teised näitavad seda, kui palju tööd on jäänud lõpetada. Esimene neist on edu ja väärtuste loomise tähistamine, teine ​​on vähem inspireeriv ja motiveeriv.
• Põlemisdiagramm: kui peate näitama töö lõpetamise määra, kasutage selleks läbipõlemisskeemi. Kuid põletusdiagrammi abil saate näidata, kui palju väärtust on loodud ja kui palju rohkem väärtust kavatsete sprindi lõpuks luua. Palju motiveerivam tööriist meeskonnale, kes demonstreerib ettevõttele, mida on tehtud (või vähe, kui asjad ei lähe nii hästi ...) ja mida neil on veel ees. Igal juhul kasutage graafikuid selleks, et leida kohti, kus edusammud ei jälgi ootuspäraselt, ja otsige mustreid või kõrvalekaldeid ning astuge nende peale, et probleem võimalikult kiiresti lahendada. Värskendage neid iga päev sprintide jaoks ja üks kord sprindi lõpus versiooniversioonide graafikute jaoks.
• Töölauad : Need on suurepärased visuaalsed radiaatorid loodava väärtuse demonstreerimiseks. Iga päev või päeva suvalisel ajakohastamisel näitavad need kohe tehtud edusamme. Koos Kanbaniga on need ka suurepärased tööriistad süsteemi voolu ja ummistuste visualiseerimiseks. Kui näete, et palju arendusi on lõpule viidud, kuid testimine pole nii produktiivne, näete probleemi toimumist ning reageerite asjakohaselt ja kiiresti.

Muud arvestatavad vahendid on Vilgas teenitud väärtus , tsükli aeg ja kumulatiivsed vooskeemid (CFD).

Hoidke need mõõdud, tabelid ja muud tööriistad nähtaval, eelistatavalt valjult ja uhkelt seinal, et kõik saaksid neid näha. Meeskond, sidusrühmad ja teised huvitatud isikud näevad kohe projekti seisu. See on läbipaistev ja on väärtuslik suhtlusvahend. Kui te ei saa neid esemeid seinale panna, kasutage ühiskasutatavaid ja koostööl olevaid tööriistu ning veenduge, et juurdepääsutajatel oleks see olemas.

Pidev täiustamine

Püüdke kogu oma väledas elus välja selgitada ja õppida, kus on võimalik täiustusi teha. Õppetunde ei hõivata ega õpita projekti lõpus. See on nagu sõidueksami sooritamine ja esialgne esimene sõit ilma juhendajata. Saate teada, mis töötab ja mida peaksite tegema, kuid aja jooksul kohandate oma juhtimisoskusi ja -võimeid, õppides uusi tehnikaid. Sa kogud isegi halbu harjumusi. Otsige neid üles, mõistke neid ja leidke viise, kuidas end paremaks muuta.

Ebaõnnestumise tuvastamiseks ja abinõude rakendamiseks on palju võimalusi. Sisseehitatud lähenemine sellele Agile'is on retrospektiiv. See on peegeldamise ja kohanemise peamine vahend. Iga sprindi lõpus leidke meeskonnaga aega, et parandada töö tegemist, kvaliteedi tarnimist, tõhususe maksimeerimist, jäätmete minimeerimist ja võimsuse suurendamist. Kui tuvastate parandusmeetmeid, ärge kiusake kõik probleemid kohe lahendama. Tehke kindlaks need, millel on kõige suurem mõju ja mida saab rakendada järgmisel sprindil. Mõõtke ja jälgige. Kui sellel oli soovitud mõju, lukustage see, kirjutage see oma tööviisidesse ja tehtud määratlustesse. Kui see ei toimi, mõelge uuesti. Kõiki õpitud õppetunde, mida eelseisval sprindil ei panda, saab parkida ja need on prioriteediks järgmisel sprindil.

Räägi protsess. Eemaldage kõik, mis ei tööta. Eemaldage takistused. Teie küpsus Agile meeskonnana ei tunne piire, kui te seda lubate.

Agile projektijuhtimise taga

Oluline on teada, mis juhtub pärast projekti edastamist. Tugi ja hooldus on võtmetähtsusega selle tagamisel, et kui projekt on klientide käes, jääb see tulemuslikuks; klientide tagasisidet saab arvesse võtta tulevastes väljaannetes; ja kliendiküsimustega tegeletakse asjakohaselt. Projekt on ainulaadne ja ajaliselt piiratud ettevõtmine. Selle tarnitaval tootel on elu pärast projekti meeskonna laialisaatmist. Veenduge, et olete võimeline toodet toetama, kui see töötab.

Agiilsed projektid eksisteerivad koos traditsioonilisemate lähenemisviisidega. Eelarvekontrolli ja sidusrühmade nähtavuse nõuete tasakaalustamine Agile paindlikkuse ja reageerimisvõime eesmärkidega.

Juhtimisraamistikku või Agile juhtimismudelit kasutatakse koos tavapäraste Agile protsessidega, näiteks Scrum. Nad töötavad kahel konkreetsel viisil:

• Nad pakuvad Agile projekti jaoks ümbrist, selgitades protsesse, mis toimuvad väljaspool arenduse iteratsioone (sprindid). See hõlmab selgete kriteeriumide esitamist projekti algatamise edukaks lõpuleviimiseks ning otsuste ja kava nõuetekohaseks kinnitamiseks.
• Need muudavad tavapärase Agile-protsessi konkreetsete osade rõhuasetuse ja toovad esile konkreetsed põhimõtted ja tehnikad, mis vajavad juhtimist või toetavad valitsemist.

Tänapäeva pidevalt muutuvas maailmas soovivad organisatsioonid ja ettevõtted projektide elluviimisel kasutada paindlikumat lähenemist ja soovivad muutuda väledamaks. Projektide ja programmidega tegelevate organisatsioonide jaoks ning seal, kus juba on olemas ametlikud projektijuhtimisprotsessid, on paljude agiilsete lähenemisviiside mitteametlikkus hirmutav ja mõnikord peetakse seda liiga riskantseks. Need projektile keskendunud organisatsioonid vajavad küpset ja kiiret lähenemist - agiilsust projekti elluviimise kontseptsiooni raames - Agile projektijuhtimine .

Õppige ja kasvage koos Agile'i omaksvõtmisega. Tehke kunagi ainult seda, mis teie meeskonnale sobib, tagage nende hääle kuuldavus ja tegutsege nende soovide järgi. Innustage oma meeskonda kasutama uusi ja väärtuslikumaid tehnikaid, kui on õige aeg. Pidage ettevõttega läbirääkimisi ja julgustage neid mõistma, mida tähendab olla vilgas organisatsioon.

Nautige teekonda.