История на Scrum
След публикуването на доклада на Уинстън Ройс "Управление на разработката на големи софтуерни системи" през 1970 г., мнозина се опитаха да намерят методология, която да елиминира недостатъците на модела на разработка на Waterfall. Алтернатива на „водопада“ беше методът Scrum, който ще бъде обсъден сега.
Scrum получи името си през 1986 г. от работата на Такеучи и Нонаки Новите правила за разработване на нови продукти. Този document твърди, че най-ефективният начин за постигане на целта е да се даде на разработчиците ясен план за действие.
През 1995 г. се появи друго ръководство, "Разработка на софтуер със Scrum", от Sutherland и Schweiber. Оттогава тази публикация е актуализирана няколко пъти. Сега се счита за основно ръководство за развитието на този метод. Текущата version на Ръководството за Scrum съдържа информация, актуализирана през 2020 г.
Основните разпоредби на Ръководството за Scrum предполагат, че шаблонът за управление на проекти трябва да се основава на факта, че разработчиците доставят готовия продукт в рамките на договорената времева рамка - спринтове. За успешното внедряване на Scrum се препоръчва да се използва структура, състояща се от няколко елемента: роли, събития, правила и артефакти.
Роли в Scrum
Има три роли в Scrum, всички от които образуват Scrum екип:
Клиентът на софтуерния продукт е най-важният човек в проекта, защото само той напълно разбира неговата стойност за бизнеса. Клиентът обяснява на разработчиците нуждите на потребителите на бъдещия продукт, но не носи отговорност за техническата част от процеса на разработка. Клиентът определя и приоритета при създаване на определени елементи or функции в продукта.
На разработчиците е поверено изпълнението на технически задачи, чиято кръстосана функционалност зависи от обхвата на приложението. Разработчиците са заети със създаването на изоставане в спринта, писане на code, приспособяване на проекта към целта на спринта и други задачи.
Scrum Master е фасorтаторът на Scrum екипа. Осигурява помощ на клиента и разработчиците. Просто казано, Scrum Master е зает с комуникацията между тези, които не участват в проекта, и хората, които пишат codeа. Понякога различни екипи от програмисти в една и съща голяма компания комуникират и координират на общи срещи на scrum masters на тези екипи.
Събития в Scrum
Има 5 вида схватки:
Спринтът е най-важната част от Scrum. Включва планиране на спринта, ежедневни изправяния (ежедневна схватка), преглед и ретроспекция на спринта.
Планиране на спринт. Всички членове на Scrum екипа участват в съставянето на план за бъдещия спринт. Именно тук се представя идеята за продукта и всеки член на екипа може да изрази своето мнение, Howво мисли по въпроса. След това на срещата се определят приоритетите и се обявяват срокове.
Daily Scrum е ежедневно кратко събитие за схватка, което продължава не повече от 15 minutesи. Обикновено се прави, за да се планира работата на енcodeерите за днес or утре. В Daily Scrum можете да обсъждате текущи проблеми. Всички разработчици, участващи в проекта, са длъжни да участват в такъв семинар. Присъствието на Scrum Master е разрешено, но не е задължително.
Преглед на спринта (Демо) - Показване на резултатите, създадени по време на спринта. Обикновено това събитие се провежда на последния етап. В нея участват всички желаещи.
Ретроспектива на спринта - обсъждане на резултатите от спринта. Членовете на екипа споделят мнението си How са се справor с възложените им задачи и How да подобрят резултатите от работата в бъдеще.
Освен това понякога се извършва прецизиране на неизпълнените задачи - прецизиране на неизпълнените задачи. В него се обсъждат неизпълнени задачи, подготовка за следващия спринт и приоритизиране на текущите задачи.
Артефакти
Scrum артефактите са работата, която се случва в края на проект or спринт. Има три артефакта - изоставането на продукта, изоставането на спринта и увеличението. Всеки от тях е необходим за навременното доставяне на софтуера на потребителите. Има и спомагателни артефакти (изгаряне на диаграми и други).
Компоненти, включени в артефактите за спринт:
Product backlog – интерфейс и бекенд функции.
Спринт изоставането е списък от задачи, които трябва да бъдат изпълнени по време на итерация. Те се договарят преди началото на спринта.
Увеличаване - Общият брой софтуерни изостанали елементи, създадени по време на спринта, и стойността на увеличенията, напequalsи преди него. Завършеното ново увеличение трябва да бъде показано преди края на спринта. Това означава, че имате работеща version, която отговаря на изискванията на scrum екипа.
Елемент за изоставане на продукта - трябва да бъде завършен по време на итерацията на спринта. По правило елементът е разделен на няколко малки задачи.
Целта на спринта са задачите, които трябва да бъдат изпълнени (създаване на неизпълнен елемент or друга задача).
Изгарянето на спринта е работата, останала преди края на спринта. Графиката на изгаряне е or възходяща, or низходяща. Всичко зависи от трудностите, с които се сблъскват членовете на екипа по време на работа. Това не е индикатор за напредък, а само начин за решаване на проблеми и стимул.
Product Release/Product Burn-Down Chart е диаграма, начертана от Scrum Master преди края на следващия спринт. Хоризонталната ос е спринтовете, вертикалната ос е количеството работа, която остава.
Правила на рамката на Scrum
Ролите, събитията и артефактите са в основата на Scrum, но има и други правила освен това. Всички те повишават ефективността на работния процес. Ето списък на тези правила:
- Scrum екипът включва софтуерния клиент, Scrum Master и разработчици.
- Всички спринтове трябва да са с еднаква дължина.
- След завършване на един спринт веднага започва работа по нов.
- Спринтът винаги започва с план.
- Членовете на екипа имат сутрешна схватка в началото на работния си ден.
- Всеки спринт се преглежда по време на всеки спринт. Това подобрява комуникацията между екипа и заинтересованите страни.
- Не се препоръчва да променяте изоставането в спринта по време на спринта.
Ограничения в Scrum
Наред с очевидните предимства, Scrum има и недостатъци:
- Scrum често води до намаляване на обема на извършената работа поради липсата на общ краен срок.
- При слабо участие or нежелание за сътрудничество между участниците в проекта има значителни шансове да провалите резултата.
- Scrum структурата е трудна за използване в големи екипи, но все пак е възможна. Има рамки за мащабиране за това: LeSS, SAFe, Nexus и други.
- Напускането на един or повече членове от екипа по средата на проекта не се отразява много добре на проекта.