Планиране на спринт
Планирането на спринта е началният етап в Scrum спринта. Той определя обхвата и начините на работа по време на спринта. Целият Scrum екип участва в планирането.
Спринтът е ясно определен период от време, през който определена част от работата трябва да бъде завършена. Един спринт се нуждае от планиране преди да започне. На първо място, трябва да определите продължителността и целта на спринта.
На семинара за планиране се съгласуват списъкът със задачи и целта на спринта. Важно е да заредите екипа с правилната мотивация за работа, така че всеки член да е фокусиран върху успеха.
Ако спринтът е зле планиран, това може да доведе отбора до провал. Разработчиците няма да могат да се справят с очакванията, поставени върху тях, тъй като задачите се оказаха нереалистични.
Въпроси, които трябва да имате предвид, когато планирате спринт:
- Клиентът or собственикът на софтуер обявява целта на спринта, като по пътя обяснява How да я постигне. Екипът на Scrum открива Howви задачи могат да бъдат изпълнени в бъдещ спринт, за да се постигне тази цел.
- Разработчиците разпространяват работен план помежду си, който се съгласува с клиента на софтуера.
- Клиентът (собственикът) на продукта винаги участва в съставянето на плана за спринт. Той си поставя цел, а екипът по програмиране трябва да разбере дали тя може да бъде постигната със спринт.
- Планът трябва да използва продуктово изоставане, информация от което може да бъде добавена към плана.
- Членовете на екипа трябва да завършат срещата за планиране с ясно разбиране Howво им е необходимо, за да постигнат резултата. Можете да покажете реда на бъдещите действия в архива на спринта.
Планирането не трябва да надвишава два часа седмично. Scrum Master трябва да обясни на всички, че има времеви ограничения. Ако всички работни проблеми бъдат разрешени бързо, тогава срещата може да приключи по-рано от обикновено. Няма минимална продължителност на такава среща.
Оценка на задачите
Оценявайки сложността на работата, не е необходимо да прекалявате. Процесът на планиране се нуждае не от точна, а поне от приблизителна оценка на сложността на разработката. Отборът трябва не само да разбере целта на спринта, но и да сравни целта с възможностите на своя отбор.
За да оцените сложността, можете да използвате обичайните размери на дрехите за всички (L, XL, XXL). Разбира се, това не дава гаранция за точност, но все пак.
За да бъде оценката на сложността по-точна е необходимо взаимно разбиране. Членовете на екипа трябва открито да споделят мненията си и да не се страхуват да задават въпроси на собственика на продукта.
Критиката към екипа след приключване на работата може да доведе до факта, че при планирането на следващия спринт прогнозите ще бъдат по-малко оптимистични. Това ще помогне на екипа да избегне повторение на грешката и ще го предпази от негативна оценка в бъдеще.
Оценка на трудност в точки, точки и часове
Обикновено екипите за разработка оценяват сложността на работата си с течение на времето. Но някои Agile екипи избират да оценяват трудността в точки or точки. Това е по-добра индикация за общите разходи, необходими за внедряване на неизпълнен елемент or друга възложена задача.
Точките се присъждат според сложността и обема на работата. Освен това се вземат предвид възможните рискове. Оценяването с помощта на този метод помага за ефективното разделяне на работата на малки стъпки.
Чрез редовното използване на метода за оценяване (точки) при планиране, екипите имат по-добро и по-точно разбиране за това колко време ще им е необходимо, за да завършат работата. Освен това има и други предимства.
- Времевата оценка не взема предвид работа, която не е пряко свързана с проекта, въпреки че със сигурност ще се появи. Обсъждане на работни въпроси чрез месинджър, провеждане на срещи - всичко това също отнема време на членовете на екипа.
- Емоциите могат да повлияят на избора на дати. Точкуването при оценяване на работата елиминира този фактор.
- Оценката на сложността на работата и съответно скоростта на изпълнение на задачите може да бъде различна за всеки от екипите. Работата с напequalsи точки не може да се счита за показател за скорост. Тоест няма психологически натиск върху отбора.
- Чрез правилното разпределение на разходите и сложността на труда можете бързо и без конфликт да разделите точките за извършената работа между участниците.
- Броят точки, получени за изпълнение на дадена задача, зависи от нейната сложност, а не от изразходваното време. Следователно програмистите ще мислят за подобряване на ефективността си, а не за това колко време ще отнеме.
Недостатъкът на оценката на сложността е, че често се злоупотребява. Например, този метод не може да се използва за оценка на служителите.
Екипите трябва да използват система за точкуване, за да разберат по-добре обема на възложената им работа и да подредят правилно приоритетите.
Ежедневна Scrum среща
Работните срещи са важни: на тях членовете на екипа споделят мненията си, общуват и се договарят за по-нататъшни действия. Необходими са и ежедневни скръм срещи за повишаване на екипния дух и обявяване на актуални новини.
Stand-up е кратка среща на ключовите участници в проекта: собственикът на софтуера, програмистите и scrum master. Структурата на stand-up се състои от три въпроса.
- Какво успяхме да направим вчера?
- Върху Howво работим днес?
- Какво ни пречи да постигнем резултати?
Задаването на тези въпроси стимулира развитието и помага за идентифициране на проблеми в екипа. Когато всеки участник комуникира How той/тя помага за постигането на обща цел, това подобрява взаимното разбирателство в екипа.
Важно е да запомните, че няма единен шаблон за това How да се провеждат изправяния. Всеки отбор провежда срещи по собствен модел, базиран на характеристиките на отбора.
А сега нека обсъдим Howво е необходимо за перфектното изправяне и да се запознаем с примери за ефективни изправяния.
Първо трябва да изберете време, което е удобно за всички. Обикновено стендъпите за екипи от един и същи офис се провеждат в началото на работния ден - между 9 и 10 сутринта. Това ви дава време да планирате по-добре графика си за деня. Ако членовете на екипа работят в различни региони, тогава се избира време, което е удобно за всички. Например, ако някои членове на екипа живеят в Калифорния и Сидни, тогава изправянето започва в 15:30 калифорнийско време. Разбира се, изправянето след вечеря не е удобно за всеки, но дава възможност да поддържате връзка с колеги от другата страна на океана.
Следете производителността в изпequalsо положение. Не задържайте срещата твърде дълго - концентрацията на вниманието трябва да остане най-добра. Ако е възможно, дръжте изпequalsи позиции не повече от 15 minutesи.
Използвайте топката. Може да се хвърля един към друг на свой ред. Така всички ще участват в дискусията. Тази игра помага да се задържи вниманието в групата. Използвайте екипна ретроспекция. Стендъпите се използват в много Agile методологии, това не ни пречи да обсъждаме ефективността на стендъпите на ретроспективи. Някой се среща всеки ден, други екипи - няколко пъти седмично. Ако за отбора е трудно да се възползва от изправянето, намерете причините за това и променете нещо.
Преглед на спринт
Пролетният преглед се извършва в последния етап на спринта. Необходимо е да се провери нарастването на продукта и да се коригира изоставането. Целият scrum екип и всички заинтересовани страни участват в прегледа на резултатите от спринта. Срещата се провежда в спокоен формат за подобряване на взаимодействието между участниците в проекта.
Прегледът на резултатите от спринта включва следните елементи:
- Собственикът на софтуера показва Howво от изоставането е завършено и Howво не.
- Програмистите обсъждат Howво е било добре, къде са се появor трудностите и How са бor отстранени.
- Екипът за разработка показва резултатите от работата си по време на спринта и Howво продуктово увеличение са получor.
- Собственикът на продукта споделя мислите си относно текущото изоставане. Дава и прогноза за следващата цел и срока за нейното изпълнение.
- Всеки обсъжда Howво е най-добре да направи след това въз основа на оценката на пазара и интересите на потребителите.
- Има обмен на мнения относно времето, бюджета и перспективите за добавяне към изоставането.
Резултатът е актуализиран изоставане с нови цели за следващите спринтове. Закъснението може да бъде променено, ако ситуацията го изисква.
Ретроспектива на спринт
Ретроспективата на Sprint е семинар, който обсъжда How да подобрите работния си процес. Той също така създава план за подобрение за следващия спринт. Срещата обикновено се провежда след прегледа на спринта и отнема не повече от три часа. Водещ на срещата е Scrum Master.
Основните цели на Sprint Retrospective включват:
- Спринт анализ (работа на участниците, резултати и проблеми).
- Обсъдете възможни решения за подобряване на работния процес в следващите спринтове.
- Създаване на план за внедряване на подобрения от членовете на екипа по време на изпълнението на проекта.
Scrum Master кани членовете на екипа да направят предложения How да се подобри ефективността на разработката. Екипът обсъжда предложенията и предлага определени начини и техники за тяхното реализиране.
В края на ретроспективата на спринта екипът трябва да подчертае няколко предложения за подобрение, които да бъдат приложени в следващия спринт. Предложенията могат да бъдат приложени по всяко време, но Sprint Retrospective предоставя възможност за по-задълбочен поглед върху възможната им адаптация от гледна точка на екипа.
Това е мястото, където приключваме нашето обсъждане на методологията на Scrum. Можете да научите повече за това в тематичната documentация or на първото си работно място.