La komputila industrio estas plena de ambigua lingvo, severa ĵargono kaj kompleksaj ideoj, kiuj estas malfacile kompreneblaj kaj povas sendi vian menson en frenezon de komputila bufro.
Akvofalo? Scrum? Lerta?
Se ĉi tiuj frazoj estas al vi tute fremdaj, ne zorgu; via helpema teamo de teknikaj geeks HashDork estas ĉi tie por helpi vin kompreni la distingojn inter ĉi tiuj decidaj etapoj de la evoluprocezo por ke vi povu fariĝi sperta.
La lertaj, scrum kaj akvofalaj teknikoj ĉiuj estos kovritaj en ĉi tiu bloga afiŝo, kune kun kiel ĉiu povas helpi vian teamon entute.
Ni komencu per la lerta, kaj ni kunportos la ceterajn.
Kio estas Agile?
Lerta programaro-disvolviĝo sekvas ripetan, pliigan aliron. Prefere ol ampleksa preparo ĉe la komenco de projekto, Agile-teknikoj estas flekseblaj al ŝanĝiĝantaj bezonoj laŭlonge de la tempo kaj antaŭenigas kontinuan retrosciigon de finuzantoj.
Krucfunkciaj teamoj laboras pri produktaj ripetoj laŭlonge de la tempo, kaj ĉi tiu laboro estas kategoriigita en restaron kaj prioritatita surbaze de komerca aŭ klienta valoro. La celo de ĉiu ripeto estas krei uzeblan produkton.
Gvidado antaŭenigas kunlaboron, respondecon kaj vizaĝ-al-vizaĝan komunikadon en Agile metodaroj.
Komercaj koncernatoj kaj programistoj devas kunlabori por certigi, ke la produkto plenumas la postulojn de la konsumanto kaj la celojn de la firmao.
La frazo "facilmova evoluo" rilatas al diversaj metodoj kaj kadroj kiuj estas bazitaj sur la idealoj kaj dogmoj skizitaj en la Agra Manifesto.
Fakuloj konsilas aliĝi al lertaj principoj kaj valoroj kaj uzi ilin kiel gvidilon por decidi la ĝustajn agojn por fari en aparta medio dum alproksimiĝo al programaro.
La kunlabora kaj mem-organiza teamo estas la ĉefaj fokusoj por la lerta programaro-evoluiga komunumo.
Teamoj rajtas aŭtonome decidi kiel ili traktos apartan projekton, sed tio ne signifas, ke kontrolistoj estas neekzistantaj. Lertaj teamoj estas do transfunkciaj.
En lerta paradigmo, administrantoj ankoraŭ estas necesaj. Ili certigas, ke ĉiu teamano havas aŭ akiras la necesajn kapablojn por la projekto.
Manaĝeroj en lerta kadro funkcias per kreskigado de atmosfero kiu produktas la plej bonan en la teamo. Sed prefere ol ekgvidi, ili ofte prenas malantaŭan seĝon kaj lasas la teamon decidi kiel ili liveros aferojn.
Administrantoj nur implikiĝas kiam teamoj plurfoje provas solvi problemojn sen sukceso.
Lerta Disvolva Ciklo
La stadioj de la Agile evoluciklo estas listigitaj malsupre. Estas grave memori, ke ĉi tiuj fazoj ne devus okazi en ordo ĉar ili estas flekseblaj kaj konstante ŝanĝiĝantaj. Multaj el ĉi tiuj etapoj okazas samtempe.
- planado: Post kiam projektteamo decidis ke ideo estas praktika kaj realigebla, ili komencas serĉi funkciojn. Ĉi tiu fazo celas prioritatigi ĉiun funkcion kaj asigni ĝin al ripeto post malkonstruo de la ideo en pli malgrandajn laborpecojn (la ecoj).
- Analizo de postuloj: Por determini komercajn postulojn, ĉi tiu paŝo implicas plurajn diskutojn kun administrantoj, koncernatoj kaj uzantoj. Kiu uzos la produkton kaj kiel ili uzos ĝin estas inter la detaloj, kiujn la teamo devas kolekti. Ĉi tiuj normoj devas esti specifaj, aplikeblaj kaj kvantaj.
- dezajno: La postuloj trovitaj en la antaŭa etapo estas uzataj por prepari la sistemon kaj programaran dezajnon. Konsideroj pri la aspekto de la produkto aŭ solvo devas esti faritaj de la teamo. Strategio aŭ plano por la testo ankaŭ estas evoluigita fare de la testteamo.
- Efektivigo, kodigo aŭ evoluo: La fokuso de ĉi tiu etapo estas sur konstruado kaj taksado de ecoj kaj planado de la deplojo de ripetoj (sekvante la ripetan kaj pliigan evolualiron [IID]). Ĉar neniuj funkcioj estas provizitaj, ripeto 0 de la evoluperiodo komenciĝas. Kompletigante agadojn kiel kontraktado, agordo de agordoj kaj financado, ĉi tiu ripeto provizas la bazon por estonta kresko.
- provoj: Post kiam la kodo estis kreita, ĝi estas testita kontraŭ la postuloj por certigi, ke la produkto vere kontentigas uzantpostulojn kaj plenumas komercajn celojn. Testado pri unuo, integriĝo, sistemo kaj akcepteblo estas efektivigitaj en ĉi tiu etapo.
- deplojo: Post testado, la produkto estas sendita al klientoj por ke ili povu uzi ĝin. La projekto ne estas finita post deplojo, tamen. Klientoj povas renkonti pliajn problemojn post kiam ili komencas uzi la produkton, kiu bezonos la projektan teamon por trovi solvon.
Avantaĝoj
- Pli rapida, pli altkvalita livero: Malkonstruante la projekton en ripetojn (regeblaj unuoj), la teamo povas koncentriĝi pri pli altkvalita kunlaboro, evoluo kaj testado. Kiam testado estas farita kun ĉiu ripeto, problemoj estas trovitaj kaj solvitaj pli rapide. Aldone, kun konstantaj, postaj revizioj, ĉi tiu altkvalita programaro povas esti provizita pli rapide.
- Ŝanĝo estas bonvena: Kvankam planaj cikloj estas pli mallongaj, estas simple akcepti kaj alĝustigi ŝanĝojn en iu ajn punkto de la projekto. La restaro ĉiam povas esti plibonigita kaj reprioritigita, permesante al teamoj fari ŝanĝojn al la projekto en kelkaj semajnoj.
- Fincelo eble ne estas konata: Agile estas bonega por projektoj kiam la fina celo ne estas klare difinita. Dum la projekto antaŭeniras, la celoj fariĝos klaraj, kaj evoluo povos facile alĝustigi ĉi tiujn ŝanĝiĝantajn bezonojn.
- Kontinua plibonigo: Lertaj programoj antaŭenigas uzanto- kaj teaman enigon en ĉiuj stadioj de la projekto, ebligante la aplikon de tio, kio estas lernita, por plibonigi la sekvan ripeton.
- La opinioj de klientoj estas taksataj: Estas pluraj ŝancoj por klientoj rigardi laboron finita, proponi retrosciigon, kaj vere influi la finan rezulton. Interagante tiel intime kun la projektteamo, ili povus disvolvi senton de proprieto.
- Forta teamlaboro: Agile emfazas la signifon de regula komunikado kaj enpersonaj renkontoj. Homoj povas preni respondecon kaj posedi certajn projektkomponentojn kiam ili laboras en teamoj.
malavantaĝoj
- Teamanoj devas havi scione: Lertaj teamoj ofte estas malgrandaj. Tiel, teamanoj devas havi larĝan gamon de kapabloj. Aldone, ili devas kompreni kaj senti sin trankvilaj uzante la elektitan Agile teknikon.
- Planado povus esti malpli preciza: Povas foje esti malfacila determini precizan liverdaton. Agile estas konstruita sur temp-skatolita livero, kaj projektestroj ofte rearanĝas la prioritatojn de taskoj. Tiel, verŝajne kelkaj el la liveroj, kiuj estis komence planitaj por liveraĵo, ne estos finitaj ĝustatempe. Aldone, pli da sprintoj povus esti aldonitaj en ajna momento dum la projekto, plilongigante la tutan horaron.
- Dokumentado povas esti ignorita: Iuj teamanoj povus kredi, ke koncentriĝi pri dokumentado estas malpli grava, ĉar la Agile Manifesto preferas funkciantan programaron super ĝisfunda dokumentado. Lertaj teamoj devus atingi la idealan ekvilibron inter dokumentado kaj dialogo, eĉ dum ĝisfunda dokumentado ne povas garantii projektan sukceson per si mem.
- La fina eligo povus multe malsami: Eble ne estis klara strategio por la komenca Agile-projekto, kaj tial la preta rezulto povas multe ŝanĝiĝi de tio, kio estis unue antaŭvidita. Esence malsama fina produktaĵo povas rezulti el aldonado de novaj ripetoj bazitaj sur ŝanĝado de klientenigo, ĉar Agile estas tiel adaptebla.
- Tempodevontigo de programistoj: La disvolva teamo devas esti plene engaĝita al la projekto por ke lerta estu efika. La Agile metodo, kiu daŭras pli longe ol konvencia aliro, postulas konstantan aktivan partoprenon kaj kunlaboron. Aldone, ĝi implicas, ke la programistoj devas engaĝiĝi pri la tuta longo de la projekto.
Kio estas Akvofalo?
La plej populara ripeto de la evolua vivociklo de la sistemo (SDLC) por softvarinĝenieristiko kaj IT-projektoj estas konata kiel la "akvofalaliro", kiu sekvas sinsekvan, linearan proceduron.
Diagramo de Gantt, formo de bardiagramo kiu montras la komencajn kaj finajn datojn de ĉiu laboro, estas foje uzata por plani ĝin.
La evoluigteamo progresas al la sekva nivelo post kiam unu el la ok fazoj estas finita. La teamo estas nekapabla reveni al antaŭa stadio sen devi rekomenci la tutan proceduron.
Aldone, la kliento eble bezonos taksi kaj akcepti la postulojn antaŭ ol la teamo povas iri al la sekva nivelo.
La akvofalmodelo estis evoluigita en la tre fakorganizitaj medioj de la produktado- kaj konstrusektoroj, kie alĝustigoj eble estos prohibe multekostaj aŭ eĉ maleblaj.
La akvofalo-tekniko estas tiel nomata ĉar ĝi intencas flui en nur unu direkto—malsupren—same kiel akvofalo. Ĝiaj fazoj inkludas analizon, komencon, testadon, dezajnon, konstruaĵon, deplojon, prizorgadon kaj testadon.
La akvofala tekniko havas plurajn avantaĝojn, same kiel ajna alia strategio. Unu estas, ke la fazoj de projektplanado kaj dezajno estas pli bone establitaj.
Klientoj kaj la disvolva teamo estas pli vicigitaj kiam temas pri projektaj liveroj dum uzado de akvofala programaro. Ĉar vi konscias pri la amplekso de la projekto ekde la komenco, akvofala evoluo ankaŭ faciligas kontroli la progreson.
La akvofalo-procezo uzas specialistojn, programistojn, analizistojn kaj testistojn por koncentriĝi pri siaj laboroj en la projekto prefere ol havi la tutan teamon emfazi unu paŝon.
Etapoj de Akvofalo
La ses ŝtupoj de la Akvofalo devas ĉiuj okazi unu post la alia:
- Kolekti kaj stoki postulojn: Vi devus amasigi ĝisfundan scion pri tio, kion postulas ĉi tiu projekto nuntempe. Estas pluraj teknikoj por kolekti ĉi tiujn datumojn, inkluzive de intervjuoj, enketoj kaj kunlabora cerbumado. La bezonoj de la projekto devus esti evidentaj kiam ĉi tiu fazo finiĝos, kaj via teamo devus esti ricevinta kopion de la postdokumento.
- Dezajno de sistemo: La sistemo estas desegnita de via teamo uzante antaŭdestinitajn specifojn. Dum ĉi tiu etapo, neniu kodigo estas farita, sed la teamo starigas postulojn por aparataro aŭ la programlingvo.
- efektivigo: Ĉi tiu etapo implikas kodigon. La datumoj de la antaŭa etapo estas uzataj de programistoj por konstrui uzeblan produkton. Kodo ofte estas efektivigita en etaj pecoj kiuj estas kombinitaj ĉe la konkludo de unu fazo aŭ la komenco de alia.
- provoj: La produkto povas komenci esti provita post kiam la kodo estas kompleta. Ajnaj problemoj estas zorge trovitaj kaj raportitaj de testistoj. Via projekto eble devos reiri al fazo unu por retakso se signifaj problemoj aperos.
- Livero/deplojo: La produkto estas finita ĉe ĉi tiu punkto, kaj via teamo sendas la liverojn por deplojo aŭ liberigo.
- vivtenado: La kliento ricevis la produkton kaj uzas ĝin. Via teamo eble devos evoluigi korektojn kaj ĝisdatigojn kiam problemoj aperos por ripari ilin. Denove, gravaj problemoj povas postuli reveno al la unua paŝo.
Avantaĝoj
- Simpla funkcii kaj administri: La Akvofalo-aliro estas simpla uzebla kaj komprenebla ĉar ĉiu projekto estas pritraktita en la sama sinsekva maniero. Antaŭ ol komenci Waterfall-projekton, la teamo ne bezonas havi ajnan antaŭan kompetentecon aŭ trejnadon. La akvofala alproksimiĝo estas tre strikta; ĉiu etapo havas aron de liveroj kaj revizio, simpligante ĝin administri kaj konservi.
- Bone dokumentita metodaro estas postulata: La dokumentado, kiu estas postulata de la akvofala metodaro, helpas klarigi la rezonadon malantaŭ la testoj kaj kodo. Aldone, ĝi kreas paperan spuron, se koncernatoj volas pliajn informojn pri certa fazo aŭ por estontaj iniciatoj.
- Devigo de disciplino: Ĉiu paŝo en akvofala projekto havas komencon kaj finon, faciligante komuniki progreson al koncernatoj kaj klientoj. La teamo povas malaltigi la eblecon maltrafi templimon metante postulojn kaj dezajnon unue antaŭ produkti kodon.
malavantaĝoj
- Povas esti malfacile kolekti precizajn postulojn: Paroli kun konsumantoj kaj koncernatoj por determini iliajn bezonojn estas unu el la komencaj etapoj de Akvofalo-projekto. En ĉi tiu frua etapo de la projekto, eble estos defie konstati iliajn apartajn postulojn. Klientoj ofte lernas pri siaj postuloj dum la projekto evoluas prefere ol esprimi ilin antaŭen.
- Ŝanĝoj malfacilas alĝustigi: La skipo ne povas rekomenci laboron post finado de fazo. Estas tre malfacile kaj multekoste reiri kaj ripari ĝin se ili lernas dum la testa fazo, ke funkcieco mankis dum la postprocezo.
- Programaro estas provizita post ĝia limdato: Du ĝis kvar fazoj de la projekto devas esti finitaj antaŭ ol la vera kodigo povas komenciĝi. Koncernuloj ne vidos funkcian programaron ĝis malfrue en la vivociklo kiel rezulto.
Kio estas Scrum?
Unu el la plej ŝatataj procezaj kadroj por praktiki Agile estas Scrum, kiu estas subaro de Agile.
Ĝi estas ripeta paradigmo por administri la kreadon de kompleksaj programoj kaj produktoj. Sprintoj, kiuj estas fikslongaj ripetoj, kiuj daŭras unu ĝis du semajnojn, ebligas al la teamo liberigi programaron laŭ regula horaro.
Koncernatoj kaj teamanoj kunvenas por diskuti la sekvajn paŝojn post ĉiu spurto. La roloj, respondecoj kaj renkontiĝoj en Scrum restas konstantaj.
Ekzemple, Scrum precizigas la sprintplanadon, ĉiutagan star-supren, sprintdemonstraĵon kaj sprintretrospektivon kiel la kvar ritojn kiuj disponigas ĉiun sprintstrukturon.
La teamo uzos vidajn artefaktojn kiel taskaj tabuloj aŭ bruldiagramoj dum ĉiu spurto por montri progreson kaj ricevi pliigajn sugestojn.
En scrum, la teamo kaj la produktposedanto laboras proksime kune por identigi kaj prioritatigi sisteman funkciecon. Ili atingas tion kreante produktan restaron, kiu enhavas ĉiujn taskojn necesajn por produkti programaron, kiu funkcias kiel celite.
Cimflakoj, nefunkciaj postuloj kaj funkcioj ĉiuj devus esti inkluditaj en la atendovico. Transfunkciaj teamoj devas taksi kaj registriĝi por liveri programarajn pliiĝojn dum kontinuaj Sprintoj, kiuj kutime daŭras 30 tagojn, post kiam la celoj estas establitaj.
Nur la teamo povas aldoni funkciojn al la Sprint post fari la restaron por tiu sprint.
Sekva Sprint-livero, la produkta restaro estas taksita kaj, se necese, reprioritigita, kaj la sekva liverebla aro estas elektita por esti parto de la sekva sprinto.
Scrum-procezo
- Rezultita produkto: Por mendi la erojn en la produkta restaro, la Produktposedanto kaj Scrum Teamo renkontas (la laboro pri la produkta restaro venas de uzantrakontoj kaj postuloj). La produkta restaro estas listo de ĉiuj dezirataj funkcioj por la produkto prefere ol listo de taskoj, kiuj devas esti finitaj. Post tio, la disvolva teamo elektas taskojn el la produkta restaro por plenumi dum ĉiu sprinto.
- Sprint-planado: Antaŭ ĉiu spurto, la Produktposedanto liveras al la teamo la ĉefajn erojn en la restaro ĉe sprint-planadrenkontiĝo. La grupo tiam elektas erojn el la produkta restarigo kiun ili povas fini dum la spurto kaj movas ilin al la spurtaro (kiu estas listo de taskoj por kompletigi en la spurto).
- Rafinado/preparado de la restaro: Por certigi, ke la restaro estas preta por la sekva spurto, la teamo kaj produktposedanto renkontas ĉe la fino de unu spurto. La teamo povas forĵeti uzantrakontojn kiuj ne plu estas trafaj, aldoni novajn, revizii la ordon en kiu ili devus esti traktitaj aŭ dividi uzantrakontojn en pli malgrandajn taskojn. Dum ĉi tiu "prizorgiga" renkontiĝo, oni certigos, ke la restaro inkluzivas nur aferojn trafajn, profundajn kaj konformajn al la celoj de la projekto.
- Scrum-renkontiĝoj ĉiutage: En 15-minuta starkunveno nomita la Ĉiutaga Scrum, ĉiu grupano diskutas siajn celojn kaj ajnajn problemojn kiuj aperis. Ĉiutage dum la spurto, la teamo partoprenas en la Ĉiutaga Scrum, kiu tenas ĉiujn en tasko.
- Kunveno por taksi la sprinont: La teamo prezentas sian laboron ĉe sprintrevizia renkontiĝo ĉe la fino de ĉiu sprinto. Anstataŭ raporto aŭ prezento de PowerPoint, ĉi tiu renkontiĝo devus inkluzivi veran pruvon.
- Retrospektiva sprintkunveno: La teamo diskutas iujn ajn modifojn, kiuj devas esti faritaj en la sekva spurto kaj kiel bone Scrum funkcias por ili ĉe la konkludo de ĉiu spurto. La teamo povas diskuti la pozitivajn aspektojn de la spurto, negativajn aspektojn kaj areojn por plibonigo.
Avantaĝoj
- Pli da respondeco de la teamo: Ne ekzistas projektestro instruanta la scrum-teamon pri kion fari kaj kiam. La laboro kiu povas esti finita en ĉiu spurto estas anstataŭe decidita fare de la teamo kiel tutaĵo. Ili ĉiuj kunlaboras kaj donas manon unu al la alia, plibonigante teamlaboron kaj kreskigante individuecon en ĉiu grupano.
- Plibonigita projektvidebleco kaj travidebleco: Estas malpli da miskomprenoj kaj necerteco, ĉar ĉiuj en la teamo konscias pri siaj respondecoj danke al oftaj starkunvenoj. La teamo povas trakti problemojn antaŭ ol ili foriĝas de kontrolo ĉar problemoj estas ekviditaj anticipe.
- Plibonigitaj kostaj reduktoj: Konstanta komunikado informas la teamon pri iuj problemoj aŭ ŝanĝoj tuj kiam ili okazas, kio helpas ŝpari kostojn kaj plibonigi kvaliton. Pli malgrandaj trajtopartoj provizas kontinuan religon kaj permesas fruan erarkorektadon antaŭ ol pli grandaj eraroj iĝas tro multekostaj por solvi.
- Simpla adaptiĝi al ŝanĝoj: Estas pli simple trakti kaj adaptiĝi al ŝanĝoj kiam estas oftaj reagoj kaj mallongaj spurtoj. Kiel ilustraĵo, se la teamo renkontas tutnovan uzantrakonton dum unu sprinto, ili povas rapide aldoni tiun funkcion al la sekva sprint ĉe la postreta rafina renkontiĝo.
malavantaĝoj
- Amplekso rampa danĝero: Pro la manko de fiksita findato, certaj Scrum-projektoj povas alfronti ampleksplodon. Koncernatoj povus esti allogitaj daŭre postuli pli da funkcioj se ne ekzistas limdato por kompletigo.
- Malbona Scrum Master povas dereligi ĉion: Projektestro ne samas kiel scrummaster. La Scrum Master devas fidi la teamon kiun ili kontrolas kaj neniam doni al ili instrukciojn. La Scrum Master ne havas potencon super la teamo. La projekto malsukcesos se la scrum-majstro provas administri la teamon.
- Precizecaj problemoj povus rezulti de malbone deklaritaj taskoj: Se taskoj ne estas klare specifitaj, projektelspezoj kaj horaroj ne estos precizaj. Planado fariĝas malfacila kaj spurtoj povas daŭri pli longe ol antaŭvidite se la komencaj celoj ne estas difinitaj.
- Sperto kaj dediĉo estas necesaj por teamo: Por ke la teamo sukcesu, roloj kaj devoj devas esti klare difinitaj. La Scrum Teamo postulas teamanojn kun teknikaj kapabloj ĉar ne estas klare difinitaj roloj (ĉiu faras ĉion). La teamo ankaŭ devas engaĝiĝi partopreni en la ĉiutagaj Scrum-sesioj kaj resti kune por la vivo de la projekto.
Lerta Vs Scrum
Kvankam Agile kaj Scrum uzas la saman metodaron, ekzistas iuj varioj inter la du. La Agile Manifesto skizas aron de principoj por krei programaron per ripeta evoluo.
Scrum, aliflanke, estas aro de gvidlinioj al kiuj devas esti aliĝitaj dum vi faras Agile programaron. Agile estas koncepto, dum Scrum estas tekniko por meti ĝin en praktikon.
Scrum estas metodo por efektivigi Agile, tial ili ambaŭ havas multajn aferojn en komuna. Ambaŭ aliroj estas ripetaj, prioritatas fruan kaj oftan programaran liveron, kaj akceptas ŝanĝon. Ili ankaŭ subtenas malfermitecon kaj daŭran evoluon.
Agile Vs Akvofalo
Rigida kontraŭ fleksebla plej bone priskribas la distingojn inter la Akvofalo-procezo kaj Agile. Dum Agile estas fluida kaj konstante ŝanĝanta, Akvofalo estas multe pli strikta, pli rigida metodaro.
Tiuj pliaj distingoj inter ili estas kiel sekvas:
- Agile ne postulas linearan aliron, dum Akvofalo estas sinsekva.
- Dum bezonoj ofte estas antaŭdifinitaj en Waterfall-projektoj, ili antaŭvidas ŝanĝi kaj adaptiĝi en Agile-iniciatoj.
- Kontraste al Agile, Waterfall-projektoj ne permesas modifojn esti faritaj al laboro kiu estis kompletigita en antaŭa stadio.
- La akvofalo estas organizita proceduro, en kiu vi devas fini ĉiun paŝon antaŭ ol pluiri al la sekva. Tamen, Agile estas fleksebla metodaro, kiu ebligas vin daŭrigi kun la projekto laŭ via propra ritmo.
Agile Vs Akvofalo Vs Scrum
- La akvofalo pliigas fidon je kio estos provizita tre baldaŭ post kiam ĝi estas planita. Agile dependas de la plej bonaj praktikoj de evolumedio. Ĉi tie, kelkaj projektriskoj povas esti bone administritaj ĉar la rezultoj estas kontinue taksitaj.
- Akvofalo ne antaŭvidas ke la teamo kaj projekto baziĝos en la sama loko. Dum scrum kaj lerta bezonas samlokigon de dungitoj.
- Agile temigas redukton de projekto-relaboro kaj instigas ŝanĝojn esti korpigitaj multe pli frue. Kontraste al la akvofalo, kiu respondas malsame, scrum ankaŭ ebligas fruan malkovron de ŝanĝoj.
- Pli kompakta skizo por la fina produkto estas provizita de lerta kaj scrum. Ĉi tio kreas problemon kun la promesoj faritaj al la aĉetanto. Kontraste, la akvofala grafiko donas al klientoj kaj programistoj pli bonan impreson pri la preta rezulto.
- Ĉiu el ĉi tiuj teknikoj havas aron da iloj por organizi kaj simuli la taskojn implikitajn en ilia kreado.
konkludo
Se vi sekvis ĝis nun kaj certas pri via scio pri la distingoj inter la Akvofalo, Agile kaj Scrum-procezoj, vi jam devus scii, kiu strategio funkcios plej bone por vi kaj via teamo.
La Akvofalo-tekniko, kiu estas por projektoj kun difinita amplekso, tempokadro kaj buĝeto, povas esti via plej bona elekto se vi ŝatas malmolajn regulojn kaj procedurojn kaj trovas, ke ili alportas klarecon.
Aliflanke, se la libereco kaj adaptebleco Agile proponas vin inspiras, ĝi povus esti kie vi devus atentigi.
Scrum estas la vojo por iri, tamen, se vi deziras iom da disciplino en fleksebla kadro.
Tamen, vi devas konsideri ĉi tiujn alirojn laŭ la projekto pri kiu vi laboras kaj via finfina rezulto.
Lasi Respondon