Яка роль відстежувача традиційних випусків при використанні дошки Scrum / Kanban?

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

1. Традиційні трекери, такі як Fogbugz, JIRA, BugZilla, Trac, Redmine тощо.
2. Віртуальні карткові дошки / спритні інструменти управління проектами, такі як Pivotal Tracker, GreenHopper, AgileZen, Trello тощо

Звичайно, вони так чи інакше перекриваються, наприклад, завдання Pivotal Tracker можна імпортувати до JIRA, сам GreenHopper реалізується поверх бази випусків JIRA тощо. Але я думаю, що все ще можна побачити різницю в орієнтації між цими двома типами інструментів.

Здається, традиційний трекер випусків використовується навіть у компаніях, які в іншому випадку займаються спритним управлінням проектами. Моє запитання: чому вони це роблять? Я також вважаю, що ми повинні використовувати інструмент відстеження проблем у своїй компанії, але коли я думаю про це, я не знаю, нащо нам це потрібно.

Наприклад, розробкою Trello, здається, керують за допомогою самого Trello (див. Цю віртуальну стіну ), хоча вони мають доступ до Fogbugz, одного з найкращих трекерів, що випускають проблеми. Тож, може, нам не потрібен традиційний трекер випуску, коли ми будемо робити 100% своєї роботи спритно, використовуючи один із спритних інструментів PM?

Існує (принаймні) три різні способи роботи команди. Виберіть той, який працює для вашої команди.

1. Деталі та огляд високого рівня

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

2. Помилки та функції

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

3. Основна сторінка доставки програмного забезпечення проти постійної доставки програмного забезпечення

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

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

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

Звичайно, для обох інструментів можна використовувати будь-який тип інструменту, але вам доведеться піти на компроміси.

Повне розкриття інформації: Я трохи упереджений, тому що я менеджер продуктів GreenHopper в Atlassian, але також довго займався розробкою Agile за межами Atlassian

Наявність просто інструменту планування Agile або просто трекера проблем, безумовно, є життєздатним. Проблема в тому, що це недостатньо оптимально. На мій досвід, це недостатньо оптимально, оскільки:

• Планування продукту зазвичай відбувається на відстані епічного та історійного періоду. Складні інструменти планування тут чудові
• Однак, як свідчить стара приказка, жоден план не переживає першого контакту з ворогом. У цьому випадку після перших кількох релізів ви зобов'язані закінчити з помилками (і інший зворотним зв'язком), який увійшов на QA, клієнти, підтримка і т.д. Вони повинні годувати назад в планування , але не придушувати його

Таким чином, просто використовувати інструмент планування Agile - це чудово, але в міру того, як ваш продукт дозріває і ви отримуєте більше зовнішнього введення, важче та складніше ефективно керувати цим входом. Деякі з цих зовнішніх дописувачів просто не можуть внести свій внесок у спосіб "керованого Agile відставання", вони просто хочуть подати свою проблему та продовжити роботу. Ось де наявність інструмента відстеження проблем дозволяє залучати цих учасників та успішно керувати поточним бізнесом, спрямованим на розвиток продукту.

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

Деякі продукти трохи оптимізовані для історій та завдань у порівнянні з дефектами, але насправді немає великої різниці. Будь-який хороший спритний інструмент PM, який не накладає занадто великі накладні витрати з точки зору примусової структури або необхідних полів, може легко використовуватися для відстеження дефектів. Мій поточний проект використовує єдиний інструмент як для завдань, так і для дефектів, і він працює нормально, окрім того, що продукт є POS :)

Ми запускаємо трекер випуску під назвою DoneDone, який відповідає №3 у відповіді Джоела - більш традиційна роль трекера помилок. Дійсно, ми створили це тому, що наша консультація історично постачає багато коду (у вигляді веб-сайтів) через нерегулярні інтервали.

Ми трохи прозвучали до нашої бази користувачів DoneDone місяць тому, хоча, і досить багато з них попросили передового роду схожих на Trello та Sprint.ly для їх більш безперервного циклу коду / випуску. Іншим корисним розумінням було те, що багато хто з цих людей використовують DoneDone до того, як починається QA, тому вони хочуть, щоб усі ці дані були в одному місці, коли їх проекти (або функції) рухалися між циклами.

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

Відстеження випусків не є управлінням проектами, хоча багато інструментів розроблені для того, щоб ви могли робити те і інше, тому одна система насправді не замінює іншу,

Дошка Kanban дає вам прекрасний огляд вашої роботи, яка є поточною та видатною, і давайте нам з першого погляду дізнаємося, які пріоритети, тоді як інструмент відстеження проблем дозволяє прив’язати свої проблеми до вашої системи контролю версій, і працює краще як засіб реєструвати все, що повинно бути у вашому відстані від Kanban, але з додатковими деталями, які інакше перетворили б вашу дошку Kanban справжній безлад для читання.

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

Я не знаю, чи є чітка відповідь, тому я просто повідомляю про свій досвід ...

В протягом багатьох років я був повністю проданий на реальних системах стеження помилка, як FogBugz, Jira, Trac і т.д. Тим НЕ менше, я недавно влаштувалася на роботу , де ми моторні ( по- справжньому бути гнучкими, а не просто робити Agile). У нас немає довгих історичних списків помилок чи приємних елементів.

Такого інструменту просто немає. Все, що важливо, ми отримуємо досить швидко. Що-небудь не таке важливе, ну, який сенс?

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