Практики от Extreme Programming в Scrum
Разберете защо Scrum има нужда от практики от Extreme Programming като TDD, pair programming и непрекъсната интеграция, за да изгради наистина завършен Increment.
Scrum ви казва кога да се срещате, как да инспектирате напредъка и кой за какво носи отговорност. Той умишлено пропуска въпроса как точно се пише софтуер. Ръководството за Scrum от 2020 г. изисква използваем, ценен Increment, който отговаря на Definition of Done до края на всеки Sprint. Въпреки това, в него не се споменават стратегии за тестване, архитектура или качество на кода. Ако даден екип приеме Scrum без техническа дисциплина, той просто се втурва по-бързо към създаването на лош софтуер. Extreme Programming, или XP, осигурява техническия двигател, който кара Scrum да работи на практика.
Структурната празнина
Кен Шуабър и Джеф Съдърланд създават Scrum като лека рамка за сложни проблеми. По замисъл тя не налага конкретни инженерни практики. Този неутралитет прави Scrum приложим и извън софтуерната сфера, но залага капан на софтуерните инженери. Когато екипите се опитват да доставят софтуер, готов за релийз, на всеки две седмици без строги инженерни навици, качеството на кода се срива. Техническият дълг нараства, дефектите стигат до продукционна среда, а събитието Sprint Retrospective се превръща в списък с оправдания относно регресионното тестване.
XP подхожда към проблема от обратната посока. Кент Бек създава Extreme Programming около ежедневния занаят на писане на код. Докато Scrum въвежда емпиричен контрол на процеса, XP изгражда технически цикли за обратна връзка. Внасянето на XP практики в Scrum среда дава на Developers конкретните инструменти, необходими за спазване на Definition of Done.
Разработка, водена от тестове (TDD) и Definition of Done
Един стабилен Definition of Done изисква Increment да бъде изцяло верифициран. Ръчното тестване в края на даден Sprint не може да се мащабира. Когато тестването се случва след написването на кода, Developers прекарват последните дни от Sprint в трескаво отстраняване на дефекти, като често прехвърлят недовършена работа в следващия Sprint. Разработката, водена от тестове (TDD), обръща тази последователност. Първо пишете тест, който се проваля, след това пишете минималното количество код, за да мине тестът, и накрая изчиствате дизайна.
TDD носи две преки ползи в Scrum. Първо, действа като жива документация за елементите от Product Backlog. Второ, изгражда автоматизирана защитна мрежа. Когато Developers модифицират съществуващ код, за да постигнат нова Sprint Goal, те веднага разбират дали са счупили съществуваща функционалност. Без автоматизирани регресионни тестове скоростта на работа в отделните Sprints неизбежно спада с разрастването на кодовата база.
Pair Programming и колективна собственост върху кода
Scrum подчертава, че Developers носят колективна отговорност за създаването на стойностен Increment. В действителност много екипи разпределят задачите на отделни тесни специалисти. Един отговаря за базата данни, друг за потребителския интерфейс, а трети се грижи за скриптовете за внедряване. Когато специалистът по бази данни излезе в отпуск, напредъкът в рамките на текущия Sprint спира.
Практиките pair programming и колективна собственост върху кода премахват тези изолирани зони. Когато двама инженери работят заедно по един проблем, знанията се предават непрекъснато. Прегледът на кода се случва в момента на самото писане, което елиминира забавянето от асинхронните pull requests. Всеки разработчик може да променя всяка част от системата без страх, защото цялостните автоматизирани тестове го защитават. Тази споделена компетентност прави екипа адаптивен и устойчив по време на Sprint Planning.
Непрекъснатата интеграция като емпиричен механизъм
Емпиризмът изисква прозрачност. Ако кодът стои в изолирани клонове с дни, никой не знае реалното състояние на Increment. Непрекъснатата интеграция (Continuous Integration) изисква разработчиците да обединяват работата си в основния клон многократно на ден, като при всяко качване се изпълняват автоматизирани билдове и тестове.
Тази практика предотвратява конфликтите при сливане на код, които редовно провалят срещите за Sprint Review. Ако основният клон е винаги чист и готов за внедряване, Product Owner може да реши да пусне версия по всяко време, дори в средата на текущия Sprint. Цикълът на обратна връзка се съкращава от седмици до минути.
Практически стъпки за интеграция
Не ви е нужно специално разрешение, за да приложите XP практики в Scrum. Scrum Guide дава на Developers автономията сами да решават как да изграждат Increment. Можете да интегрирате XP практиките директно в работните споразумения на екипа:
- Включете автоматизирано тестово покритие и липса на известни дефекти в своя Definition of Done.
- Използвайте pair programming за сложни елементи от Product Backlog, за да премахнете забавянията при преглед на кода.
- Практикувайте непрекъснат рефакторинг по време на Sprint, вместо да създавате отделни задачи за рефакторинг.
- Въведете Continuous Integration, така че вашият Increment да бъде наистина използваем във всеки момент.
Scrum без техническо съвършенство е просто административно бреме. Когато внедрите XP практиките в рамката на Scrum, вие давате на Developers оперативната дисциплина, необходима за доставяне на реална стойност във всеки един Sprint.