Oblíbenou metodou agilního vývoje softwaru je i Extreme Programming (XP). Na rozdíl od Scrum procesu, XP je více zaměřeno na jednotlivé praktiky než na konkrétní proces. Míří přímo na vývojáře a testery, a proto je často vnímáno více jako soubor praktik agilního vývoje či agilního developmentu, než metoda řízení projektů. Jednotlivé praktiky se velice často používají i v rámci Scrum procesu.
Takže o čem je vlastně Extreme Programming? XP říká, že když je něco dobré, tak proč to nedělat pořád. A proč nedělat jenom to. Jednoduchý princip. Dělejte jen to, co se Vám osvědčilo. Nic převratného v tom není. Ostatně kdo by chtěl opakovat pořád stejné chyby. XP dále aplikuje tyto čtyři hodnoty: jednoduchost, komunikace, zpětná vazba, odvaha.
Dělejte jen na věcech, na kterých opravdu záleží. Každý den. Bez vyjímek. Nevymýšlejte složité designy a architektury, nepište věci, které nikdo nepotřebuje. Uvedu příklad. Když si zákazník u Vás objedná koloběžku, Váš tým specialistů se obvykle usnese, že ‘To už známe, on zákazník vždy chce koloběžku, pak si ji zkusí, zjistí, že nemá rovnováhu a my to pak předěláváme na tříkolku.‘ A tak se vytvoří silný ‘core‘, tedy ‘podvozek‘ tak, aby z toho šlo snadno udělat cokoliv se dvěma a více koly. Jak to obvykle dopadne? Zákazník si z toho objedná třeba ultralight, a ten těžký podvozek nás pak celý projekt potáhne k zemi.
Tedy jen tak, že budete komunikovat se zákazníkem, abyste věděli, co potřebuje, a následně budete dělat jen věci, která jsou opravdu potřeba, a až tehdy když jsou potřeba, zajistíte, že zákazník dostane to, co opravdu potřebuje. A dostanete to rychle. Abyste byli v tomto procesu úspěšní, musíte umět naslouchat a učit se ze svých chyb. Učit se, co jste dělali dobře a pak už dělat jen to co se Vám osvědčilo. Jen tak budete efektivní a lepší než konkurence.
Naučte se, jak transformovat firmy, měnit firemní kulturu a leadership pomocí Agilního & Enterprise Koučinku. Podívejte se na vypsaná školení zaměřených na Agile a Scrum na Sochova.cz. Pořiďte si kopii populární knihy The Great ScrumMaster: #ScrumMasterWay, Skvělý ScrumMaster #ScrumMasterWay, Agilní lídr: Využití síly vlivu nebo Agilní Metody Řízení Projektů.
Pekné, Zuzi.
Mám k tomu akorát dilema:
Zákazník často chce různé věci, které mohou v rozporu s tím, jak funguje systém. Jak udržíš rovnováhu? Tj. rozuměj kvalitu systému, nějakou koncepci atd. vs. dělat jen to, co zákazník chce?
Uvedu příklad ze života:
Máme systém, který je docela hodně konfigurovatelný. Tj. zákazník si sám může vytvořit nový produkt a není na nás závislý (do určité míry). Produkty se dají dědit.
A teď potřebuje, aby určité části produktu se nenabízely v podproduktu. V infrastruktuře to není. Systematické řešení by bylo pracnější a časově náročnější, tak se vymyslí “dočasné” řešení, které je v systému přes rok. A jednou za čas je dočasné řešení potřeba rozšířit 🙂
Co s tím?
ITíci nechtějí dělat dočasná řešení. Já nechci dělat dočasná řešení. Z obchodního pohledu možná je lepší udělat dočasné řešení 😀 Protože teď za nějaké peníze vyřeším nějaký problém, až se ten problém trošku zvětší a začne zákazníka pálit, tak za podobné peníze dočasné řešení rozšíříme 🙂 ALE: funguje to jen pokud systém není celý postaven na dočasných řešeních. Jenže zobecnění může být značně náročné, před tím jsem investoval úsilí do dočasných řešení. Pravda, budu zobecňovat to, co už bylo 5x požadováno, takže je šance, že to zobecním dobře.
Co s tím?
Oleg
Ahoj,
V podstate sis sam odpovedel 🙂 Obchodne je to lepsi. Az to prestane byt unosne, nebo az to zacne mit smysl, udelej refactoring. Delej ho jen tehdym kdyz je to opravdu potreba. Chapu ze vyvojari chteji delat superdesigny, ale je na PO aby vysvetlil potreby businessu a naopak businessu vysvetlil ze je obcas nutne neco prepsat (rychlost, bezpecnost, … ). Duvodem ale nemuze byt ze se to ITikum libi vic 😉
Zuzi