Меню

Терминология Agile And Scrum: Речник за Agile / Scrum концепции

agile scrum terminology

Опитайте Нашия Инструмент За Премахване На Проблемите

Това е изчерпателно ръководство за всички важни терминологии Agile / Scrum и е всичко в едно речник на Agile и Scrum концепции:

Както всички знаем, Agile не се нуждае от представяне. Това е рамка за разработка на софтуер, използвана по целия свят.

Тази статия е изчерпателно ръководство за всички пъргави / скрам концепции, които трябва да имате на една ръка разстояние.

Agile Scrum

Какво ще научите:

Agile Manifesto

Методологията Agile се основава на Agile Manifesto. За повече информация относно манифеста проверете Манифест за гъвкава разработка на софтуер .

Ключовият извод от пъргавия манифест може да бъде съкратен до :

  • Комуникацията от човек на човек е ефективна за обвързването на процеса.
  • Работещият продукт е по-добър от конвенционалната поетапна документация.
  • Участието на клиент / собственик на бизнес е от решаващо значение, както и непрекъснатите цикли на обратна връзка.
  • Промените са неизбежни. Следователно екипите трябва да ги приемат и приветстват.

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

С течение на времето фрийстайлът се превърна в обичайни практики. От които най-известният е Scrum.

Нека започнем нашите дефиниции с това.

Какво е Scrum?

Scrum е модел за развитие, разработен от Кен Швабер и Джеф Съдърланд и се използва от 90-те години на миналия век.

Работата е разделена на по-малки изисквания (истории, епопеи и задачи) и сплотени екипи изграждат и доставят на малки вноски. Често се търси обратна връзка и се правят подобрения на продукта под формата на чести кратки версии.

Стълбове

Стълбовете на Scrum са обяснени подробно по-долу:

  • Прозрачност : Екипите са наясно какво се случва и са отворени за споделяне и взаимно подпомагане. Комуникацията протича свободно чрез ежедневно изправяне и неформални взаимодействия между хората.
  • Инспекция : Честите и религиозни проверки на работата са ключът към успеха на Scrum. Екипите могат да идентифицират, диагностицират, отстраняват неизправности, поправят и да се върнат в релси по прост и надежден начин.
  • Адаптация : Scrum не предполага, че това, което правят, е правилно. Има периодични контролни пунктове под формата на Планиране на спринт, ежедневна скрам, преглед на спринт / ретроспективни срещи където екипът може да прегледа и адаптира.

Scrum Team

Scrum екипи обикновено са малки (5-9) и обикновено имат кръстосан функционален характер. Те включват a Scrum Master , разработчик, тестер (обичайна практика е всички гъвкави членове на екипа да се отнасят като разработчици, независимо от тяхната сфера на работа).

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

Scrum екип

Роли в Scrum

По-долу са дадени различните роли в Scrum:

  • Собственик на продукта: Собственик на продукт притежава изоставането. Той е отговорен за продукта и формата, която приема. Поддържането на изоставането на продукта, цялостната продуктова визия и насочването на целите на екипа към него са основните отговорности на собственика на продукта.
  • Екип на разработчика: Екипът на разработчика няма ограничени роли. От тях се очаква да работят междуфункционално и да изберат най-добрия подход за постигане на целта.
  • Scrum Master: Работата на капитана на скрама е да се увери, че скрамът е изпълнен по правилния начин. Scrum master се нарича още Слуга Лидер за целия екип.

Scrum церемонии

Agile разчита на няколко навика, за да остане на път и да бъде успешен.

Някои от тях са споменати по-долу:

# 1) Ежедневна скрам среща: Това е типична 15-минутна кратка среща, където всеки член на екипа говори за следните точки:

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

Този формат на срещата е много ефективен, за да се разбере каква работа е завършена, какво остава и как екипът може да си помогне, ако е необходимо.

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

# 2) Спринт : Спринт е итерация с време (често 3 седмици веднъж, но може да бъде по-дълга или по-кратка). Това е повтарящ се процес и може да се разглежда като един изблик на развитие и доставка.

# 3) Планиране на спринта: Целта на планирането на спринта е да планира как да превърне набор от истории за натрупване на продукти в приращение на продукта, който може да бъде изпратен.

Общият формат може да бъде като ситуация от 2 части.

  • Първата половина - Екипът избира елементите, които се ангажират да завършат.
  • Втора половина - Собственикът на продукта е на разположение за въпроси.

Екипът решава как да го изгради. По този начин задачите се създават и разпределят съответно, което води до Спиране на спринта.

# 4) Спринт преглед / Демо : След спринт, екипът и заинтересованите страни се срещат, така че завършената работа може да бъде представена.

Изпълнените задачи се сравняват с планираните елементи и функционалността, която не е приложена, се пропуска. Продължителността на тази среща е не повече от 4 часа.

# 5) Ретроспектива на спринта: Тази среща се улеснява от Scrum Master и целият екип, включително PO, присъства на него.

Екипът обсъжда скорошния Sprint, като фокусира идеите за подобряване на процеса и определя какви промени могат да бъдат направени, за да направят следващия Sprint по-продуктивен.

Обикновено, тази среща отнема не повече от 2 часа.

=> Препоръчително четене - Ловки ретроспективни срещи

Основи на пъргавата оценка

По-долу са дадени основите на Agile Estimation:

Входове

  • Изоставане на продукти и изоставане в спринта.
  • Исторически данни, предишни оценки за подобни задачи с действителни стойности на усилията, изразходвани за тях.

Очаквани участници

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

Определение към Epic / Feature / Idea

  • Това са големи потребителски истории, обикновено твърде големи, за да се приложат в една итерация.
  • Idea / Epic -> Stories -> Tasks (Една идея може да има множество истории. Една история може да има множество задачи. Обхватът на историята е ограничен до един Sprint. Всички задачи трябва да бъдат затворени, за да завършите историята)

# 1) Техника за оценка на историята: Story point е число, което казва на екипа колко сложна е историята.

В повечето случаи се използва серията Фибоначи или размерът на тениската. Обикновено една сюжетна точка се счита за еквивалентна на еднодневната работа на човек.

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

Включените стъпки включват:

  • Разбийте много големи изисквания на малки задачи.
  • Изберете екип от поне 2 оценители, Scrum Master , Собственикът на продукта и останалите могат да участват.
  • Всеки оценител разпределя частно своите точки от историята за потребителска история (задача) и публикува същите.
  • Историческите точки за изискването се разпределят от оценителите въз основа на техните предишни познания за размера на подобна задача.
  • Очаква се оценките да се различават леко.
  • Ако оценките се различават значително, тогава оценителите с високи и ниски стойности обясняват своите оценки.
  • След това се прави още един кръг на оценка от всички оценители, следвайки същия процес, докато всички те се сближат до един и същ брой.

# 2) Планиране на покер: Тази интересна и забавна техника е обяснена тук: Как да улесним гъвкавия процес на оценка с помощта на Planning Poker

Забележка :Има много други техники за гъвкава оценка, но това са двете най-известни.

Scrum Артефакти

Най-важните скрам артефакти са Product Backlog и Sprint Backlog . Това са тези, които помагат при наблюдението на общите цели на спринта.

# 1) Натрупване на продукти:

  • Подреден списък с „изисквания“, който се поддържа за продукт / проект.
  • Списък може да съдържа грешки и нефункционални елементи.
  • Собственикът на продукта е отговорен за определянето на приоритетите в PBL.
  • Собственикът на продукта е отговорен за управлението на натрупаните продукти.

# 2) Спринт изоставане:

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

# 3) Диаграма за изгаряне:

как пишете тестови случаи
  • Това е публично показана диаграма, показваща завършената и оставаща работа в спринта.
  • Показва действителната работа, която е завършена дневно.
  • Поддържа се от Scrum Master ежедневно.
  • Има два вида ‘Release Burn-down charts’ & ‘Sprint Burn-down charts’.

Диаграми за изгаряне

Определение на Готово

Определение на Готово е различно за различните скрам екипи. С прости думи, DoD е начин да разберете кога екипът ще постигне целта чрез наличните инструменти. Това е договорът между PO и екипа.

DoD met означава, че всички истории от изоставането са разработени в съответствие с изискванията на заинтересованата страна. Историите може да са нетехнически или да имат множество задачи.

Прецизиране на изоставането (поддържане)

Прецизиране на изоставането не е основна скрам практика, но е възприета като начин за управление на качеството на изоставащите елементи, влизащи в спринт.

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

Бързо сравнение с водопада

ПараметриПъргавВодопад
Удовлетвореността на клиентите Клиентите са доволни поради бързата доставкаДоставката закъснява, така че клиентите не са сигурни
Доставка на работещ софтуер Чести доставкиПо един на няколко месеца
Късни промени Може да бъде обхванат в предстоящата пролет бързоТруден за изпълнение
Комуникация Ежедневна комуникацияПреглед на срещата с ръководител на проекти
Зависимост Тясна комуникация и сътрудничество между бизнесмени и разработчици - тестери.Ръководителят на проекта управлява проекта

Натрупване на продукти

Докато се движим нагоре, се създават PBI и те са ДЪЛБОКИ:

  • Д- Доста подробно
  • IS- Emergenc е
  • IS- Приблизително
  • P- Приоритизирани

И те са по-подробни за екипа.

Натрупване на продукти

Неща, към които Scrum Master трябва да се адаптира:

  • Премахване на пречките
  • Улеснявайте
  • Наставничество и преподаване
  • Коучинг

Това са задачите, които а Scrum Master трябва да изпълнява, когато Scrum е ново внедрена. Но с течение на времето и когато екипът свикне със Scrum (става Самоорганизиран), Scrum Master има задача да изпълни, т.е.да ‘НАБЛЮДА’.

Изграждане на Scrum екип

Докато изграждате екип, Scrum Master може да се изправи пред следните предизвикателства - Формиране, щурмуване, нормиране и изпълнение.

  • Формиране- Където няма отношения в екип.
  • Штурм- Където границите между членовете на екипа биха станали светли.
  • Нормиране- Когато в екипа има установени добри отношения.
  • Изпълнение- Това е последният етап, в който има само работа в екип.

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

Заключение

Надяваме се, че този урок е обяснил накратко всичко важно Терминология Agile And Scrum . Моля, обърнете се към тази поредица от уроци Пълно ръководство за гъвкава методология за подробности относно Agile / Scrum концепциите.

Честита пъргавина!

Препоръчително четене

^