Методологія

У якості методології управління проектом необхідно використовувати SCRUM з наступними необхідними атрибутами:

backlog

Список функціональностей, які команда прагне зробити в найближчому майбутньому. Список може бути більше, ніж команда може зробити за весь час олімпіади. Команда споконвічно самостійно формує цей список, а по закінченню 1-го спринту корегує його;

спринти

Команда працює короткими ітераціями довжиною в 1 тиждень. Спринт починається із планування й оцінок завдань на наступний тиждень, а закінчується демо для журі, після чого команда робить ретроспективу й починає новий спринт.

планування спринту

Перед початком кожного спринту, починаючи з 1-го, команда обговорює, що вона буде показувати на наступному демо для журі, на якому команді будуть нараховуватись бали. Виходячи з того, що в backlog завдань буде більше, ніж команда може зробити, то їй необхідно самостійно пріоритезувати завдання, для того, щоб заробити якнайбільше балів. Відібрані завдання обговорюються командою з технічної сторони, призначаються відповідальні й завдання переноситься в стовпчик Planned. Якщо запланована функціональність не може бути виконана 1-ю людиною, або її виконання займає більше декількох днів, то завдання декомпозується на більш дрібні, для того, щоб команда могла відстежувати свій прогрес на дошці. Команда має намагатися брати в спринт рівно ту кількість завдань, яку вона в стані виконати за 1 тиждень.

демо для журі

Подія, на якій команда презентує нову функціональність для журі. На демо мають бути представлені закінчені функціональності, які мають сенс для кінцевого користувача (наприклад, реєстрація користувача в системі). Окремі технічні функціональності такі, як саме була настроєна база даних або підключена та або інша бібліотека самостійно демонструватися не повинні. При цьому журі залишає за собою право ставити технічні запитання й вимагати продемнострувати деталі такої функціональності. Журі також буде самостійно відтворювати можливі сценарії використання продукту, тим самим намагаючись знайти вузькі місця й недоліки в системі. За результатами демо журі виставляє оцінки командам (див. нижче), а також критикує продукт і дає побажання про подальше поліпшення. Журі виступає в ролі замовника або споживача кінцевого продукту.

ретроспектива

Після демо (на наступний або в цей же день) команда збирається на ретроспективу, де проводиться аналіз успішності попереднього спринту - на основі завдань, що залишилися; у колонку Planned оцінюється оптимістичність або песимістичність власних прогнозів на спринт, у результаті чого робляться висновки й коректування для наступного спринту. Робиться аналіз зворотного зв'язку отриманого від журі, на основі якого додаються й пріоритизуються нові завдання в backlog.

реліз

Ітерація дорівнює 3 спринтам, після якого олімпіада вважається завершеною. На реліз команда повинна представити MVP (mіnіmal vіable product), який готовий для експлуатації реальними користувачами за, що команди можуть одержати найбільшу кількість балів.

стендапи

Щоденні внутрішні наради команди лімітовані за часом в 15 хвилин, на яких кожний учасник коротко розповідає, чим він займався вчора, чим планує займатися сьогодні й з якими проблемами він зіштовхнувся. У випадку, якщо на стендапі в рамках озвучування свого статусу виникають додаткові питання, які не можуть бути вирішено протягом 1-2 хвилин, то обговорення зупиняється й переноситься на час після закінчення стендапу для того, щоб усі встигнули розповісти про свій статус за 15 хвилин. Також статус кожного учасника команди має бути актуально відображений на дошці для того, щоб лідер команди міг розуміти, чи встигає команда до демо і якщо ні, ухвалювати якісь заходи.

Отправить отзыв

Реєстрація