Sprint Retrospectives, които наистина променят поведението
Научете как да провеждате Sprint Retrospectives, които водят до реална промяна в навиците. Фокусирайте се върху единични, конкретни подобрения, поставени директно във вашия Sprint Backlog.
Повечето срещи от типа Sprint Retrospective са просто вежливи сесии за споделяне на разочарования, които не променят нищо. Хората се оплакват от нестабилни автоматизирани тестове или неясни критерии за приемане, пишат бележки на дигиталната дъска и се връщат по бюрата си. Две седмици по-късно абсолютно същото напрежение се появява отново. Scrum ръководството от 2020 г. определя събитието Sprint Retrospective като възможност за планиране на начини за повишаване на качеството и ефективността. Ако в понеделник сутрин екипът ви действа по абсолютно същия начин, събитието се е провалило.
Илюзията на списъците с действия
Екипите често приключват Retrospective с пет общи стремежа. Обещават да комуникират по-добре, да пишат по-чист код и да обновяват работните задачи своевременно. Това са само пожелания, а не реални действия. Човешките навици не се поддават на общи добри намерения. Когато към дадена задача за подобрение липсват конкретен отговорник и видим праг на изпълнение, тя бързо се изпарява под натиска на новата работа.
Scrum ръководството предлага практично решение: подобренията с най-голямо въздействие се адресират възможно най-скоро и дори могат да бъдат добавени в Sprint Backlog за следващия Sprint. Това разположение има съществено значение. Ако дадено подобрение не стои на дъската редом с продуктовата работа, то просто престава да съществува в моментите, когато разработчиците правят ежедневни компромиси. Поставянето му в Sprint Backlog му осигурява същата видимост, каквато имат и функционалностите за потребителите.
Изберете точно един малък експеримент
Амбициозните планове за подобрение почти винаги се провалят. Когато се опитате да поправите автоматизираното тестване, прегледите на кода и прецизирането на Backlog в рамките само на един Sprint, надхвърляте капацитета на екипа за адаптация. Истинската промяна в поведението изисква малки, дисциплинирани стъпки.
Възприемайте резултатите от Retrospective като проверими експерименти. Вместо да се опитвате да прекроите целия си работен процес, изберете една конкретна, ограничена промяна за предстоящия Sprint:
- Спрете започването на нови задачи, когато повече от две заявки за сливане (pull requests) чакат за преглед.
- Изисквайте Product Owner и един разработчик да отделят десет минути за изясняване на гранични случаи, преди да започне работата по дадена задача.
- Стартирайте целия пакет с тестове локално, преди да изпратите какъвто и да е клон към хранилището.
- Посветете първите три минути от Daily Scrum на инспекция на блокираната работа, преди всичко останало.
Дефинирайте наблюдаемо завършване
Ако не можете да проверите дали екипът е приложил дадена промяна, няма как да оцените нейното въздействие. Неясни цели от рода на по-бърз преглед на заявките за сливане водят до субективни спорове, вместо до яснота. Практически насоченият ангажимент от Retrospective определя точно какво означава завършеност.
Например, дефинирайте експеримента ясно: всяка заявка за сливане получава обратна връзка в рамките на четири работни часа, или авторът сигнализира в екипния чат. В края на съответния Sprint не питате хората как са се почувствали относно прегледите на код. Инспектирате дали тези прегледи наистина са се случвали в рамките на четиричасовия интервал. Емпиризмът стъпва на наблюдение и доказателства, а не на спомени.
Затваряне на цикъла за обратна връзка
Най-бързият начин да убиете ентусиазма за Retrospective е да игнорирате резултатите от предходните срещи. Преди да отворите нов разговор за поредните трудности, отворете вашия Sprint Backlog и прегледайте подобрението, избрано на предишната ретроспектива. Изпълни ли го екипът? Направи ли доставката по-плавна или качеството по-високо?
Ако експериментът не е решил проблема, откажете се от него и опитайте друг подход. Ако е проработил, превърнете го в стандартна практика и преминете към следващата проблемна точка. Retrospective събитията стават ценни единствено когато екипът види прекия резултат от собствените си решения, променящи ежедневното му темпо на работа.