Спринты
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы.
Просмотр тем
Что такое спринты?
Спринт — это короткий временной интервал, в течение которого scrum-команда выполняет заданный объем работы. Спринты лежат в основе методологий scrum и agile, и правильный выбор спринтов поможет вашей agile‑команде выпускать более качественное программное обеспечение без лишней головной боли.
«При использовании scrum продукт разрабатывается в ходе нескольких итераций с фиксированной продолжительностью, которые называются спринтами и разбивают большие сложные проекты на небольшие задачи», — говорит Меган Кук, менеджер группы товаров для Jira Software в Atlassian.
Многие ассоциируют Scrum-спринты с Agile-разработкой программного обеспечения настолько часто, что Scrum и Agile принимают за синонимы. Однако это не так. Agile — это набор принципов, а Scrum — методика для активного решения задач.
Многочисленные сходства между глобальными задачами agile и процессами scrum вполне справедливо приводят к тому, что эти два понятия ассоциируются друг с другом. Благодаря спринтам команды могут следовать agile‑принципу «частой поставки рабочего программного обеспечения», а также реализовать agile‑задачу «реагирования на изменения в соответствии с планом». Установки scrum — прозрачность, проверка и адаптация — дополняют agile‑методику и играют главную роль в концепции спринтов.
Руководство по Scrum закладывает прочную теоретическую основу для обсуждения спринтов. Мы хотим внести немного красок в эту тему и делимся рекомендациями от людей, которые занимаются этой работой каждый день.
Как планировать и выполнять спринты в scrum
Авторы Scrum действительно все предусмотрели. Чтобы запланировать предстоящий спринт, нужно провести собрание по планированию спринта. Планирование спринта — это мероприятие, на котором команда сообща отвечает на два основных вопроса: какую работу можно выполнить в этом спринте и как она будет выполняться?
Выбором подходящих рабочих задач для спринта занимаются совместно владелец продукта, Scrum-мастер и команда разработчиков. Владелец продукта определяет цель спринта и задачи из бэклога продукта, при выполнении которых она будет достигнута.
Затем команда создает план, согласно которому будут выполняться задачи бэклога, чтобы к окончанию спринта вся работа была завершена. Выбранные рабочие задачи и план по их выполнению называется бэклогом спринта. К концу совещания по планированию спринта команда готова приступить к работе. Для этого необходимо просто выбирать задачи из бэклога спринта и менять их статус с «В работе» на «Готово» по мере завершения работы.
В течение спринта команда собирается на ежедневные Scrum‑совещания (стендапы), чтобы обсудить ход работы. Такие совещания нужны, чтобы выявить блокеры и проблемы, которые могут повлиять на достижение цели спринта.
По окончании спринта команда показывает выполненную работу на обзоре итогов спринта. Здесь можно продемонстрировать итоги работы заинтересованным сторонам и другим участникам команды до того, как они попадут в рабочую среду.
Завершите цикл спринтов на моем любимом собрании — ретроспективе спринта. Здесь команда может определить области, требующие улучшения в следующем спринте. С этими сведениями можно начинать следующий цикл спринта. Вперед!
Что стоит и не стоит делать
Даже если основы уже известны, большинство команд спотыкается в начале работы со спринтами. Меган Кук завершает эту дискуссию списком действий, которые стоит и не стоит делать при использовании спринтов, которые она сформулировала за годы своей работы.
И если уж вы работаете над тем, чтобы стать сильным специалистом по scrum, выполняя рекомендации, ознакомьтесь также с действиями, которые выполнять не следует.
Чего не стоит делать.
Оптимизируйте спринты с помощью автоматизации
Когда вы поймете, как работают спринты, вы сможете оптимизировать процессы, используя автоматизацию. Вот три правила автоматизации, которые часто используются в спринтах Jira.
Эти и сотни других правил автоматизации можно найти в библиотеке шаблонов Jira Automation.
Подробнее о спринтах
Спринты настолько известны (и настолько эффективны), что их часто считают первым шагом на пути к повышению гибкости. Но мы выяснили, что для освоения спринтов необходимо овладеть некоторыми взаимосвязанными понятиями Scrum и Agile. Изучите остальные статьи по Scrum, чтобы расширить знания и стать еще на шаг ближе к счастью от использования Scrum.
Scrum и Agile для чайников
Комментарий Котиков
Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.
На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.
Эджайл и скрам помогают организовать процесс работы в команде так, чтобы выпускать интересный пользователю продукт регулярно и часто.
В некоторых банках путь идеи к пользователям благодаря эджайлу сократили с двух лет до шести месяцев — в других компаниях шесть месяцев цикла разработки сжались в три. В наше суматошное время это истинное конкурентное преимущество, особенно для малых игроков.
Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?
Кое-что из эджайла и скрама можно взять даже в индивидуальную работу. Обеспечить регулярную публикацию постов, отмерять нагрузку на исполнителя, оценивать будущие задачи по времени и не забывать анализировать качество проделанной работы — смотрите, за нас уже всё придумали. Осталось внедрить.
Эджайл
(англ.agile —«проворный, шустрый, сообразительный»)
Концепция гибкости:
Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.
«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?
Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете
Скрам
(англ. scrum — толкотня в борьбе за мячик в регби)
Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.
Жесткость скрама заключается в структуре. Есть некий набор подходов, работающих вместе лучше, чем по отдельности. Вытащить что-нибудь и заиспользовать вам, я надеюсь, никто не запретит.
Обычно скрам происходит там, где есть некий продукт, имеющий ценность для пользователей и заказчиков, и нужно как можно быстрее на пути к цели понимать, в том ли направлении мы сейчас бежим — или надо корректировать курс. Формат скрама позволяет выпускать очередную версию чаще, регулярно получать обратную связь и быстро дорабатывать продукт, а также — улучшать процесс работы.
Если вы работаете в команде, скрам предписывает всем участникам процесса стремиться к взаимозаменяемости, к способности «подхватить» провисающую задачу, если сосед заболел, к обмену навыками и коллективной ответственности за продукт. Индивидуализма в скраме мало. Решения принимаются коллективно (по строгим принципам), никто не может надавить и заставить выбрать другое решение, если команда уверена, что остановилась на верном.
Поэтому даже если мы все уверенно побежали в неправильном направлении, у нас будет в конце спринта возможность его скорректировать и починить то, что нас направляет не туда. Команда в скраме самоорганизующаяся и самонастраивающаяся.
Команда в скраме
Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.
В каждой команде есть:
Устройство спринт
Работа в скраме состоит из спринтов. Все спринты устроены одинаково. Предполагается, что с каждым следующим спринтом команда становится всё сыграннее и эффективнее. В скраме учишься на своих ошибках, но быстро — каждый спринт анализируешь, что именно натворил и как хочешь это исправить.
У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.
В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.
Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.
В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.
Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.
В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.
Результатом спринта всегда является что-то, что можно показать. Показывает работу команда на демо в конце спринта.
На мой взгляд, скрам-процесс похож на работу над коллективным блогом. Такой процесс помог бы соблюсти регулярность, свести воедино экспертизу авторов и не набирать столько, что не успеешь сделать.
Структура спринта
Спринт начинается с планирования: команда садится и обсуждает: вот эту идею берем, вон ту не берем. В IT этот процесс может затягиваться на пару часов, потому что обсуждение идет вплоть до деталей. В случае работы с блогом это может превратиться в обсуждение тем и плана статей, которые потом останется сесть и написать — понимая, что пишем, когда и зачем.
Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.
Каждый участник стендапа по очереди отвечает на три вопроса:
Все завязывающиеся в процессе детальные разговоры уходят за пределы стендапа. Стендап — это точка, в которой можно поймать проблемы или узнать, что мы с коллегой почему-то делаем одно и то же одновременно, а значит — кто-то из нас может заняться чем-то другим.
Вообще поддержанием всех вот этих четких правил поведения должен заниматься скрам-мастер. Это обычно идеологи технологии, верящие в нее и готовые выстраивать процесс для максимальной эффективности проведенного вместе времени. Без скрам-мастера процессы выродятся в минимально возможные, потому что человек ленив и экономичен.
В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.
«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)
Как использовать Agile и Scrum для управления проектами
Agile и Scrum для руководителя проекта — основы гибких методологий, инструкция по ведению бэклога и спринтам, контроль процессов и организация работы.
Для чего внедрять гибкие методологии
Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.
Неожиданности появляются не только из-за бизнес-процессов, здесь работает и человеческий фактор. Например, представители заказчика могут намеренно затягивать внедрение ПО, преследуя личные цели. Сбор требований на этапе аналитики тоже не дает стопроцентной точности — заказчики не расскажут вам все сразу. Плюс сейчас ПО требует мгновенной реакции на отзывы пользователей — подход с долгой тщательной подготовкой не работает.
Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.
Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.
Начните с бэклога
Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.
Вместо проектного задания используется бэклог — список функций, требований к системе, желаний заказчика. В Scrum они сортируются по приоритету. Это живой документ, добавляйте в него новые задачи по ходу работы.
Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.
Не нужно прорабатывать и продумывать полностью все функции сразу. Все «хотелки» и то, что появляется в процессе, добавляются в бэклог. Решайте, что делать сразу, а что стоит отложить на следующую версию.
Внедряйте спринты
Scrum создавался в первую очередь для гибкости и ускорения разработки. Для этого появилась механика спринтов — весь процесс делится на отрезки, обычно от одной до четырех недель.
Как это работает? Команда забирает из бэклога часть задач. Каждая разбивается на максимально мелкие тикеты. Теперь нужно оценить время на задачу, и вот здесь проявляется особенность Scrum.
Дело в том, что люди плохо считают процессы в абсолютных величинах. Сложно сказать, сколько часов что займет. Поэтому в Scrum используется относительная оценка. За основу берется простая функция, которую все оценивают одинаково — например, понятно, что ее сделают за час. Остальные тикеты вычисляются так — «это мы будем делать раз в пять дольше по времени».
Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.
Ключевая идея — до тех пор, пока команда не забрала задачи на спринт, их можно бесконечно видоизменять в бэклоге. В разработку уходит согласованная часть. Каждый спринт — это небольшой релиз, в конце которого команда показывает работающую функцию ПО.
Распределите роли в команде
В идеальном мире на ключевые роли в scrum-команде назначаются люди, выращенные на проекте. Такой человек будет знать процессы изнутри, лучше ориентироваться в оценках и понятнее ставить задачи.
Cвязующее звено между командой разработки и пользователями. Этот человек собирает общую концепцию продукта из мнений заказчиков и других заинтересованных в выпуске ПО людей. Он формирует задачи и расставляет приоритеты.
Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.
Люди, которые непосредственно создают и тестируют код.
К разработчикам есть несколько требований:
У такого принципа формирования команды есть минус — сложно заменить неожиданно выпавшего человека. Но скорость разработки на практике все равно выше, чем у других подходов.
Контролируйте процессы
Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.
Контролируйте работу команды с помощью двух scrum-показателей:
Организуйте работу команды
В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:
Задача руководителя — выяснить и устранить трудности, которые мешают разработчику добиться прогнозируемого результата. Для сотрудников это три-пять минут — ответили на вопросы, поставили оценки, разбежались работать дальше. Никаких решений или дискуссий.
В конце каждого спринта проводится ретроспектива. Команда встречается, озвучивает мнение, что в отрезке было хорошо, что плохо. Спросите у сотрудников идеи — что поможет им работать быстрее и эффективнее, что исправит проблемы. Запишите их в отдельный план — забирайте туда только те идеи, которые возможно сделать за следующий спринт.
Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.
На следующей ретроспективе обсудите идеи из плана, отсортируйте их по категориям «плохо» и «хорошо». Повторите процесс — получается ретроспектива на ретроспективу.
Формируйте организацию процесса постепенно. Разбивайте день — например, шесть часов люди работают по спринтам, два часа остаются на срочные и случайные моменты. Если все пойдет без неожиданностей, ничего страшного, продолжайте спринт, сделайте больше тикетов.
Первый спринт команда всегда «факапит», потому что слишком оптимистично смотрит на дедлайны и задачи. Второй — берет очень мало задач и делает больше. Третий — снова плохая оценка, но уже чуточку лучше. Потом все выравнивается. Это рабочий процесс.
Демонстрируйте проект
Не затягивайте с первой версией продукта. Демонстрацию лучше проводить после каждого спринта — пусть даже релиз не пойдет к пользователям. Не копите внутри команды много функций — покажите их заинтересованным лицам и получите обратную связь. После — сразу измените бэклог.
В этом основное преимущество Scrum — гибко менять список задач во время разработки, не делать лишнего и не получать тысячи правок после завершения проекта, как в каскадной методологии разработки.
Изучите инструменты для контроля
Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:
Чек-лист — как начать использовать Agile и Scrum на проекте
Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.
Делает из вебинаров статьи, пишет про все и даже немного больше.
Agile/Scrume/Kanban как выравнивать процессы, максимизировать процессы
Материал подготовлен в рамках обучения Product University, январь, 2021
Для начала определим кто такой менеджер?
Менеджер — это человек производящий и управляющий потоками, для оптимизации производственной деятельности и достижения поставленных целей и результатов.
Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrume, Kanban. Чтобы иметь представления как работать с командой.
Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.
А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.
Подход к проектам по разработке ПО
• Гибкая методология разработки,
• Постоянное формирование требований на основе целевого видения продукта
• Короткие горизонты планирования (1-2 мес.)
• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля
• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Особенность реализации проектов
• Фиксированы срок и стоимость проекта.
• Лучший контроль качества – контроль результата каждой итерации
Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки
Scrum – самая популярная из гибких методологий разработки
Позволяет решать задачи
• с минимальными затратами.
РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.
Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.
ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.
По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.
Как максимизировать и выравнивать процессы?
На самом деле здесь уже все продумано, и придумать велосипед не нужно!
Используется всего четыре артефакта:
Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.
Это краткое описание того, ради чего выполняется данный спринт, цель на спринт помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.
Sprint Burndown Chart
Есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.
Ритуалы в скрам это:
Sprint Planning Meeting (встреча по планированию спринта)
Daily Meeting (ежедневная встреча команды).
Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.
Sprint Review – сдача спринта Product Owner
По завершению каждого спринта команда обязана провести демонстрацию полученного результат.
Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.
Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.
Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Kanban — это метод для разработки продуктов, который помогает наладить текущие процессы и не перегрузить команду. Незавершенные задачи не простаивают и потоком движутся по цепочке создания продукта или его поддержки.
Kanban используют для реализации проектов.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с «передовой» и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.
В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи
Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.