Judrūs ekspertai prieš judrų manifestą

Kaip manote, ar jūsų „vietinis judrus ekspertas“ perskaitė „Agile“ manifestą? Ar turi? Na, tai nėra problema ... jei nevartosite žodžio „judrus" kasdien! Bet jei jūs tai darote (arba jūsų vietinis ekspertas) ... gerai, tai yra kažkas panašaus į žmones, kurie per daug kalba apie religiją, bet nuo savo literatūros pamokų neatidarė Biblijos (politinio korektiškumo įspėjimo) ar savo pasirinktos šventos knygos Prieš 10 metų ... Mums jie nepatinka. Dėl priežasties.

Gerai, gerai, nekomentuokime kitų žmonių ir jų nuomonės. Vietoj to, pereikime „Agile Bibliją“ žingsnis po žingsnio.

Agile manifesto citatos bus pateiktos 2006 m

tokio tipo teksto blokas

ir mūsų komentarai bus pateikiami ta pačia įtrauka, kaip šis. Eime!

Vienintelis manifestas!

Mūsų prioritetas yra patenkinti klientą
per ankstyvą ir nuolatinį pristatymą
vertingos programinės įrangos.

Tai tokia puiki idėja! Tuo metu, kai jis buvo pagamintas, tai buvo tikrai revoliucinga! Bet įgyvendinti šią idėją yra kur kas sunkiau, nei galėjo suvokti šios kelios eilutės.

Pagrindinė problema: Visi, tiesiogiai bendravę su klientu, žino, kad šis manifesto punktas yra bent šiek tiek sudėtingas.

Deja, klientas ne visada yra tikras, ko nori (-ų), ar (-ių) nori per daug dalykų vienu metu, ir negali jiems tinkamai suteikti prioritetų! Be to, gali būti, kad kai kurie iš tų dalykų, kuriuos klientas galvojo (-us), bet vėliau nenorėjo…

Jei atidėtume tai - manifesto esmė įrodo jo vertę produkto sėkmei! Tačiau šios išimties NEGALI pamiršti, nes jos gali būti mirtinos!

Kitas punktas apima kažką panašaus, tęskime šią temą ten.

Sveikiname besikeičiančius reikalavimus, net vėlai
plėtra. Agile procesai keičiasi
kliento konkurencinį pranašumą.

Tai puiku. Tačiau nuolatinis pasukimas ir spaudimas plėtros komandai daro produktą silpną. Dėl greito kodavimo ir daugybės projekto peradresavimų produkto kodo kokybė tampa prasta, todėl pakeitimai tampa sunkesni. Racionalesnis ir ramesnis tobulinimas pagerina pakeitimų atlikimo vėlesniuose produkto kūrimo etapuose efektyvumą. Mes sutinkame, kad pokyčiams turėtų būti pritarta, tačiau proporcingai turėtų būti keičiamos ir kitos sutarties / susitarimo sąlygos! Daugeliu atvejų tikimasi, kad produktas bus diegiamas tuo pačiu metu, kaip ir tuo atveju, jei nebūtų reikėję papildomų pakeitimų. Ne kietas.

Judrumas reiškia pasiruošimą laukiamiems pokyčiams, o ne viską keičiant visada ir visada. Tie, kurie yra akredituoti bendrauti su potencialiu klientu / klientu, nuo pat pradžių turėtų derėtis dėl tikroviško susitarimo. Dažnai 10 minučių su rašikliu ir popieriumi tinkamu laiku (projekto pradžia) sutaupo dienų, savaičių ir net vystymo mėnesius (nukreipimas, pasukimas, keitimas) vėlesniais etapais! Šis produktų išpūtimo pradžia turėtų būti laikomas neprofesionaliu, nes to tikrai yra! Mąstymas „tegul tik surenka klientą, vėliau sugalvosime ką nors baigti“ yra neetiškas, o kūrėjams dažnai tenka „taupyti dieną“ (viršvalandžiai, savaitgaliai, darbas namuose, darbas namuose). aplinkinis stresas) ... Ne kietas. Ir tikrai - net ne judrus.

Pristatykite veikiančią programinę įrangą
dažnai, nuo a
pora savaičių iki poros mėnesių su
pirmenybė trumpesniam laikotarpiui.

Aš turiu tik gerą patirtį su tuo. Tai suteikia galimybių ankstyvam traukos tikrinimui, mokymuisi pagerinti. Puiku, jei „Agile“ koncepcija pritaikoma kuriant reikiamo tipo produktus. (Ne visada taip, tikėkite ar ne.)

Verslininkai ir kūrėjai turi dirbti
kartu kiekvieną dieną viso projekto metu.

Gerai, gal ne kasdien, bet taip pat - nykštys aukštyn! Mums (žmonėms) nepavyko to sugadinti per pastaruosius 15 metų ... Duokite mums laiko.

Kurkite projektus aplink motyvuotus asmenis.
Suteikite jiems reikiamą aplinką ir palaikymą,
ir patikėk jiems, kad darbas bus atliktas.

Štai kur dauguma vadinamųjų agilistų nesugeba atlikti Agile manifesto. Jiems dažnai trūksta pagarbos asmenims, kurie, jei ne ekspertai, vis tiek yra geresni specialistai, atsižvelgiant į jų kompetencijos sritį, nei „judrus“ projekto vadovas. Tai verčia vadovą per daug įsitraukti į kitų žmonių darbą, todėl vienas po kito sulaužomos svarbios „mašinos pavaros“. Dar mažesnis „mašinos“ judrumas ir patikimumas pokyčiams. Kuris yra priešingas judrus.

Veiksmingiausias ir efektyviausias
informacijos perteikimas plėtrai ir jos viduje
komanda yra tiesioginis pokalbis.

Na, mes nieko negalime pasakyti prieš šį. Priešingai, kruopščiai už tai!

Pagrindinė pažangos priemonė yra veikianti programinė įranga.

Taip. Problema ta, kad daugelis vadinamųjų agilistų taip pat nesilaiko šios sąlygos.

Judrūs procesai skatina darnų vystymąsi.
Rėmėjai, kūrėjai ir vartotojai turėtų turėti galimybę
išlaikyti neribotą laiką pastovų tempą.

Sunku pasiekti, bet, žinoma, puiki rekomendacija.

Nuolatinis dėmesys techninei kompetencijai
o geras dizainas padidina judrumą.

Ir vėlgi, deja, vadinamieji judrūs projektų vadovai dažnai pamiršta šį dalyką, sukeldami rimtas, jei ne mirtinas pasekmes.

Paprastumas - meno maksimizavimas
neatliktų darbų - būtina.

Sveika, paprastumas!

Geriausios architektūros, reikalavimai ir projektai
atsiranda iš savarankiškai organizuojančių komandų.

Ave!

Reguliariais intervalais komanda svarsto, kaip
kad jis taptų efektyvesnis, tada derinamas ir derinamas
atitinkamai jos elgesys.

Amen!