Современные команды разработчиков программного обеспечения, по крайней мере, в своих процессах, более гибки! Они готовы думать вне установленных параметров, чтобы следовать тому, что работает для них. Они стремятся изучить и освоить новые методы управления проектами и проектными процессами.
Метод управления проектами под названием Kanban уже несколько лет активно работает в индустрии программного обеспечения, и за последние пять лет приобрел популярность. Вместе с гибкими методологиями принятие метода Канбана дало компаниям много поводов для радости.
Но есть также критика, что Kanban - не что иное, как прославленный список дел. Так о чем это все? Давай выясним.
Что такое канбан?
Если ваша компания готова выйти за рамки традиционного подхода к управлению программными проектами, сегодня нет недостатка в методах управления проектами.
Например, система Agile Project Management, которая фокусируется на нелинейных итерационных методах разработки программного обеспечения. Использование гибких методов очевидно в Scrum, который фокусируется на более гибком подходе к управлению проектами.
Agile также имеет ссылки на другие структуры управления проектами, такие как Kanban и Extreme Programming. Из них Канбан достиг большой популярности. В конце концов, кто не хочет, чтобы процесс развивался японцами?
Kanban - это концепция, которая развилась на заводе-изготовителе Toyota, чтобы обеспечить производство точно в срок (JIT), которое сокращает затраты и позволяет меньше использовать ресурсы. По сути, он следует принципу «тянуть», то есть задачи или продукты должны «тянуться» требованиями и спросом, а не «выталкиваться» сверху вниз. Он был разработан для обеспечения лучшего хранения автомобильных компонентов на заводах Toyota в зависимости от спроса. Это означало, что по мере роста спроса запросы будут удовлетворяться.
Концепция была адаптирована к индустрии программного обеспечения с небольшими изменениями Дэвида Андерсона в его книге 2010 года Kanban . С тех пор он был использован для различных проектов с большим успехом. Это может оказать огромную помощь в сложных проектах, которые могут пострадать от перегрузки на одной стороне цикла разработки.
По сути, система Kanban рассматривает процесс разработки программного обеспечения как конвейер. Допустим, программный процесс имеет три типа задач: анализ, разработка, тестирование и, наконец, развертывание. Допустим, есть двадцать задач, которые необходимо выполнить.
В случае традиционной системы управления проектами, если, например,
- Всего 25 историй
- Аналитики могут справиться с пятью историями в неделю
- Разработчики могут обрабатывать пять историй в неделю
- Тестеры ограничены тремя историями в неделю
В этой ситуации работа просто накапливается в конце тестеров. В конце недели 1 ситуация будет выглядеть следующим образом:
- Только три истории перешли к развертыванию.
- Разработчики и аналитики работают над тремя историями, так как тестировщики не могут взять результаты разработчиков и протестировать их.
- Работа накапливается, оставляя разработчиков, аналитиков и менеджера проекта в затруднительном положении.
Аналитики и разработчики теперь могут просто теребить свои пальцы! Или их менеджер может понять, что они бездействуют и перераспределить их в другой проект, где может возникнуть аналогичная ситуация. Итак, есть два проекта, которые сейчас застряли на этапе тестирования!
Проблемы в такой ситуации не трудно увидеть. Какой смысл в разработке десяти историй (или кусочков программного обеспечения), когда они не будут тестироваться в ближайшее время?
Теперь перейдем к методу Канбана.
Метод Канбана - чрезвычайно простая концепция. Он следует простой логике использования «метода извлечения», чтобы сначала устранить узкие места, и ограничить число незавершенных работ (WIP) для улучшения рабочих процессов.
В своей простейшей форме Kanban, буквально «визуальная доска», помогает «вытягивать» элементы из списка дел, а не работать с временными рамками. Метод Канбана помогает выявить узкие места, чтобы процесс управления был лучше управляем.
Базовая доска Канбан имеет список задач, которые необходимо выполнить, выполняемые задачи и выполненные задачи.
Однако в управлении программным обеспечением задачи могут быть немного более сложными. Большинство Agile проектов также имеют похожую доску. На доске Канбан четко обозначены этапы развертывания, а также номер для каждого столбца. Это число представляет собой максимальное количество задач или историй, которые может выполнить определенный шаг.
Наш пример на доске Kanban будет выглядеть примерно так в начале второй недели. Это означает, что разработчики и аналитики не будут работать над оптимальным количеством историй на этой неделе. Было бы очевидно, что работа накапливается в конце тестера. И организации могут обеспечить совместную работу команд для проведения тестирования. Кроме того, они могут посмотреть на другие модели потока процессов, чтобы этого не произошло.
Когда проекты обрабатываются через систему Kanban, становится меньше возможностей для накапливания работы. Истории принимаются в соответствии с максимальной доступной пропускной способностью.
В типичной конфигурации Kanban работа будет выполняться в соответствии с доступной пропускной способностью, а работа будет выполняться командами, чтобы они всегда были максимально загружены. Система также позволяет ускорить выполнение срочных задач, чтобы они перемещались по доске с минимальными усилиями.
Взгляните на эту доску Канбан.
Понятно, что все шаги работают с максимальной эффективностью. И задача, которая находится на «ускоренном пути», также учитывается.
Kanban ни в коем случае не единственный метод, используемый для повышения эффективности путем ограничения WIP. Существуют и другие системы, которые достигают того же результата, например, системы CONWIP (постоянная работа в процессе) и DBR (барабан-буферная веревка), которые в первую очередь предназначены для обрабатывающей промышленности.
Тем не менее, Kanban - это система, которая была наилучшим образом модифицирована для соответствия индустрии программного обеспечения.
Чем Канбан отличается от гибких методологий?
В основе Kanban лежит методология, в которой используются некоторые элементы Agile Project Management. Многие проекты в Agile-среде имеют корни в Lean-подходах. Разница между методологией Kanban и гибким управлением проектами не столь черно-белая, как сторонники этих двух методов, заставили бы нас поверить. У них больше общего, чем различий.
Гибкая структура не является абсолютной. Вопрос не в том, являются ли команды гибкими или нет. Команды часто имеют ловкость в различной степени. Одним из способов повышения гибкости процесса разработки программного обеспечения является использование Kanban.
Существует несколько различий между методиками Kanban и Agile. Некоторые особенности разработки Kanban, которые немного отличаются от Agile:
- Сроки не являются значимым фактором . Это сложная концепция, чтобы обернуть голову, так как она кажется не интуитивной. «Как вы работаете без сроков?» Часто спрашивают люди. Но если каждый член команды задействован с максимальной эффективностью, время перестает быть фактором.
- Истории (задачи) больше, чем в типичных Agile системах. Как правило, длина и сложность историй больше, чем в типичном проекте Scrum. Поскольку основное внимание уделяется не оценке времени, а просто продвижению процесса, Канбан может позволить себе работать над более крупными историями.
- В существующих процессах нет существенных изменений. Принципы Kanban для разработки программного обеспечения, сформулированные его основателем Дэвидом Андерсоном в своем блоге, включают в себя следующие основные принципы:
-
- Начните с того, что вы делаете сейчас
- Согласитесь проводить постепенные, эволюционные изменения
- Уважайте текущий процесс, роли, обязанности и названия
- Каждая история измеряется во времени цикла . Проект оценивается не традиционным быстрым вычислением скорости (количество историй, выполненных за заданное время), а временем цикла. Это означает, что Канбан делает акцент на том, сколько времени потребовалось для выполнения задачи. На многих канбан-досках часто можно увидеть тикер, в котором указано, сколько дней команде требуется, чтобы закончить рассказ. Эта оценка входит в следующий цикл.
Канбан: доска, но что еще?
Итак, Канбан - это доска, которая показывает нам, как устроены истории - многие даже спрашивают, что такое большое дело. На самом деле, существует много дискуссий о том, что может и может сделать Канбан.
Является ли Kanban просто методом управления рабочим процессом? Или это то, что можно использовать вместе с Agile методологиями для максимальной эффективности? Или это может быть совершенно новый способ управления рабочим процессом?
Каждая команда использует Kanban по своему усмотрению для своей конкретной ситуации. Несмотря на это, Kanban обладает потенциалом работать как образ жизни для разработки программного обеспечения, если использовать его до оптимального уровня.
Используется ли он для управления рабочим процессом или как новая парадигма в разработке программного обеспечения, нельзя отрицать, что он помогает управлять WIP.
Чтобы заставить Kanban работать лучше всего, важно думать об этом не просто как об управлении WIP, но как о структуре управления проектом. Определенные базовые рекомендации помогут этому процессу.
- Оптимизируйте команды так, чтобы ни одна команда не начинала то, что они не могли закончить. Это помогает процессу вместе.
- Не сопротивляйтесь изменениям оригинальной системы Kanban. Если ваш проект будет успешным с сроками и сроками, включите их так же, как и вы. Это создает более здоровую и надежную среду разработки.
- Не избегайте командной работы. Канбан может показаться, но не моделью, основанной на людях, работающих в изоляции. Командная работа должна быть неотъемлемой частью разработки программного обеспечения Kanban.
- Думай нестандартно Подумайте об изменениях в рабочем процессе. Многие команды в настоящее время выбирают разработку через тестирование с помощью приемочной разработки, где приемочные тесты сначала выполняются с использованием сценариев использования, которые затем определяют необходимые функции и характер разработки.
Гибриды
Поскольку все больше и больше компаний используют инструменты управления проектами, наиболее подходящие для их конкретной ситуации, неудивительно, что две из лучших методологий управления проектами: Scrum и Kanban, были успешно интегрированы.
Гибрид, названный Scrumban, проникает во многие проекты.
Если организация уже использует Scrum, но ей трудно держать проект вместе, либо из-за неэффективного спринта, либо из-за того, что тестирование не является герметичным, возможно, пришло время рассмотреть Scrumban.
Чтобы объяснить это просто, Scrumban вовлекал увеличение лупы к спринтам. Это касается не только спринтов как части проекта, но и того, что происходит внутри спринтов. Scrumban помогает понять, как история обрабатывается в спринте, и это может иметь все значение.
Scrumban, или любой из его вариантов, является минимальным изменением от существующих практик. Прелесть использования Kanban в том, что его можно использовать практически с любой моделью управления проектами: водопад, Agile или что-то среднее.
Начало работы с Kanban
С системой Канбан легко начать. Также возможно минимально реализовать Kanban в качестве пробной версии для определенной части проекта.
- Составьте план процесса разработки программного обеспечения. Составьте четкую карту всего процесса. Как проект - от первоначального проекта до разработки, тестирования, изменений в функциях - работает в реальности?
- Перечислите шаги, где будет использоваться Kanban. Используйте шаги, которые полностью под вашим контролем. Обычно это этапы анализа, разработки, анализа и тестирования.
- Работайте над важными моментами, такими как:
- Ограничения на незавершенное производство для каждого шага.
- Процессы для ускоренной / заблокированной работы
- Оценки за пределами конверта относительно времени цикла
- Частота рассмотрения Канбанской доски / процесса / оценки
- Купите доску и стопку заметок Post-It.
- Начать
- Просмотрите по мере необходимости.
- Повторение
Так что, давай, и начать на Канбан!
Не пугайтесь, если все пойдет не так, как вы хотели изначально. Вся идея гибких методологий заключается в том, чтобы учесть изменения в людях и процессах! Сообщите нам о своем опыте использования метода Канбан.
Рекомендуемые статьи
- 6 Best Helpful A Управление проектами (PMO)
- 8 полезных шагов для создания сложных карт-историй для вашего проекта
- 5 важных ценностей экстремального программирования (мощного)