Agile Board

У цьому завдань завжди більше, ніж ресурсів. Всім замовникам потрібно зробити завдання якомога раніше, всі піднімають пріоритети своїх завдань. У розробників витрачалося дуже багато часу на те, щоб розібратися, які з цих невідкладних завдань найнагальніші. Це дуже гальмувало розвиток, і треба було щось робити. Зробити так, щоб кожен розробник знав, які саме завдання йому займатися сьогодні, а які можна відкласти на завтра, наступний тиждень, місяць.

Зрештою більшість наших проблем вдалося вирішити за допомогою Agile Board та Scrum, але дійшли ми цього далеко не відразу, а поетапно.

Насамперед ми завели фільтри. Непоодинокі випадки, коли менеджер спочатку стверджує, що завдання суперстрокове, у продакшені все зламалося і т.д. А коли починаєш з'ясовувати, скільки користувачів ця проблема зачіпає, виявляється, що цією конкретною фічею користуються три особи на день, та й відтворюється баг далеко не щоразу. Відповідно, завдання можна вирішити за місяць. Ми також розділили завдання на ті, що торкаються виключно верстки (поправити колір, відступи тощо) та інфраструктурні, до вирішення яких потрібно залучати також розробників бекенду.

Ми все це назвали компонентами. Стало зрозуміліше, які завдання, коли робити. Завдяки фільтрам вдалося скоротити кількість завдань, що висять щодня на розробнику приблизно до 20. Орієнтуватися в них стало набагато легше.

Але все ж таки з наочністю як і раніше була проблема. І вирішувати ми її спершу спробували за допомогою дашборду. Рішення виявилося далеко від ідеалу. Насамперед дашборду не вистачало інтерактивності. Наприклад, щоб змінити статус завдання або змінитивиконавця доводилося відкривати нову сторінку. Та й працювало все це не дуже швидко, JIRA є JIRA.

Незважаючи на всі ці вади, було ясно, що ми рухаємося в правильному напрямку, просто треба піти ще далі. І тоді ми вирішили спробувати Agile Board. У нас у JIRA вже був встановлений чудовий плагін Green Hopper, який вміє робити Scrum та Kanban.

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

Там є дуже хороша картинка, яка це все пояснює:

У нас є якась кількість завдань у проекті, яка потребує попередньої фільтрації для спринту. Спринт - процес розробки, що повторюється, в рамках якого ми впроваджуємо нові фічі і чинимо баги.

Готуємо робоче місце

Почали ми з малого — навели лад у JIRA. Замість купи компонентів та версій, ми залишили:

компонент «Верстка: інфраструктура»;
компонент «Верстка: інтерфейс»;
опціональні продуктові чи технологічні компоненти, наприклад: платформа – iOS, продукт – підвал;
версія backlog;
продуктові версії для запусків

Крім цього ми запровадили деякий набір правил для написання та компонування завдань:

короткий і чіткий заголовок, краще з дієсловом;
мінімально необхідний та чіткий опис завдання з усіма необхідними даними, бажано без посилань на зовнішні джерела;
повинні бути вказані компонент та версія
завдання вимірюване і кінцеве;
відмовляємося від гігантських батьківських завдань, на кшталт "Запуск нового інтерфейсу картинок";
батьківські завдання використовуються для завдань, які можна зробити за тиждень;
всі сабтаски у батьківських завдань справді є декомпозицією завдання;
використовуємо механізм лінкування завдань, якщо вони пов'язані один з одним.

Налаштовуємо Agile Board

Насамперед, треба вибрати тип: Scrum чи Kanban.

Потім необхідно заповнити його даними.

Ми зробили фільтр, який є джерелом даних для нашої Agile Board. Цей фільтр відбирає проектні завдання з компонентами для верстки, з проставленою версією «backlog». Backlog означає, що ми повинні зробити це завдання у найближчі пару спринтів.

Відповідно до workflow роботи над завданнями необхідно додати нових колонок і призначити на них відповідні статуси.

За замовчуванням три колонки: to do, in progress, done. У нас їх більше:

to do – завдання, які нам залишилося зробити у межах поточного спринту;
in progress – завдання, які ми робимо зараз;
on review – завдання, у яких прямо зараз рев'ювимо реалізацію;
commited – завдання, які вже запрограмовані, але готові до тестування;
testing – завдання, які готові до тестування чи тестуються на даний момент;
done - Виконані завдання.

Останні дві колонки можуть бути поєднані в одній. Наприклад, зараз у нас в одному з проектів немає колонки "testing", а є одразу "done".

Налаштовуємо угруповання завдань. За промовчанням групуються за assignee. Нам це цілком підійшло.

Налаштовуємо кольори карток, щоб можна було візуально відрізняти баги від фічі.

Налаштовуємо швидкі фільтри. Дуже зручна штука. Коли завданьбагато, дозволяє швидко їх пофільтрувати за різними параметрами. Фільтри можна поєднувати.

Estimation, working days та issue detail view ми поки що не використовуємо.

Використовуємо Agile Board

Ми прийняли тривалість спринтів за один тиждень. Відповідно, на першій проектній синхронізації ми набираємо завдань на тиждень та беремо їх у роботу. Відбувається це на вкладці Plan.

Наповнити спринт можна двома способами:

просто розтягнути блок донизу, захоплюючи з бэклога необхідні завдання;
перетягнувши drag&drop'ом завдання з backlog в спринт.

Завдання в backlog можна сортувати як вам завгодно простим перетягуванням. Ми займаємося цим раз на тиждень із проектними менеджерами – до зустрічі про синхронізацію.

При наповненні задачі можна ткнути на будь-яке завдання, і в правій колонці з'явиться опис задачі:

Коли спринт наповнений – стартуємо його. Далі можна працювати із вкладкою Work.

У цьому режимі можна також переглянути детальний опис будь-якого завдання, змінити статус задачі drag&drop'ом (перетягнути з in progress в on review). Цю вкладку ми проглядаємо на синхронізації в середині тижня, обговорюючи прогрес завдань.

На початку нового тижня ми завершуємо спринт та переходимо на вкладку Report. При цьому ми одразу бачимо скільки завдань ми зробили, а скільки ні. Незавершені завдання потрапляють нагору backlog, вони будуть зроблені в рамках наступного спринту насамперед. Крім цього, є кілька звітів, наприклад:

sprint report;

Другий графік дає нам розуміння, скільки часу ми в середньому живуть завдання до закриття. На графіку видно, що є сплеск:

Це довгограюча задача для вимірюванняпродуктивність. Саме для цієї задачі — все ОК, але для інших завдань — явний сигнал, що формулювання завдання неправильне та/або воно потребує декомпозиції. За допомогою цього графіка, а також поля Sprint у кожного завдання, ми можемо відстежувати терміни виконання завдань, і якщо вони зависають, вживати заходів.