Toto je prvá časť krátkeho zrhnutia knihy Extreme Programming Explained. Je skôr na pripomenutie jednotlivých častí knihy (alebo aj inšpirácia pre jej prečítanie). Aj preto kombinácia s angličtinou. Pre úplné pochopenie jednotlivých častí je naozajlepšie prečítať si knihu samotnú.
Extreme Programming (XP) is about social change.
Prvá veta knihy. A najdôležitejšia. Môžete mať namakaný tím programátorov, ktorí budú robiť samostatne veci na 100%. Ale akonáhle ich chcete zapojiť do projektu, dať im viac úloh, prioritizovať, komunikovať… jednoducho po nich chcete, aby pracovali ako tím, bez zmeny na ľudskej úrovni to nepôjde.
It is about letting go of habits and patterns that were adaptive in the past, but now get in the way of us doing our best work. It is about giving up the defenses that protect us but interfere with our productivity. It may leave us feeling exposed.
Pri predstavovaní XP sú dôležité tri pojmy
- hodnoty (values) – sú pohľadom konkrétnej osoby na svet; filozofiou, ktorú vyznáva
- praktiky (practices) – veci, ktoré bežne robíme
- princípy (principles) – most medzi hodnotami a praktikami.
Hodnoty (values)
XP sa zameriava na päť dôležižých hodnôt, ktoré majú priamy vplyv na vývojársky (ale aj akýkoľvek iný) tím.
- komunikácia (communication) – dôležitá pre samotné fungovanie tímu a efektívnu spoluprácu
- jednoduchosť (simplicity) – vďaka komunikácii sa môžu veci zjednodušovať. Ak majú ľudia spolupracovať, jednoduchšie veci sú pochopené a akceptované skôr.
- feedback – priebežná a konkrétna spätná väzba je jednak zárukou dobre zvládnutej komunikácie a zároveň prispieva k lepšej spolupráci
- odvaha (courage) – ak vieš, kde je problém, vyrieš ho, poukáž naň, jednoducho niečo sprav. Povzbuď ostatných v tíme, aby nabrali odvahu tiež
- rešpekt (respect) – ak sa ľudia v tíme vzájomne nerešpekujú, ak im nezáleží na projekte, ani zvyšné hodnoty spolu nemusia stačiť
Samozrejme, tieto hodnoty nie sú fixne dané a niektoré sa môžu v jednotlivých tímoch líšiť.
Princípy (principles)
Hodnoty môžu príliš abstraktné a preto je dobré si určiť princípy, ktorých sa v tíme budete držať. XP odporúča nasledovné
- humanity – rovnováha medzi osobnýmí a tímovými potrebami
- economics – vždy treba brať ohľad na biznisové hodnoty, ciele a potreby. Vývoj softwaru je pre firmu tým užitočnejší, čím skôr vie priniesť reálnu hodnotu – „zarobiť peniaze“
- mutual benefits – najdôležitejší princíp a zároveň najtažšie uchopiteľný. V podstate sa treba vždy snažiť o win-win situáciu. Vývoj by mal byť rovnako kvalitný ako aj rýchly, efektívny a jednoduchý.
- self-similarity – snaha a použitie rovnakých nástrojov / riešení všade, kde je to možné
- improvement – vo vývoji softwaru je „dokonalosť“ sloveso – teda proces – niečo, čo nie je nikdy dokončené. Dokonalosť neexistuje, vieme sa k nej iba blížiť
- diversity – tímy potrebujú rozmanitosť. S rozmanitosťou prichádzajú konflikty. Preto je nutný rešpekt.
- reflection – dobré tímy sa zamýšľajú nad spôsobom svojej práce a zaujímajú sa aj o to, prečo pracujú. Analyzujú úspechý aj faily
- flow – sústavné doručovanie hodnoty v menších ale pravidelných častiach
- opportunity – Learn to see problems as opportunities for change.
- redundancy – The cost of the redundancy is more than paid for by savings from not having the disaster.
- failure – If you’re having trouble succeeding, fail. Ak nevieš, ktoré z troch riešení je najlepšie, skús všetky. Ak nie je ani jedno správne, aspoň sa niečo nové naučíš.
- quality – Quality is not a control variable. Projects don’t go faster by accepting lower quality.
- baby steps – malé zmeny sa robia rýchlejšie a ľahšie ako veľké projekty. A ak nevyjdú, napácha sa menšia škoda.
- accepted responsibility – Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t.
Praktiky (practices)
Praktiky (alebo inak aj nástroje) sú v rámci XP rozdelené na dve skupiny:
- primárne (primary) – tie, ktoré je dobré a bezpecné zavádzať hocikedy
- sekundárne (corollary) – ich zavádzanie môže byť komplikovanejšie, pretože si vyžadujú fungovanie iných praktík
Primárne praktiky (primary practices)
Veľa z nich je už dnes bežným pojmom a asi takmer každý tím sa a on ako-tak snaží.
- sit together – pokiaľ to je aspoň trocha možné, mal by tím sedieť spolu v jednej miestnosti.
- whole team – ľudia musia vnímať, že sú súčasťou tímu, že sú v tom spolu a podporujú sa navzájom pri práci, učení a spoločnom raste
- informative worksprace – teda ak hocikto príde na pracovisko, vie mať rýchlo prehľad o stave jednotlivých projektov
- energized work – Work only as many hours as you can be productive and only as many hours as you can sustain. Nadčasy a vyčerpanie kvalite práce nepridávajú
- pair programming – toto je asi najviac diskutabilná časť XP. Zároveň je to ale pojem, s ktorým si asi väčšiná ľudí XP spája a myslí si, že XP je iba o tom. Opak je pravdou. Párové programovanie je (ako môžete vidieť) iba jednou časťou spektra.
- stories – Plan using units of customer-visible functionality.
- weekly cycle – Plan work a week at a time. … Planning is a form of necessary waste. It doesn’t create much value all by itself. Work on gradually reducing the percentage of time you spend planning.
- quarterly cycle – Plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.
- slack – It is important in an atmosphere of distrust and broken promises to meet your commitments. Preto je lepšie sľubovať menej (ale presnejšie) a prípadne doručiť viac, ako naopak.
- ten-minute build – build by nemal trvať viac ako desať minút, aby nebol pre vývojára demotivujúci
- continuous integration – Integrate and test changes after no more than a couple of hours.
- test-first programming – Write a failing automated test before changing any code.
- incremental design – Invest in the design of the system every day. Strive to make the design of the system an excellent fit for the needs of the system that day.
Sekundárne praktiky (corollary practices)
Kent Beck o týchto praktikách hovorí ako o komplikovaných alebo dokonca nebezpečných, ak sa ich tím rozhodne zaviesť bez toho, aby fungovali základné praktiky. Preto ich označil ako doplnkové alebo naväzujúce.
- real customer involvement – Make people whose lives and business are affected by your system part of your team. Visionary customers can be part of quarterly and weekly planning.
- incremental deployment – Find a little piece of functionality or a limited data set you can handle right away. Deploy it. You”ll have to find a way to run both programs in parallel, splitting and merging files or training some users to use both programs. This scaffolding, technical or social, is the price you pay for insurance.
- team continuity – Keep effective teams together. Ignoring the value of relationships and trust just to simplify the scheduling problem is false economy.
- shrinking teams – As a team grows in capability, keep its workload constant but gradually reduce its size. This frees people to form more teams.
Figure out how many stories the customer needs each week. Strive to improve development until some of the team members are idle; then you’re ready to shrink the team and continue. - root-cause analysis – Every time a defect is found after development, eliminate the defect and its cause. The goal is not just that this one defect won’t ever recur, but that the team will never make the same kind of mistake again.
- shared code – Anyone on the team can improve any part of the system at any time.
- code and tests – Code and Tests is a practice that is easy to approach a little at a time.
- single code base – There is only one code stream. You can develop in a temporary branch, but never let it live longer than a few hours.
- daily deployment – Put new software into production every night.
- negotiated scope contract – Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system. Reduce risk by signing a sequence of short contracts instead of one long one.
- pay-per-use – Money is the ultimate feedback. Charge for every time the system is used.
Tieto praktiky (primárne aj sekundárne) nazýva Kent Beck zo svojej skúsenosti the core of excellence for software development teams.
Na záver pre mňa najdôležitejší odstavec knihy:
If you have six weeks to get a project done, the only thing you control is your own behavior. You can’t control others‘ expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It’s not my job to „manage“ someone else’s expectations. It’s their job to manage their own expectations. It’s my job to do my best and to communicate clearly.