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