Канплан: где ваше отставание встречает Канбан
Подходит для вашей команды практика Agile со смешанной методологией?
Там нет никакой серебряной пули, когда дело доходит до выбора Agile структуры для вашей Agile команды. Используете ли вы kanban, scrum или их комбинацию, например scrumban и kanplan, Agile - это командный процесс. Каждая команда должна выяснить, какая структура работает лучше всего, как основа для планирования, отслеживания и релиза отличного программного обеспечения.
Scrumban против kanban против scrum
Kanban стремится дать членам команды достаточно работы, чтобы команда постоянно работала в полную силу. Команды, практикующие kanban, извлекают выгоду из гибкого (flexible) планирования, более четкой направленности и полной прозрачности, потому что все, что есть на доске, является главным приоритетом. Это то, над чем работают разработчики. Kanban отлично подходит для оперативных групп, ориентированных на постоянное предоставление с меняющимися приоритетами.
С другой стороны, scrum делит работу на серию итераций фиксированной длины, называемых спринтами; все, что запланировано на спринт, является главным приоритетом команды (например, определенная функция или группа функций). Команды разработчиков с четкой дорожной картой и приоритетными кусками работы обычно получают наибольшую выгоду от scrum.
Но, может быть, ваша команда выиграет больше всего от комбинации scrum и kanban? Или хочет перейти от scrum к kanban? Если это походит на вашу команду,то это решение scrumban. Эта смешанная методология проявляется по-разному, но наиболее распространенные тенденции среди команд scrumban включают использование спринтов с беклогом из scrum, а также лимиты WIP и время цикла от kanban. (Примечание: время цикла - это количество времени, необходимое для прохождения задачи через рабочий процесс команды.)
Что такое канплан?
Канплан представляет собой смешанную методологию для отработки Agile разработки программного обеспечения. Как и scrumban, он сочетает в себе черты как scrum, так и kanban. Kanplan идеально подходит для команд, которые хотят ухаживать за беклогом, но не хотят работать в спринте.
Почему kanban - это основа, а не строгая структура
Команда разработчиков Atlassian отвечает за платформу, используемую для сборки, тестирования и предоставления программного обеспечения Atlassian. Разработчики зависят от надежной инфраструктуры и быстрой непрерывной интеграции (CI - Continuous Integration). Четыре года назад это выглядело как 21 000 сборок в месяц. Сегодня это число превышает 150000 сборок в месяц.
Эта способность к масштабированию может объясняться ростом команды, переходом от Subversion к Git, автоматизированным тестированием и чем-то менее очевидным: решением перейти от scrum к kanban. Характер инженерных работ по сборке (например, специальные запросы, инциденты, инновационные работы) не вписывался в структуру scrum. Поэтому команда решила представить scrumban, который быстро превратился в kanban, потому что команде не нравилось работать со спринтами. Но, оказывается, kanban был не тем эликсиром, на который они надеялись. Как и многие команды, они пытались заставить его работать. Они переходили от одной доски к нескольким: доска поддержки инженеров, рабочая доска проекта и другие, все с разными рабочими процессами. Но их самая большая болевая точка на всех досках? «Пустошь», как выразился один из членов команды, состоит из нерешенных задач, которые необходимо перевести в режим готовности к работе. Когда-то в колонке "В разработке", команде было хорошо идти, но их колонка "Сделать" - колонка пустоши - была просто пустошью.
Превратите свой список дел в список необходимых требований (backlog)
Наша инженерная команда по сборке пыталась бороться с их длинным и неорганизованным списком дел с помощью ежедневных летучек и еженедельных совещаний по планированию. Но что им действительно нужно, так это список необходимых требований (backlog), а не новые встречи.
Поскольку доски kanban традиционно не имеют функциональности списка необходимых требований (backlog), менеджеры по продуктам, менеджеры по разработке и руководители команд используют задачи в первом столбце для планирования. По мере того, как этот список расширяется, задачи трудно увидеть и расставить приоритеты по ним. Инженерная команда по сборке разделила свои доски на основе разных областей работы, но объединенная доска команд осталась подавляющей (требуется много прокрутки). Это разделяет доску kanban на два разных экрана; список необходимых требований (backlog) для ухода за списком необходимых требований (backlog) и доска kanban для команды инженеров для выбора и перемещения задач в рабочем процессе.
Эта функциональность ничем не отличается от беклога доски scrum в программном обеспечении Jira. Например, когда вы щелкаете по значку списка необходимых требований (backlog) на боковой панели, вы переходите к широкому столбцу списка необходимых требований (backlog) задач. После ухода за вашим списком необходимых требований (backlog) вы можете перетаскивать вопросы на следующий этап рабочего процесса.
Эта комбинация экрана списка необходимых требований (backlog) из scrum и доски kanban в одну Agile доску функционирует как список необходимых требований (backlog) доски scrum. Когда вы нажимаете на задачу, появляется подробное представление задачи. Сфокусированные обзоры, такие как детальный обзор задачи, позволяют каждому члену команды выполнять задачи быстрее и с меньшим количеством отвлекающих факторов.
Наконец, для тех не- scrum команд, которые используют эпики и предварительно назначенные версии для организации своих релизов, они могут воспользоваться инструментами, найденными на scrum-досках, как просмотр или быстрое редактирование. Это простое и быстрое редактирование дает менеджерам по продуктам, менеджерам по разработке и всем, кто работает в режиме планирования, возможность эффективно управлять эпиками и версиями.
Хотите добавить бэклог на свою доску kanban?
ХОТИТЕ ПОПРОБОВАТЬ?
Выберите вариант развертывания (облачный или серверный), а затем выполните одно из следующих руководств, чтобы включить список необходимых требований (backlog) в своем проекте kanban:
- Включить kanplan в облаке
- Включить kanplan на сервере
Kanplan предназначен, как сказал один клиент, для того, чтобы принести вам «лучшее из обоих миров». Вы можете перемещать карты без наличия спринта в процессе и вводить задачи в список необходимых требований (backlog), чтобы помочь вам лучше планировать. Он удаляет пустошь, которую испытала инженерная команда по сборке в Atlassian, и дает командам kanban режим планирования, которого раньше не было в мире kanban. Кроме того, он по-новому показывает ведущим проекта, как выполнять работу для команд, которые не чувствуют себя kanban, scrum или scrumban, и дает им основу, необходимую им для работы, которую они хотят выполнить. Открыв режим планирования на доске kanban, новые и старые команды kanban могут найти способы заставить эту Agile структуру работать вместо того, чтобы пытаться следовать передовым практикам, которые могут не применены к их команде. Помните: Agile разработка - это постоянное улучшение по сравнению с лучшей практикой.
По материалам Agile Coach "Kanplan"