Пътна карта
По-долу е кратко описание на начина, по който планираме и изпълняваме нашата работа през годината. То е предназначено за клиенти и партньори, които желаят да имат преглед на нашия тримесечен подход, нашите двуседмични спринтове и как управляваме PI (Program Increment) Планиране две седмици преди края на всяко тримесечие.
Пътни карти
Разгледайте нашите пътни карти, за да получите преглед на нашите текущи приоритети и нашата визия за годината.
Защо е важно за вас
- Прозрачни етапи: Ще знаете точно кога започват и завършват спринтовете и кога се провеждат основните планиращи събития (PI Планиране).
- Редовни проверки: Всеки спринт включва среща за преглед (или демонстрация), на която можете да видите напредъка, да предоставите обратна връзка и да поискате корекции.
- Проактивно съгласуване в края на тримесечието: Организирането на PI Планиране две седмици преди края на тримесечието ни позволява лесно да се адаптираме към приоритетите на следващото тримесечие, без да бързаме.
Работим заедно
- Останете ангажирани: Вашата обратна връзка по време на прегледите на спринтовете и сесиите за планиране ръководи нашите решения относно функции, корекции и приоритети.
- Предвиждайте: С етапи, зададени на всеки две седмици (за спринтове) и всяко тримесечие (за PI Планиране), можете да коригирате собствените си бизнес или срокове за пускане съответно.
Преглед на Работните Елементи
AI Smarttalk управлява два основни типа входящи работни елементи:
- Функции – Нови функции или подобрения на съществуващите.
- Бъгове – Дефекти или проблеми в съществуващите функции, които изискват поправка.
По-долу е бърз преглед на това как функциите и бъговете обикновено напредват през нашия процес:
| Тип елемент | Време за преглед | Типичен приоритетен поток | Планиране на ритъм |
|---|---|---|---|
| Функции | Прегледи на приоритетите на всеки две седмици | Прието (в беклога) / Отложено / Отхвърлено | Подробно по време на PI Планиране (на всеки 3 месеца) |
| Бъгове | Непрекъснато триажиране; критичните бъгове се анализират възможно най-скоро | Гореща поправка (ако е критичен) / Поправка на бъг (ако е по-малко критичен) | Може да бъде включен в текущия или следващия спринт |
Годишен План – Преглед
Разделяме годината на четири тримесечия (Q1, Q2, Q3, Q4). Всяко тримесечие обикновено обхваща три месеца, и използваме двуседмични спринтове за разбиване на н ашата работа. Този подход осигурява:
- Редовни актуализации според предсказуем график.
- Чести цикли на обратна връзка, където можете да споделите вашите идеи и да насочите проекта.
- Адаптивност в случай, че приоритетите се променят в средата на тримесечието.
Ключови Милестонове
-
Спринтове (на всеки 2 седмици)
- Провеждаме серия от двуседмични спринтове през тримесечието. Всеки спринт завършва с преглед на завършената работа и планиране на следващите стъпки.
-
PI Планиране (2 седмици преди края на всяко тримесечие)
- Две седмици преди края на всяко тримесечие провеждаме сесия за PI Планиране.
- Защо 2 седмици преди? Този график ни позволява да съберем достатъчно информация, обратна връзка от потребителите и наличността на екипа, за да финализираме целите за следващото тримесечие, без да нарушаваме последния спринт.
-
Преход между тримесечията
- В края на всяко тримесечие събираме находките от прегледите на спринтовете, включваме последната обратна връзка и подготвяме целите за следващото тримесечие.
Как обикновено протича едно тримесечие
Едно тримесечие (например, Q1, от 1 януари до 31 март) се състои от 6 спринта с продължителност приблизително 14 дни всеки. Ето типичния график:
- От Спринт 1 до Спринт 5 – Нормални цикли на разработка, всеки с продължителност две седмици.
- PI Планиране – Провежда се около петия или шестия спринт, приблизително две седмици преди края на тримесечието.
- Финален спринт и закриване – Използваме финалния спринт за финализиране на доставките и раз решаване на всички оставащи проблеми. В края на тримесечието имате ясна представа за завършените функции, разрешените проблеми и предстоящите стъпки.
- Q1 обхваща периода от 1 януари до 31 март (приблизително 90 дни).
- Q2 обхваща периода от 1 април до 30 юни и т.н.
- Всяко тримесечие включва постижение (PI Q1, PI Q2 и т.н.) две седмици преди края на тримесечието (например, Q1 приключва на 31 март, PI Q1 е насрочено за 17 март).
Забележка: Тази структура (6 спринта на тримесечие, всеки с продължителност 2 седмици) може да варира леко в зависимост от действителния календар, празници или специфични нужди на проекта. Въпреки това, двуседмичният ритъм на спринтовете и PI Планирането преди края на тримесечието остават постоянни, за да ви предоставят предсказуеми постижения.
Глосар
По-долу е глосар на термини, често използвани в нашата методология на разработка:
Спринт
- Определение: Период от време (обикновено 1 до 2 седмици), през който екипът се фокусира върху набор от цели (потребителски истории, задачи), за да достави функционален продуктен инкремент.
- Цел: Да се позволят бързи итерации, честа видимост на напредъка и възможността за корекции в края на всеки спринт.
PI (Програмна инкрементация)
- Определение: По-дълъг времеви интервал (често тримесечие, ~8 до 12 седмици), който групира множество спринтове.
- Цел: Да се планират и координират екипите по по- широки стратегически цели, като същевременно се позволява корекции за по-дълъг период от време в сравнение със спринт.
Беклог
- Определение: Приоритизирана списък на функции, подобрения и корекции, които трябва да бъдат реализирани. Той се поддържа от Продукт Оwner или продуктовия екип.
- Цел: Да се гарантира, че екипът се фокусира върху елементи, които предоставят най-висока стойност за продукта или проекта.
Потребителска история
- Определение: Кратко описание на функция от гледна точка на потребителя (“Като [тип потребител], искам [възможност], за да [полза]”).
- Цел: Да се фокусира върху стойността за потребителя и да се уточнят функционалните изисквания.
Епик
- Определение: Потребителска история в голям мащаб, която обикновено може да бъде разложена на няколко по-малки истории.
- Цел: Да се управляват и структурират сложни функции или проекти в голям мащаб.
Релийз
- Определение: Доставяне на стабилизирана версия на продукта в производствената среда или на потребителите.
- Цел: Да се предостави usable стойност и да се съберат конкретни отзиви.