Agilní experti vs Agilní manifest

Myslíte si, že váš „místní agilní expert“ četl agilní manifest? Máš? No, není to problém ... pokud nepoužíváte slovo „Agile“ denně! Ale pokud to uděláte (nebo váš místní odborník)… dobře - to je něco jako lidé, kteří příliš mluví o náboženství, ale neotevřeli Bibli (výstraha politické korektnosti) ani svatou knihu podle svého výběru, protože jejich třídy literatury Před 10 lety ... Nelíbí se nám. Z důvodu.

Dobře, nekomentujeme ostatní lidi a jejich názory. Pojďme místo toho projít „Agilní bibli“ krok za krokem.

Citace z Agile Manifesto budou uvedeny v

tento druh textového bloku

a naše komentáře budou uvedeny v pravidelné odrážce, jako je tato. Pojďme!

Manifest, jediný a jediný!

Naší nejvyšší prioritou je spokojenost zákazníka
prostřednictvím včasného a nepřetržitého doručení
hodnotného softwaru.

To je skvělý nápad! V té době to bylo opravdu revoluční! Realizace této myšlenky je však o něco těžší, než by těchto pár řádků mohlo vnímat.

Hlavní problém: Každý, kdo měl přímý kontakt se zákazníkem, ví, že bod tohoto manifestu je alespoň poněkud složitý.

Je smutné, že zákazník si není vždy jistý, co chce, nebo chce příliš mnoho věcí najednou, a nemůže je správně upřednostnit! Navíc se může stát, že některé z těch věcí, které si zákazník myslel, později nechtěl…

Pokud to odložíme stranou, bod Manifestu dokazuje jeho hodnotu pro úspěch produktu! Tyto výjimky by však NEMĚLY být opomíjeny, protože mohou být fatální!

Další bod se týká něčeho podobného, ​​pokračujme v tomto tématu.

Vítejte měnící se požadavky, dokonce pozdě
rozvoj. Agilní procesy využívají změnu
konkurenční výhoda zákazníka.

To je skvělé. Ale neustálé otáčení a tlak na vývojový tým činí produkt křehkým. Rychlé kódování se spoustou přesměrování projektů snižuje kvalitu kódu produktu, takže změny jsou těžší. Racionálnější a klidnější vývoj zvyšuje účinnost provádění změn v pozdějších fázích vývoje produktu. Souhlasíme s tím, že změny by měly být vítány, ale ostatní ustanovení o smlouvě / dohodě by měla být také úměrně změněna! V mnoha případech se očekává, že produkt bude nasazen ve stejnou dobu, jako by tomu bylo v případě, že by nebyly vyžadovány žádné další změny. Není vpohodě.

Agility je o připravenosti na očekávané změny a ne o změně všeho a vždy. Ti, kteří jsou akreditováni pro komunikaci s potenciálním klientem / zákazníkem, by měli od samého začátku vyjednat realistickou dohodu. 10 minut s perem a papírem ve správný čas (začátek projektu) šetří dny, týdny a dokonce měsíce vývoje (přesměrování, otočení, změna) v pozdějších fázích! Toto prověšení v začátcích produktů by mělo být považováno za neprofesionální, protože je to opravdu hodně! „Pojďme jen získat klienta, později si pomyslíme na něco, co dokončíme práci“ mentalita je neetická a příliš často přichází na vývojáře, aby „zachránili den“ (práce přesčas, pracovní víkendy, práce z domova, práce v stresující prostředí)… Ne cool. A opravdu - ani agilní.

Dodejte pracovní software
často z a
pár týdnů až pár měsíců, s
upřednostňuje kratší časové období.

S touto mám jen dobré zkušenosti. Poskytuje možnosti zpětné vazby ke zlepšení učení při trakčním testování a učení. Skvělé věci, pokud je Agilní koncept použitelný při vývoji softwaru potřebného typu produktu. (Ne vždy, věřte tomu nebo ne.)

Obchodní lidé a vývojáři musí pracovat
denně v průběhu celého projektu.

Dobře, možná ne denně, ale také - palec nahoru! My (lidé) se nám za posledních 15 let nepodařilo tento zničit ... Dejte nám čas.

Budujte projekty kolem motivovaných jednotlivců.
Poskytněte jim prostředí a podporu, kterou potřebují,
a důvěřujte jim, že svou práci zvládnou.

V tomto případě většina takzvaných agilistů neprojde agilním manifestem. Často chybí úcta k jednotlivcům, kteří jsou, pokud ne odborníci, stále lepšími odborníky s ohledem na jejich odbornost, než „agilní“ projektový manažer. Díky tomu se manažer příliš zapojuje do práce ostatních lidí, což jednotlivě prolomí důležitá „strojová zařízení“. Snížení další agility stroje a spolehlivosti při změnách. Což je protilehlé.

Nejúčinnější a nejefektivnější metoda
zprostředkování informací do a uvnitř vývoje
tým je osobní rozhovor.

Proti tomuto nemůžeme nic říct. Naopak, hurá za to!

Pracovní software je primárním měřítkem pokroku.

Ano. Problém je v tom, že mnoho z tzv. Agilistů tuto klauzuli také nerespektuje.

Agilní procesy podporují udržitelný rozvoj.
Sponzoři, vývojáři a uživatelé by měli být schopni
udržovat konstantní tempo po neomezenou dobu.

Těžko dosáhnout, ale samozřejmě - skvělé vodítko.

Trvalá pozornost k technické dokonalosti
a dobrý design zvyšuje pohyblivost.

Bohužel, takzvaní agilní projektoví manažeři na to často zapomínají, což má vážné, ne-li fatální následky.

Jednoduchost - umění maximalizace částky
nedokončené práce - je zásadní.

Zdravím, jednoduchost!

Nejlepší architektury, požadavky a návrhy
vynoří se z organizujících se týmů.

Ave!

V pravidelných intervalech tým přemýšlí o tom, jak
aby se stala efektivnější, pak naladí a upraví
jeho chování podle toho.

Amen!