Scrum се промени след 25 години насам. За добро ли е тази промяна? Когато чух новината направих веднага проучване на новото в Scrum Guide. Признавам си бях доста изненадан. Това което е променено доста се различаваше от моите очаквания.
Първото което ми направи впечатление е още по-кратката версия. Scrum Guide е вече 13 страници. Досега беше 19. Винаги съм споделял мнението си, че този наръчник е доста кратък за повечето хора. Начинаещите нямат големи шансове да научат детайлна и полезна за работата им материя.
Какви са промените в Scrum Guide от 2020?
Първата промяна е използването на по-опростен език.
Създателите премахнаха контекста на софтуерната разработка. Така искат да направят техния framework още по-обхватен.
Други новости са леки промени във формата на текста като например ре-организирано съдържание (e.g., "Measuring Progress toward Goals")
Вече има така наречения Product Goal, за който е отговорен вашият Product Owner.
Не се говори вече за роли. Например Product Owner role е вече само Product Owner.
Development Team е вече просто Developers.
Инкремента беше “potentially releasable”. Сега е “In order to provide value, the Increment must be usable”.
Терминът self-organisation вече е self-management.
Sprint Goal вече е официална част от Sprint Backlog. Досега това беше само добра практика, но и не част от наръчника.
Definition of Done вече присъства доста по-ясно в целия Инкремент.
Вече няма 3 въпроса по време на Daily Scrum събитието! За какво ще си говорите по време на тази среща остава изцяло ваш избор. Стига да направите инспекция на прогреса.
По време на Sprint Planning важна официална тема е „Защо спринта е ценен за заинтересованите страни“.
Sprint Review (познато като демонстрацията) е вече в контекста на ревю както от гледна точка на Sprint Goal, така и на Product Goal.
Servant Leadership термина вече не съществува. Актуалният термин е просто Leadership.
Scrum Master и Product Owner спокойно могат да участват в Daily Scrum събитието като Developers.
Scrum Master-а вече подпомага Product Owner-а в намирането на техники и за дефиниране на Product Goal.
Какво представлява целта на продукта?
Тъй като това е една изцяло нова тема и в същото време отново неясна, нека да я обсъдим по-детайлно.
Тази част от статията е базирана на публикацията на Dave West, който единствено за момента споделя някакви детайли. Извадих само най-важните теми и не съм цитирал абстрактни и неясни части от статията му.
Тъй като за мен тези обяснения може да не бъдат достатъчни, или могат да подтикнат някои Scrum екипи към непродуктивна посока, ще публикувам допълнения към всички от точките тук. В тези допълнения представям своята гледна точка и препоръки за екипите. Споделям и примери и за допълнителна яснота към всяка точка.
Извадките и допълнителните обяснения
Product Goal е темата, която засяга въпроса „защо“ ние вършим цялата тази работа.
Думата Цел е умишлена, тъй като описва две неща:
Това е нещо, към което да се стремим.
Измеримо е, когато сте го постигнали.
Новият Scrum Guide не дава детайли относно подробностите за целта на продукта, като по този начин позволява на екипите на Scrum да формират целта по правилния начин за техния контекст. Например, някои Scrum екипи могат да работят за тримесечна продуктова цел с ясни конкретики. Друг Scrum екип може да има продуктова цел, която е по-абстрактна.
Ето някои от характеристиките на целта на продукта:
Препоръчително е целта на продукта да бъде ясна и кратка.
Моето допълнение:
Целта трябва да е разбираема за всички. Това включва целият Scrum Team и заинтересованите страни с достъп към артефактите на екипа.
Пример: Вашият директор отваря вашите онлайн ресурси (например Jira или Confluence) и прочита някъде записана целта на продукта ви. За жалост не разбира нищо.
Целта на продукта може да бъде постигната без да са завършени всички Product Backlog Items.
Моето допълнение:
Product Owner ролята като отговарящ за Product Backlog и за продукта като цяло, може да реши да свали приоритета на незавършените Product Backlog Items. Тоест, да избере да не се правят изобщо в близко бъдеще. Този избор и промяна в приоритизацията трябва да бъде напълно съобразен с изискванията към продукта.
Пример: Вашият Product Owner може да премахне User Story, касаещо импортиране на данни от .pdf файл, тъй като смята, че импортиране на данни само от .xlsx файл в съвсем достатъчно за продукта ви. Уверява се, че никой инвеститор или директор няма да побеснее и сваля този Item по-надолу във вашия Product Backlog.
Целта на продукта може да се променя с времето. Оригинално становище: „understanding of the Product Goal will be refined“.
Допълнение:
Вероятно би била добра практика да рафинирате своята продуктова цел рядко само при установени силни нужди, или в края на вашия избран период за постигането на целта.
Пример: Както вече знаете Scrum обществото не приема добре радикална промяна на Sprint Backlog Items по време на спринта. Така постигаме спокойна работа без нерви и кризи. Когато е нужно, доработки и промени се правят в следващия спринт. Променящата се цел на продукта би имало също негативен ефект върху работата.
Целта на продукта е прозрачна в Product Backlog по същия начин, както Sprint Goal е прозрачна в Sprint Backlog. Всеки Scrum екип ще направи необходимото, за да се случи това в зависимост от тяхната среда.
Допълнение: Всъщност тук би трябвало всичко да е ясно. Целта на спринта не е тайна и всеки има достъп до нея. Всеки Scrum екип може да я публикува в своя софтуер за работа, или да си я принтира и да я закачи на стената в стаята си.
Product Goal сравнена с Value Proposition
Ето още едно лесно обяснение за Продуктови Мениджъри, което не е от статията на Dave West, но смятам, че би било доста полезно.
В Продукт Мениджмънт курса учим какво е Value Proposion и курсистите имат упражнение в което дефинират такова.
Продукт мениджърите трябва чудесно да знаят какво е Value Proposition.
На всички препоръчвам да прочетете своя безплатен бонус модул от Продукт Мениджмънт курса си: Модул 37 Value Proposition.
Също така, в този контекст, можем да добавим, и че Product Goal може да се приема кратка версия на Value Proposition, която касае конкретен период от време. Вместо обаче конкретен период от време, можете да мислете за своята цел на продукта за конкретна версия на продукта ви, ако така ще ви бъде по-лесно.
И тъй като Scrum Master ролята помага на своя Product Owner в намирането на техники за дефиниране на Product Goal, ако сте Scrum Master или бъдещ такъв, веднага разучете Value Proposition темата, тъй като може да ви бъде от помощ.
Заключения
Scrum Guide сега е още по-кратък, вместо да стане по-детайлен и да предлага повече познание. Вместо повече безплатно знание за всички, това редуциране вероятно ще задържи нуждата от допълнителни детайлни курсове. Опростяването на езика би трябвало да помогне на читателите. Донякъде тук има подобрение, но цялата абстракция и все още много неясни термини остават.
"Increment must be usable". Usable е отново абстрактно понятие.
Бих препоръчал на всички да прочетат понятието Usability в продуктовата разработка.
Също така обърнете внимание на връзката между „usable“ и не-наличие на сериозни дефекти. Тоест – работата ви няма бъгове.
Scrum Guide вече наистина прилича на брошура или на реклама. Само че няма по-дълга версия. Всеки по света интерпретира този наръчник както пожелае. Всичко си остава същото както досега.
Definition of Done вече е обяснено, което е доста добре.
След като Scrum Master и Product Owner са и разработчици, които присъстват на Daily Scrum събитието, трябва повече да внимавате за конфликти на интереси.
Също така без старите интересни въпроси, и след като всички са разработчици, събитието все повече прилича на хора, които са се събрали заедно и разговарят. Специалистите, които няма да знаят онези стари класически вечни въпроси няма да имат примерна насока по какъв начин ще направят своята инспекция и ще обсъдят риска и проблемите си.
Scrum проповядва събития с фиксирана продължителност. Това обаче не пречи на членовете на екипа да се събират колкото пъти пожелаят на ден и да обсъждат без значение от продължителността проблемите си. Daily Scrum събитието като че ли изглежда вече малко излишно.
Компетентния Product Owner като че ли трябва да познава все повече продуктови практики, за да успява да се справя и с продуктовата цел. В същото време обаче, вашият Scrum Master трябва подпомага колегата си Product Owner и в тази част. Все още остава идеята, че Scrum Master ролята трябва да има най-добри „проучвателни умения“ и компетенции за подпомагане на силно важния Product Owner, които би трябвало да отговаря за продукта и не би трябвало да е начинаещ аматьор.
Противоречия остават и с новите промени.
Може би ще срещаме вече ново поколение Scrum Мастъри, за които Leadership е различно от Servant leadership и вероятно няма да са чували стария термин.
„Development Team“ донякъде поне придаваше чувство за единност между разработчиците. Те вече не са екип, а само разработчици.
Напредналите екипи наистина имат повече свобода за действие и могат да използват свои дефиниции, интерпретации и практики. Всъщност напредналите екипи винаги са следвали своите собствени практики, стил на работа и правила (които всъщност често нарушават Scrum правилата).
Всички модули и теми в Scrum курса на "Проджект Мениджмънт Академия" ще запазят старото си съдържание, за да могат всички да учат старите правила. Новото ще бъде отбелязано в съответните секции за сравнение. Нека всеки професионалист има база за сравнение с преди и сега и всеки да избере екип да избира своята терминология, правила и идеи.
Сърдечни поздрави!
Антон Радев
Създател на Проджект Мениджмънт Академия
