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