Комментарии 17
Куда-то пропала проблема 2 :)
Можн проапгрейдить, добавив количество задач на каждом этапе.
Картинка красивая.
Можн проапгрейдить, добавив количество задач на каждом этапе.
Картинка красивая.
А можно поконкретнее по поводу количества задач? Что именно было бы интересно?
Интересная статья. Спасибо автору :)
А скажите, у вас аналитика включена в канбан-цепочку? С какого момента вы начинаете мерять прохождение задачи? С момента начала проработки требований или тогда, когда выуживаете из бэклога?
Случалось ли такое, что задача, уже поступившая в разработку, сдвигалась в пользу срочной, более приоритетной задачи?
А скажите, у вас аналитика включена в канбан-цепочку? С какого момента вы начинаете мерять прохождение задачи? С момента начала проработки требований или тогда, когда выуживаете из бэклога?
Случалось ли такое, что задача, уже поступившая в разработку, сдвигалась в пользу срочной, более приоритетной задачи?
В данном случае был большой запас по аналитике, и в канбан цепочку мы ее не включали. Требования разрабатывались парралельно процессу разработки.
По поводу срочных задач — да, такое было довольно часто, мы старались не бросать незавршенные задачи, но иногда приходилось что-то ставить на паузу в пользу более срочной задачи.
По поводу срочных задач — да, такое было довольно часто, мы старались не бросать незавршенные задачи, но иногда приходилось что-то ставить на паузу в пользу более срочной задачи.
Спасибо за статью :)
К автору есть несколько вопросов.
как быть, если задачи связаны? И нет смысла выкладывать на сервер одну без решения другой — заказчику не принесет это ценности.
К примеру, тривиальная система по обработке заказов: клиент регистрируется, формирует заказ,
отправляет заказ, менеджер его обрабатывает, посылает запрос складу, склад формирует накладные,
отправляет заказ клиенту, потом менеджер фиксирует факт оплаты и закрывает заказ.
Тут выходит, что надо решить все задачи и только тогда выкладывать, в этом случае заказчик продукта сможет его использовать в работе. Кроме того, сложно протестировать задачи по отдельности,
без контекста, потому как действия, совершенные в одной функции, скажем так, влияют на другую,
и от того, как будет реализована первая функция, зависит реализация второй.
Можно, допустим, предварительно сделать детальное проектирование всего, но,
как известно, это не круто :)
Второй вопрос:
данная система предполагает, что задачи делаются и вычеркиваются из списка последовательно.
Но часто бывает следующее:
Задача1, Задача2, Задача3 — связаны.
И оптимальный, возможно :), путь решения — реализовать 70% функционала каждой задачи, после чего
выпустить релиз. А остальное доделать в следующей итерации(-ях).
Как вы поступаете в таких случаях?
К автору есть несколько вопросов.
как быть, если задачи связаны? И нет смысла выкладывать на сервер одну без решения другой — заказчику не принесет это ценности.
К примеру, тривиальная система по обработке заказов: клиент регистрируется, формирует заказ,
отправляет заказ, менеджер его обрабатывает, посылает запрос складу, склад формирует накладные,
отправляет заказ клиенту, потом менеджер фиксирует факт оплаты и закрывает заказ.
Тут выходит, что надо решить все задачи и только тогда выкладывать, в этом случае заказчик продукта сможет его использовать в работе. Кроме того, сложно протестировать задачи по отдельности,
без контекста, потому как действия, совершенные в одной функции, скажем так, влияют на другую,
и от того, как будет реализована первая функция, зависит реализация второй.
Можно, допустим, предварительно сделать детальное проектирование всего, но,
как известно, это не круто :)
Второй вопрос:
данная система предполагает, что задачи делаются и вычеркиваются из списка последовательно.
Но часто бывает следующее:
Задача1, Задача2, Задача3 — связаны.
И оптимальный, возможно :), путь решения — реализовать 70% функционала каждой задачи, после чего
выпустить релиз. А остальное доделать в следующей итерации(-ях).
Как вы поступаете в таких случаях?
Если релиз какой-то задачи не возможен без другой задачи, она ожидает на stage сервере, пока функционал не будет реализован полностью. После чего есть возможность провести полноценное интеграционное тестирование, затем на боевой сервер выносится группа задач
Стоит дополнить по первой части вопроса:
В этом конкретном случае ситуация, описанная в первом примере, не составляла проблем, т.к. проект действующий, с уже реализованными основными возможностями, мы занимались добавлением достаточно небольших улучшений и дополнений, попутно исправляя баги.
Разработка системы с нуля имеет свои особенности, и подобная схема работы может быть не так эффективна.
Что касается второй части вопроса, то тут желательно стараться максимально дробить задачи, как раз для того, чтобы иметь возможность сначала реализовать работающий костяк, а потом заниматься улучшениями. А в процесс это вписывается довольно просто — «улучшение задачи№1 — это задача№2»
В этом конкретном случае ситуация, описанная в первом примере, не составляла проблем, т.к. проект действующий, с уже реализованными основными возможностями, мы занимались добавлением достаточно небольших улучшений и дополнений, попутно исправляя баги.
Разработка системы с нуля имеет свои особенности, и подобная схема работы может быть не так эффективна.
Что касается второй части вопроса, то тут желательно стараться максимально дробить задачи, как раз для того, чтобы иметь возможность сначала реализовать работающий костяк, а потом заниматься улучшениями. А в процесс это вписывается довольно просто — «улучшение задачи№1 — это задача№2»
В случае 1-2недельных итераций всегда есть время, чтобы обкатать изменения на боевом сервере. Если обнаруживаем баг в новой версии, то сразу же откатываемся на предыдущую и правим баг. Если нет — считаем версию стабильной.
В данном же случае, как я понимаю, изменения могут поступать на боевой сервер и по нескольку раз в день. Если обнаруживаем баг, то 1) сложнее найти поставку, в которой он был допущен, 2) становится проблемой откатиться до версии перед багом, т.к. за это время была куча других поставок (попробуйте объяснить пользователям почему вдруг исчез функционал, не связанный с найденным багом).
В результате, никогда нельзя сказать, что есть стабильная версия + вероятность авралов, связанных со срочным исправлением багов, дабы не откатываться. Как считаете?
В данном же случае, как я понимаю, изменения могут поступать на боевой сервер и по нескольку раз в день. Если обнаруживаем баг, то 1) сложнее найти поставку, в которой он был допущен, 2) становится проблемой откатиться до версии перед багом, т.к. за это время была куча других поставок (попробуйте объяснить пользователям почему вдруг исчез функционал, не связанный с найденным багом).
В результате, никогда нельзя сказать, что есть стабильная версия + вероятность авралов, связанных со срочным исправлением багов, дабы не откатываться. Как считаете?
Не могу не согласиться, но всегда есть особенности. Систему требовалось построить так, чтобы релиз срочного исправления не был стрессом для процесса и команды. На практике же, работы, ведущиеся по плану, выпускались 1-2 раза в неделю, иногда реже.
Что касается стабильности релизов, мы традиционно используем CI практику, что, является достаточным для обеспечения необходимого качества.
Что касается стабильности релизов, мы традиционно используем CI практику, что, является достаточным для обеспечения необходимого качества.
Посмотрел картинку изобретенного процесса — не совсем понял, что же «нового».
Кроме того — в тексте формулируются 3 «проблемы» которые возникли перед проектной командой, которые и решил новый способ организации. Не совсем понятно как предложенный способ решает 3ю проблему и в чём преимущество перед традиционными итерационными методами с очередями заданий и обратными связями.
Сложилось ощущение, что автор находится во власти «предвзятости выжившего», указывая причиной успеха «новую» методику.
Кроме того — в тексте формулируются 3 «проблемы» которые возникли перед проектной командой, которые и решил новый способ организации. Не совсем понятно как предложенный способ решает 3ю проблему и в чём преимущество перед традиционными итерационными методами с очередями заданий и обратными связями.
Сложилось ощущение, что автор находится во власти «предвзятости выжившего», указывая причиной успеха «новую» методику.
В данной схеме нет ничего нового, все это стандартные инструменты Scrum и Kanban, да и само по себе совмещение этих методологий общепринятая практика. Цель статьи — показать на реальном примере, что может быть причиной для пересмотрения своего процесса разработки, побудить непосредственно участников команд к изучению и использованию новых инструментов.
По поводу 3-й проблемы — используя данную схему работы мы получили необходимую гибкость для того, чтобы постоянные изменения в плане как можно меньше отражались на работе команды.
По поводу 3-й проблемы — используя данную схему работы мы получили необходимую гибкость для того, чтобы постоянные изменения в плане как можно меньше отражались на работе команды.
Красиво и понятно расписано. Хорошая статья.
Работаю по примерно такой же схеме. Но разница с Вашими проектами в том, что изменяемые требования и приоритеты у меня в каждом проекте.
В большинстве проектов используем Канбановское ограничение по задачам на определенных стадиях в дополнение к Вашему гибриду Скрам-Бан. В контракте эти ограничения прописаны. Лично мое мнение — этот гибрид методологий самый идеальный, разве что можно включить еще коллективное владение кодом (XP) и ревьювинг.
Работаю по примерно такой же схеме. Но разница с Вашими проектами в том, что изменяемые требования и приоритеты у меня в каждом проекте.
В большинстве проектов используем Канбановское ограничение по задачам на определенных стадиях в дополнение к Вашему гибриду Скрам-Бан. В контракте эти ограничения прописаны. Лично мое мнение — этот гибрид методологий самый идеальный, разве что можно включить еще коллективное владение кодом (XP) и ревьювинг.
Смысл проделанных ритуальных действий — в отказе от Scrum. Проблема была в том, что вы работали по скраму. Как только перестали — стало хорошо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Scrum-ban