Комментарии 13
Хорошо, когда такой диалог есть - зачастую его может и не быть.
Я ещё в 0х делал у задач Task состояния State с разными видами состояний Kind
Задача была в нескольких состояниях за цикл жизни
Заявлена
Анализируется
Принята в работу (описана. Есть ТЗ, понимание)
Исполняется. (Назначен исполнитель и срок реализации)
Выполнена. Исполнена
Проверяется. Тестируется
Дорабатывается
Залита в релиз
Завершена . Закрыта
При этом этапы тестирований бывают разные
Просто тестирование самой задачи, отладка, тестовые прогоны данных, интеграционное тестирование и конечно же тестовая эксплуатация
И только после хотя бы месяца удачной тестовой эксплуатации у заказчика задачу можно с чистой совестью закрыть как завершенную.
Также был контроль перехода состояний
Задачу нельзя было просто так закрыть, не пройдя все стадии.
У вас нет разграничение зон ответственности.
Почему вы у разработчика спрашиваете, готова ли фича? После его работы фича проходит стадии документирования, тестирования, деплоя. За все это отвечают другие люди и команды. Разработчик честно сказал, что он выполнил свою часть работы, вы выкатываете к нему претензии, что фича не на проде. Как так?
В этой ситуации виноват конкретно тот, кто спрашивает. Он не знает, кто за что ответственен? Он не знает, какие этапы проходит фича?
Здесь картиночки, Done, Potentially shippable не поможет.
Необходимо внедрение процесса разработки, воркфлоу, контроля передачи ответственности и закрытия этапов/работ. Короче Jira (хотя бы) спасет отца русской демократии.
У разработчика спросили, готова ли задача. Задача, если иметь в виду задачу на разработку, готова.
У разработчика не спрашивали, готова ли фича.
Цель любой задачи - улучшение качества продукта. Поэтому задачу можно считать выполненной когда она улучшает качество продукта. В данном случае - не улучшает, цель не выполнена.
Часто бывает что сотрудники (это касается не только разрабов) делают задачи, а не делают продукт. Да, такой подход работает, и никуда мы от него не денемся. Судить плохо это или хорошо - сложно, нужны и драйверы, и пушеры, и вот такие ребята. Менеджеру надо знать какие люди нацелены на продукт, а какие на закрытие тасочек (грубо, но так и есть), и балансировать это дело.
Цель любой задачи - улучшение качества продукта.
Нет, это цель фичи (Feature), а не задачи (Task)
Это и есть одна из проблем коммуникации и разного взгляда на вещи участников одного процесса. Что я и постарался описать в данной статье и привести пример, как эту проблему (проблему коммуникации) можно решать. Как выше в комментариях отметили - это можно решить и другим способом, например сильно разграничив зоны ответственности и выстроить waterfall. У каждого подхода есть свои плюсы и минусы, и нужно выбирать инструмент и подход в зависимости от вашей конкретной ситуации.
пример диалога всё же реально некорректный. Разработчик никогда не будет понимать под задачей фичу. Больше похоже, что менеджер с Марса и сам не в курсе как идёт работа. Выкатка фичи в прод - это процесс, в котором участвует куча людей - PO, тимлид/техлид, QA, аналитики, devops. Задавать вопрос по выкатке разработчику, который в самом низу это просто странно.
Тогда все в корне неверно, потому что на прод выливается фича а не задача. И спрашивать у кого угодно можно ли вылить задачу - глупо )
Вы правы! Кажется, на картинке русскоязычная формулировка неверная, поэтому можно спутать с тем, что в скраме называется Definition of Ready
Мы начали с того, что все этапы, описанные в данной статье как часть DoD, делали отдельными статусами фичи (используем Канбан): на каждом этапе описывали вход/выход/ответственного и критерии приемки результата этапа. Получилось с десяток отдельных статусов.
Со временем от части статусов отказались, тк начали лучше друг друга понимать. При этом, описание отключенных статусов преобразовали в некий гайд по жизненному циклу фичи (для новых сотрудников).
По итогу вышли на тот самый документ, о котором речь, но уже осознанно и с учетом особенностей нашего процесса.
Всем добра!
"менеджер открывает для себя статусы в Jira" смотреть без регистрации и СМС
Задача готова! Или нет? Definition of Done и зачем он нужен