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