.

0 (hodnocen0 x )

BK

1. vyd.

Praha : Grada, 2002

158 s.

ISBN 80-247-0300-9 (brož.)

Moderní programování

angličtina

Další názvový údaj z obálky: vysvětlení základních principů XP, jak při vývoji programů utrácet pomaleji a získávat peníze rychleji, jak dosáhnout stabilního a předvídatelného vývoje programů, strategie plánování, návrhu, vývoje a testování programu, jak zavést XP a co jeho zavedení ztěžuje, kde bychom XP zavádět neměli

Přeloženo z angličtiny

Obdahuje předmluvu, úvod, slovníček, rejstřík

Bibliografie: s. 130-136

Programování extrémní - příručky

000029561

Obsah // Předmluva 9 // Úvod 10 // l.část Problém // 1. Základní problém: riziko // Vývoj programového vybavení selhává a nedodává požadované hodnoty. Toto selhávání má obrovský vliv na ekonomický a lidský potenciál. Musíme najít nový způsob, jak software vyvíjet. // 2. Vývojová epizoda // Každodenní programování postupuje od úkolu, který je jasné spojen s funkcí požadovanou zákazníkem, přes testy, implementaci a návrh až po integraci. Malá část všech činností vývoje softwaru je vložena do všech epizod. // 3. Ekonomická stránka vývoje softwaru // Ekonomickou hodnotu našeho vývoje softwaru musíme zvýšit tím, že budeme vydávat peníze pomaleji a příjmy získávat rychleji. Je pravděpodobné, že tím zvýšíme délku produktivního života projektu. Ale nejvíc ze všeho musíme rozšířit možnosti výběru pro naše rozhodování. // 4. Čtyři proměnné // V našich projektech budeme ovládat čtyři proměnné: náklady, čas, kvalitu a šíři zadání. Nejcennější formu řízení nám poskytuje jedna z nich: šíře zadání. // 16 // 19 // 21 // 24 // 5. Náklady na změnu 28 // Za určitých okolností lze exponenciální růst nákladů na software měnící se v čase vyrovnat. Pokud můžeme křivku vyrovnat, přestanou platit staré předpoklady o nejlepším způsobu, jak vyvíjet software. // 6. Učíme se řídit 32 // Vývoj programového vybavení musíme řídit prováděním mnoha malých

korekcí - nikoli několika velkých úprav - podobně jako při řízení auta. To znamená, že budeme potřebovat zpětnou vazbu abychom věděli, kdy jsme trochu odbočili. Budeme potřebovat mnoho příležitostí na provádění korekcí a musíme být schopni tyto korekce dělat za přijatelné náklady. // 34 // 7. Čtyři hodnoty // Budeme úspěšní, když budeme mít styl zachovávající důslednou sadu hodnot, které slouží potřebám člověka i společnosti: komunikace, jednoduchost, zpětná vazba a odvaha. // 8. Základní principy 39 // Ze čtyř hodnot odvodíme zhruba tucet základních principů, které povedou // ? t/ // nas // se s těmito principy poměřují. // 9. Zpět ? základům // 45 // Chceme udělat vše co musíme, abychom docílili stabilního a předvídatelného vývoje softwaru. Ale na cokoli navíc nemáme čas. Čtyřmi základními vývojovými činnostmi jsou psaní zdrojového textu, testování, poslouchání a navrhování. // 2. část Řešení 51 // 10. Zběžný přehled 52 // Spolehneme se na synergie mezi jednoduchými postupy, které byly před mnoha lety často opouštěny pro svou údajnou nepraktičnost nebo naivitu. // 11. Jak by to mělo fungovat? 59 // Postupy se vzájemně podporují. Nedostatek jednoho postupu pokryjí přednosti těch ostatních. // 12. Strategie řízení 65 // Celkový projekt budeme řídit pomocí základních pravidel obchodu: vývoj po fázích, rychlá a konkrétní zpětná vazba, jasná artikulace

potřeb na vyvíjený systém a využití odborníků na speciální úkoly. // 13. Strategie vybavení 69 // Pro náš tým vytvoříme otevřené pracoviště s malými privátními prostory na jeho obvodu a společnou programovací oblastí uprostřed. // 14. Rozdělení odpovědností mezi vývoj a vedení společnosti 72 // Jedním klíčem naší strategie je udržovat soustředění technických lidí na technické problémy a vedoucích pracovníků na problémy společnosti. Projekt musí být řízen rozhodováním vedení, ale tato rozhodnutí musí obsahovat technická rozhodnutí o nákladech a riziku. // // 15. Strategie plánování // Plánujeme tak, že rychle načrtneme celkový plán, který budeme upřesňovat více a více v čím dál tím kratších časových intervalech: roky, měsíce, týdny, dny. Plán vytvoříme rychle a levně, takže bude mít malou setrvačnost, když jej musíme měnit. // 16. Strategie vývoje // Na rozdíl od strategie řízení představuje strategie vývoje radikální odklon od zdravého selského rozumu. Budeme pečlivě vytvářet řešení dnešního problému dnes a věřit tomu, že zítřejší problém vyřešíme zítra. // 17. Strategie návrhu // Budeme nepřetržitě utvářet návrh systému a začneme od samotného jednoduchého počátku. Zbavíme se veškeré flexibility, která se neosvědčí. // 18. Strategie testování // Napíšeme testy vždy o něco dřív, než vlastní zdrojový text. Tyto testy zachováme

jednou provždy a budeme je často spouštět všechny najednou. Rovněž tak si odvodíme testy z pohledu zákazníka. // 3. část Implementace XP // 19. Přijetí XP // XP budeme přijímat vždy jen po jednom postupu, který pokryje ten nejpalčivější problém našeho týmu. Jakmile se již tento problém nejeví akutní, přejdeme ? dalšímu. // 20. Postupné zavádění XP // Projekty, které chtějí změnit svou současnou kulturu, jsou daleko běžnější než projekty, které mohou vytvořit novou kulturu od základu. U probíhajících projektů budeme XP zavádět postupně po menších částech: začneme testováním nebo plánováním. // 21. Životní cyklus ideálního projektu XP // Ideální projekt XP projde krátkou úvodní vývojovou fází, kterou následují léta paralelní provozní podpory a zdokonalování, a nakonec elegantní odchod do výslužby, když už projekt nemá žádný smysl. // 22. Lidské role 110 // Aby mohl extrémní tým fungovat, musí se naplnit určité role: programátor, zákazník, kouč a stopař. // 23. Pravidlo 20-80 117 // Úplná hodnota XP se projeví až poté, co budou zavedeny všechny postupy. Mnoho postupů lze přijmout jeden po druhém, ale jejich účinky se znásobí, jakmile budou používány současně. // 24. Co ztěžuje XP 118 // Ačkoli mohou programátoři vykonávat jednotlivé postupy, je těžké složit všechny součásti a udržet je pohromadě. Co ztěžuje XP jsou především emoce a zejména

strach. // 25. Kdy bychom neměli XP zkoušet // Přesné hranice XP ještě nejsou zcela jasné. Některé absolutní překážky, které zabrání XP v činnosti, však existují: velké týmy, nedůvěřiví zákazníci a technologie, které nepodporují elegantní změny. // 121 // 26. XP v činnosti 124 // XP se umí přizpůsobit běžným formám smluv, i když s drobnými úpravami. Zejména smlouvy typu pevná cena za pevnou šíři zadání se stanou smlouvami typu pevná cena za pevný termín a zhruba pevnou šíři zadání, jestliže budou probíhat současněs „Plánovací hrou". // 21. Závěr // Bibliografie opatřená poznámkami 130 // Slovníček 137 // Rejstřík // 140