Scrum | Enicomp.eu

Scrum – техника за управление на проекти. Един от подходите на Agile методологията, когато всички участници, включително клиентите, са включени в процеса на решаване на проблем. Клиентите активно работят с екипа на проекта и не само поставят задачи и контролират изпълнението, но и търсят оптималното решение. Процесът е разделен на кратки цикли – спринтове, след приключване на всеки един от тях екипът преглежда стратегията и приоритетите на работа.

Докато scrum, за който говоря, се използва най-често от екипите за разработка на софтуер, неговите принципи и уроци могат да бъдат приложени към всякакъв вид работа в екип. Това е една от причините scrum да е толкова популярен. Често смятан за гъвкава рамка за управление на проекти, scrum описва набор от срещи, инструменти и роли, които работят съвместно, за да помогнат на екипите да структурират и управляват работата си.

Хората често мислят, че scrum и agile са едно и също нещо, защото scrum е съсредоточен върху непрекъснатото подобрение, което е основен принцип на agile. Въпреки това, scrum е рамка за извършване на работа, където agile е начин на мислене. Не можете наистина да „вървите пъргави“, тъй като е необходима всеотдайност от целия екип, за да промените начина, по който мислят за предоставяне на стойност на вашите клиенти. Но можете да използвате рамка като scrum, за да ви помогне да започнете да мислите по този начин и да практикувате изграждането на гъвкави принципи в ежедневната си комуникация и работа.

Рамката на scrum е евристична; той се основава на непрекъснато учене и приспособяване към променливи фактори. Той признава, че екипът не знае всичко в началото на проекта и ще се развива чрез опит. Scrum е структуриран, за да помогне на екипите да се адаптират естествено към променящите се условия и изискванията на потребителите, с пренареждане на приоритетите, вградено в процеса и кратки цикли на освобождаване, така че екипът ви да може постоянно да се учи и подобрява.

Въпреки че scrum е структуриран, той не е напълно твърд. Неговото изпълнение може да бъде съобразено с нуждите на всяка организация. Има много теории за това как точно трябва да работят scrum екипите, за да бъдат успешни. Въпреки това, след повече от десетилетие на подпомагане на гъвкавите екипи да свършат работа в Atlassian, ние научихме, че ясната комуникация, прозрачността и отдадеността на непрекъснатото подобрение винаги трябва да останат в центъра на каквато и рамка да изберете. А останалото зависи от вас.

Скрам артефакти

Нека започнем с идентифицирането на трите артефакта в scrum. Артефактите са нещо, което правим, като инструмент за решаване на проблем. В scrum тези три артефакта са изоставане на продукта, изоставане на спринт и увеличение с вашата дефиниция за „готово“. Те са трите константи в един scrum екип, който продължаваме да преразглеждаме и да инвестираме в извънредното време.

Product Backlog е основният списък с работа, която трябва да бъде свършена, поддържан от собственика на продукта или продуктовия мениджър. Това е динамичен списък с функции, изисквания, подобрения и корекции, който действа като вход за изоставането на спринта. По същество това е списъкът със задачи на екипа. Продуктовото изоставане непрекъснато се преразглежда, приоритизира и поддържа от Собственика на продукта, защото, докато научаваме повече или с промяната на пазара, артикулите може вече да не са подходящи или проблемите могат да бъдат решени по други начини.
Sprint Backlog е списъкът с елементи, потребителски истории или корекции на грешки, избрани от екипа за разработка за изпълнение в текущия цикъл на спринт. Преди всеки спринт, в срещата за планиране на спринт (която ще обсъдим по-нататък в статията) екипът избира по кои елементи ще работи за спринта от остатъка на продукта. Изоставането на спринт може да бъде гъвкаво и може да се развива по време на спринт. Основната цел за спринт обаче – това, което отборът иска да постигне от настоящия спринт – не може да бъде компрометирана.
Инкрементът (или Sprint Goal) е използваемият краен продукт от спринт. В Atlassian обикновено демонстрираме „увеличението“ по време на демонстрацията в края на спринта, където екипът показва какво е завършено в спринта. Може да не чуете думата „инкремент“ в света, тъй като често се нарича дефиницията на екипа за „Готово“, крайъгълен камък, цел за спринт или дори пълна версия или изпратена епопея. Просто зависи от това как вашите отбори определят „Готово“ и как определяте целите си за спринт. Например, някои отбори избират да пуснат нещо на своите клиенти в края на всеки спринт. Така че тяхната дефиниция за „готово“ ще бъде „изпратена“. Това обаче може да не е реалистично за други типове отбори. Да речем, че работите върху сървърно-базиран продукт, който може да се доставя на клиентите ви само на всяко тримесечие. Все още може да изберете да работите в 2-седмични спринтове, но вашата дефиниция за „готово“ може да е завършване на част от по-голяма версия, която планирате да изпратите заедно. Но разбира се, колкото по-дълго е необходимо за пускането на софтуера, толкова по-голям е рискът софтуерът да пропусне целта.

Както можете да разберете, има много вариации, дори в рамките на артефакти, които вашият екип може да избере да дефинира. Ето защо е важно да останете отворени към развитието на начина, по който поддържате дори артефактите си. Може би вашата дефиниция за „готово“ осигурява отмяна на стреса за вашия екип и трябва да се върнете и да изберете нова дефиниция.

ПРОФЕСИОНАЛЕН СЪВЕТТрябва да сте толкова гъвкави с рамката си, колкото и с продукта си. Отделете необходимото време, за да проверите как вървят нещата, направете корекции, ако е необходимо, и не насилвайте нещо само в името на последователността.

Скрам церемонии или събития

Някои от по-добре познатите компоненти на scrum рамката са наборът от последователни събития, церемонии или срещи, които scrum екипите извършват редовно. Церемониите са мястото, където виждаме най-много вариации за отборите. Например, някои отбори намират извършването на всички тези церемонии за тромаво и повтарящо се, докато други ги използват като необходимо чекиране. Нашият съвет е да започнете да използвате всички церемонии за два спринта и да видите как се чувствате. След това можете да извършите бързо ретро и да видите къде може да се наложи да коригирате.

По-долу е даден списък на всички ключови церемонии, в които екипът на скрам може да участва:

Организиране на изоставането : Понякога известно като почистване на изоставането, това събитие е отговорност на собственика на продукта. Основните задачи на собственика на продукта са да насочва продукта към неговата продуктова визия и да има постоянен импулс на пазара и клиента. Поради това той/тя поддържа този списък, използвайки обратна връзка от потребителите и екипа за разработка, за да помогне за приоритизирането и поддържането на списъка чист и готов за работа по всяко време. Можете да прочетете повече за поддържането на здравословно изоставане тук .
Планиране на спринт : Работата, която трябва да бъде извършена (обхват) по време на текущия спринт , се планира по време на тази среща от целия екип за разработка. Тази среща се ръководи от Scrum Master и е мястото, където екипът взема решение за целта на спринта. След това към спринта от изоставането на продукта се добавят истории за специфично използване. Тези истории винаги са в съответствие с целта и също така са съгласни от екипа на scrum, за да бъдат осъществими за изпълнение по време на спринта.В края на срещата за планиране всеки член на скрам трябва да е наясно какво може да бъде доставено в спринта и как може да бъде предоставено увеличението.
Спринт : Спринтът е действителният период от време, през който екипът на скрам работи заедно, за да завърши стъпка. Две седмици е доста типична продължителност за спринт, въпреки че някои отбори смятат, че една седмица е по-лесна за обхват или месец, за да бъде по-лесно да осигурят ценно увеличение. Дейв Уест от Scrum.org съветва, че колкото по-сложна е работата и колкото повече неизвестни, толкова по-кратък трябва да бъде спринтът. Но това наистина зависи от вашия екип и не трябва да се страхувате да го промените, ако не работи! През този период обхватът може да бъде предоговорен между собственика на продукта и екипа за разработка, ако е необходимо. Това формира същността на емпиричната природа на scrum.Всички събития – от планиране до ретроспектива – се случват по време на спринта. След като се установи определен интервал от време за спринт, той трябва да остане постоянен през целия период на разработка. Това помага на екипа да се учи от минал опит и да приложи това прозрение към бъдещи спринтове.
Ежедневна сблъсък или изправяне : Това е ежедневна супер-кратка среща, която се провежда по едно и също време (обикновено сутрин) и място, за да бъде опростено. Много отбори се опитват да завършат срещата за 15 минути, но това е само насока. Тази среща се нарича още „ежедневна изправност“, като се подчертава, че тя трябва да бъде бърза. Целта на ежедневната схватка е всички в екипа да бъдат на една и съща страница, в съответствие с целта на спринта и да изготвят план за следващите 24 часа.Изправянето е моментът да изразите всички притеснения, които имате относно постигането на целта за спринт или каквито и да било блокери.
Често срещан начин за провеждане на стендъп е всеки член на екипа да отговори на три въпроса в контекста на постигането на целта на спринта:

• Какво направих вчера?
• Какво смятам да правя днес?
• Има ли пречки?

Видяхме обаче срещата бързо да се превръща в хора, които четат от календарите си от вчера и за следващия ден. Теорията зад stand up е, че той продължава да разсейва бърборенето на ежедневна среща, така че екипът може да се съсредоточи върху работата през останалата част от деня. Така че, ако се превърне в ежедневен календар, не се страхувайте да го промените и да станете креативни.
Преглед на спринт : В края на спринта екипът се събира за неформална сесия, за да види демонстрация или да провери увеличението. Екипът за разработка показва на заинтересованите страни и съотборниците елементите, които вече са „Готови“, за обратна връзка. Собственикът на продукта може да реши дали да освободи увеличението или не, въпреки че в повечето случаи увеличението се освобождава.Тази среща за преглед е също така, когато собственикът на продукта преработва изоставането на продукта въз основа на текущия спринт, което може да се включи в следващата сесия за планиране на спринт. За едномесечен спринт помислете за намаляване на времето за преглед на спринт до максимум четири часа.
Спринт ретроспектива : Ретроспективата е мястото, където екипът се събира, за да документира и обсъди какво е работило и какво не е работило в спринт, проект, хора или взаимоотношения, инструменти или дори за определени церемонии. Идеята е да се създаде място, където екипът може да се съсредоточи върху това, което е минало добре и какво трябва да се подобри за следващия път, и по-малко върху това, което се обърка.

Започнете безплатно с шаблона на Jira scrum

Използвайте шаблон

Три основни роли за успеха на скрам

Скрам екипът се нуждае от три конкретни роли: собственик на продукт, скрам майстор и екип за разработка. И тъй като scrum екипите са многофункционални, екипът за разработка включва тестери, дизайнери, UX специалисти и оперативни инженери в допълнение към разработчиците.

Собственикът на scrum продукт

Собствениците на продукти са шампионите за своя продукт. Те са фокусирани върху разбирането на изискванията на бизнеса, клиентите и пазара, след което да приоритизират работата, която трябва да бъде извършена от инженерния екип. Ефективни собственици на продукти:

Създайте и управлявайте изоставането на продукта.
Тясно си партнирай с бизнеса и екипа, за да гарантира, че всички разбират работните елементи в изоставането на продукта.
Дайте на екипа ясни насоки кои функции да предоставят следващи.
Решете кога да изпратите продукта с предразположение към по-честа доставка.

Собственикът на продукта не винаги е продуктов мениджър. Собствениците на продукти се фокусират върху това, че екипът за разработка предоставя най-голяма стойност на бизнеса. Също така е важно собственикът на продукта да е физическо лице. Никой екип за разработка не иска смесени насоки от множество собственици на продукти.

Скрам майсторът

Скрам майсторите са шампионите за скръм в своите отбори. Те обучават екипи, собственици на продукти и бизнеса в процеса на скрам и търсят начини да прецизират практиката си.

Ефективният скрам майстор разбира дълбоко работата, която се извършва от екипа, и може да помогне на екипа да оптимизира своята прозрачност и поток на доставка. Като главен фасилитатор, той/тя планира необходимите ресурси (както човешки, така и логистични) за планиране на спринт, изправяне, преглед на спринт и ретроспектива на спринта.

Екипът за разработка на scrum

Scrum екипите получават s*%& готово. Те са шампионите за практиките за устойчиво развитие. Най-ефективните scrum екипи са сплотени, съвместно разположени и обикновено от пет до седем членове. Един от начините да определите размера на екипа е да използвате известното „правило за две пици“, измислено от Джеф Безос, главен изпълнителен директор на Amazon (екипът трябва да е достатъчно малък, за да споделя две пици).

Членовете на екипа имат различни набори от умения и се обучават взаимно, така че никой да не се превърне в пречка при изпълнението на работата. Силните scrum екипи се самоорганизират и подхождат към проектите си с ясно отношение „ние“. Всички членове на екипа си помагат един на друг, за да осигурят успешно завършване на спринт.

Скрам екипът управлява плана за всеки спринт. Те прогнозират колко работа смятат, че могат да извършат през итерацията, като използват историческата си скорост като ориентир. Поддържането на фиксирана дължина на итерацията дава на екипа за разработка важна обратна връзка относно тяхната оценка и процеса на доставка, което от своя страна прави прогнозите им все по-точни с течение на времето.

Scrum, kanban и agile

Scrum е толкова популярна гъвкава рамка, че scrum и agile често се разбират погрешно като едно и също нещо. Но има и други рамки, като kanban , който е популярна алтернатива. Някои компании дори избират да следват хибриден модел на scrum и kanban, който придоби името “Scrumban” или “Kanplan”, което е Kanban с изоставане .

И scrum, и kanban използват визуални методи като scrum board или kanban board, за да проследяват напредъка на работата. И двете наблягат на ефективността и разделянето на сложни задачи на по-малки парчета управляема работа, но подходите им към тази цел са различни.

Scrum се фокусира върху по-малки итерации с фиксирана дължина. След като периодът от време за спринт бъде финализиран, се определят историите или записите за неизпълнение на продукти, които могат да бъдат приложени по време на този спринт цикъл. В kanban обаче броят на задачите или незавършената работа (лимит на WIP), които трябва да бъдат изпълнени в текущия цикъл, е фиксиран отначало. След това времето, необходимо за прилагане на тези функции, се изчислява обратно.

Канбанът не е толкова структуриран като scrum. Освен ограничението на WIP, то е доста отворено за тълкуване. Scrum обаче има няколко категорични концепции, наложени като част от прилагането му, като преглед на спринт, ретроспективен, ежедневен scrum и т.н. Той също така настоява за кръстосана функционалност, която е способността на scrum екипа да не зависи от външни членове за постигане техните цели. Събиране на амеждуфункционалният екип не е ясен. В този смисъл kanban е по-лесен за адаптиране, докато scrum може да се разглежда като фундаментална промяна в мисловния процес и функционирането на екип за разработка.

Но защо scrum?

Самата рамка на scrum е проста. Правилата, артефактите, събитията и ролите са лесни за разбиране. Неговият полу-предписващ подход всъщност помага за премахване на неяснотите в процеса на разработка, като същевременно дава достатъчно пространство на компаниите да въведат своя индивидуален вкус в него.

Организирането на сложни задачи в управляеми потребителски истории го прави идеален за трудни проекти. Също така, ясното разграничаване на ролите и планираните събития гарантират, че има прозрачност и колективна собственост през целия цикъл на разработка. Бързите издания поддържат мотивацията на екипа и щастливи потребителите, тъй като могат да видят напредъка за кратък период от време.

Въпреки това, scrum може да отнеме време, за да разбере напълно, особено ако екипът за разработка е аклиматизиран към типичен модел на водопад. Концепциите за по-малки итерации, ежедневни срещи на scrum, прегледи на спринт и идентифициране на scrum master биха могли да бъдат предизвикателна културна промяна за нов екип.