Емпиризмът на практика: Как Scrum екипите инспектират и адаптират
Научете как работи емпиризмът в Scrum чрез конкретна инспекция и адаптация. Разберете как прозрачните артефакти водят до по-добри продуктови решения.
Повечето хора не разбират правилно емпиризма. Те го възприемат като абстрактна философия или академична тема за дискусии между коучове. В действителност емпиризмът е прост. Взимате решения въз основа на това, което наблюдавате, а не на това, което се надявате да се случи. Scrum разчита на три стълба, за да постигне това: прозрачност, инспекция и адаптация. Без тези три елемента емпиричният контрол на процеса се срива до обикновено пожелателно мислене.
Прозрачността не е докладване на статус
Не можете да инспектирате това, което криете. Когато екип маркира елемент от Product Backlog като завършен, докато три автоматизирани теста все още се провалят, прозрачността изчезва. Екипът не действа нечестно умишлено. Обикновено хората се опитват да се защитят или да спазят изкуствен краен срок. В момента, в който се престорите, че недовършената работа е готова, всяко решение за продукта се превръща във фикция.
Прозрачността изисква споделени стандарти. Definition of Done съществува точно поради тази причина. Ако всички са съгласни, че завършено означава тествано, прегледано и внедрено в тестова среда, тогава завършената работа означава нещо реално. Ако завършено означава каквото даден разработчик си мисли тази седмица, имате нулева прозрачност, а инспекцията ви ще бъде напълно безсмислена.
Инспекцията изисква осезаеми доказателства
Инспекцията без конкретни доказателства е просто размяна на мнения. Ако прекарате своето Sprint Review в обсъждане на презентации за бъдеща архитектура, вие инспектирате планове, а не реален напредък. Scrum Guide настоява за инспектиране на самия Increment, което означава работещ софтуер или реални резултати, които потребителите могат да изпробват. За да инспектирате ефективно, трябва да стъпите на фактите:
- Дали потребителите могат да преминат през основния работен процес без грешки.
- Колко време отнема придвижването на даден елемент от започнат до завършен според текущия процес.
- Реалният брой дефекти, открити след внедряване, спрямо предишни Sprint итерации.
- Разликата между договорения Sprint Goal и реално доставения Increment.
Адаптацята трябва да се случва незабавно
Инспекцията е безполезна, ако не се адаптирате. Много екипи провеждат Retrospective срещи, на които откриват съществени спънки, записват ги на картони и след това не променят нищо по време на следващото Sprint Planning събитие. Това не е емпиризъм, това е просто оплакване. Ако инспекцията покаже, че нещо излиза извън приемливите граници, трябва незабавно да коригирате процеса или продукта.
Scrum Guide изрично посочва, че адаптацията трябва да се извърши възможно най-бързо, за да се минимизира по-нататъшното отклонение. Ако процесът за автоматизирани тестове се счупи във вторник, не чакате следващата седмица за Retrospective, за да говорите за надеждността на софтуерните билдове. Спирате работата и го поправяте, или променяте начина, по който екипът интегрира код още същия следобед. Адаптацията е оперативен навик, а не церемония в края на даден Sprint.
Затваряне на цикъла за обратна връзка
Когато емпиричният контрол на процеса се провали, причината почти винаги е прекалено дългият цикъл за обратна връзка. Традиционните проекти планират шест месеца, разработват четири и тестват два. До момента, в който инспектират изграденото, пазарът вече се е променил, клиентът е променил мнението си или техническите предположения са се оказали напълно погрешни.
Кратките Sprint итерации принуждават тези цикли да се затворят навреме. Ако вашият Sprint е две седмици, максималното време, през което можете да се отклонявате от реалността преди точка на инспекция, е две седмици. Ако искате по-голям контрол, не пишете по-дълги документи с изисквания. Инспектирайте и адаптирайте по-често с по-малък Increment.