Toto je druhá časť krátkeho zrhnutia knihy Extreme Programming Explained (prvá čast je tu). 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ú.
Tu vyberám iba niektoré kapitoly a myšlienky, ktoré ma oslovili. Stále odporúčam radšej si prečítať celú knihu. 🙂
The whole XP team
Many people’s perspectives must come into play for effective software development to occur. The XP practice Whole Team suggests that a variety of people work together in interlinking ways to make a project more effective. They have to work together as a group for each to be successful.
Táto kapitola popisuje úlohy, ktoré sa v XP tíme vyskytujú a ako vzájomne interagujú. Dôležité na tejto časti je uvedomenie, že pri zefektívňovaní procesu vďaka princípom XP to nie je iba o programátoroch, ktorí musia zmeniť mindset. Súčasťou efektívneho XP tímu sú testeri, architekti, projektoví a produktoví manažéri, vedenie firmy (Executives provide an XP team with courage, confidence, and accountability.), technical writers, interaction designers (toto som nevedel rozumne preložiť do slovenčiny), užívatelia, programátori, HR (oddelenie ľudských zdrojov – musí upraviť spôsob prijímania nových ľudí a pravidelné pohovory a odmeňovanie).
Roles on a mature XP team aren’t fixed and rigid. The goal is to have everyone contribute the best he has to offer to the team’s success.
Teória úzkych miest (theory of constraints)
Find opportunities for improvement in software development by first figuring out which problems are development problems.
Teória úzkych miest je metóda riadenia, ktorá hovorí, že v každom systéme sa vyskytuje minimálne jedno úzke miesto (bottleneck), ktorého odstránením (teda jeho úpravou/optimalizáciou – zvýšením priepustnosti) sa zvýši výkonosť celého systému (a v tom okamihu sa stane úzkym miestom zasa niečo ďalšie, čo „brzdí“ výkonnosť systému).
Táto teória vyšla pôvodne z výrobných procesov, kde sa dá úzke miesto často celkom jednoducho identifikovať. Pri vývoji softwaru môže byť správny prístup „tricky“, pretože identifikovať úzke miesto sa môže zdať veľmi jednoduché (viac programátorov = viac softwaru), ale pravda je väčšinou niekde inde.
Vývoj softwaru nie je iba písaní kódu. Začína sa ideami o tom, čo je treba spraviť, spísaním zadania (niektorí používajú „story cards“), písaním testov a kódu, nasadením a školením, monitorovaním a údržbou a končí (alebo znovu začína) dorábaním nových funkcionalít. Úzke miesto sa môže nachádzať hocikde v tomto procese (nepresné alebo nepremyslené zadanie, ktoré vo výsledku nie je ani dôležité a brzdí tak iné projekty, nedostatočné testy, ktoré majú vplyv na funkčnosť, nedostatočná komunikácia, dodávanie postupne namiesto naraz).
Sometimes XP can facilitate shifting the constraints out of software development completely, so XP will have ripple effects throughout an organization applying it.
Planning: Managing Scope
Táto čast je must-read a mal by byť o nej samostatný článok (a aj ten by bol iba prerozprávaním tejto kapitoly). Preto iba pár odstavcov, ktoré sa mi páčili.
A mutually agreed-upon plan, adjusted when necessary to reflect changing reality, suggests a respectful, mutually valuable relationship.
Part of planning is deciding what to do next out of all the possibilities. Planning is complicated because the estimates of the cost and value of stories are uncertain. The information on which you base these decisions changes. We use feedback to improve our estimates and make decisions as late as possible so they are based on the best possible information. That’s why planning is a daily, weekly, and quarterly activity in XP. The plan can change to fit the facts as they emerge.
Plan at every timescale with these four steps:
1. List the items of work that may need to be done.
2. Estimate the items.
3. Set a budget for the planning cycle.
4. Agree on the work that needs to be done within the budget. As you negotiate, don’t change the estimates or the budget
Everyone on the team needs to be heard. Planning provides a forum in which the team acknowledges wishes, but only commits to needs.
Planning is something we do together. It requires cooperation. Planning is an exercise in listening, speaking, and aligning goals for a specific time period. It is valuable input for each team member. Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony.
Testing: Early, Often, and Automated
Tu sa dozviete o tom, prečo písať testy. A potom ich automatizovane spúšťať pred nasadením na server. Všetci vieme, prečo to je dobré (ak náhodou nie, tak táto kapitole pre vás), ale nie všetci to robíme (aj na teba v zrkadle sa pozerám!). Treba to jednoducho dostať do hlavy, rúk a dennej rutiny.
Toyota production system (TPS)
Toyota eliminates wasted effort at every step of the process of producing cars. If you eliminate enough waste, soon you go faster than the people who are just trying to go fast.
Taiichi Ohno, the spiritual leader of TPS, says the greatest waste is the waste of overproduction. If you make something and can’t sell it, the effort that wen into making it is lost. … Software development is full of the waste of overproduction: elaborate architectures that are never used; code that goes months without being integrated, tested, and executed in a production environment… we need to use output immediately in order to get feedback we need to eliminate waste.
Requirements gathering, for instance, will not improve by having ever more elaborate requirements-gathering processes but by shortening the path between the production of requirements detail and the deployment of the software specified. Using requirements detail immediately implies that requirements gathering isn’t a phase that produces a static document; but an activity producing detail, just before it is needed, throughout development.
Applying XP
Applying XP and seeing dramatic results takes a while, more like years than weeks. You should see big improvements in the first weeks and months, but those improvements only set the stage for the big leaps forward that happen further down the road.
The way to begin organizational change is still to start with yourself. It is the one change you have control over. First develop your skills, then put them into service. Leading by example is a powerful form of leadership.
