Вы знакомы со Scrum, верно? Думаю, да, учитывая, что в Scrum Alliance насчитывается более 400 000 членов, и большинство из них успешно используют его в своих организациях.
Но это не единственный способ гибкого создания программного обеспечения - серьезно! Вы слышали о Канбан?
Для небольшого количества исходной информации, он был первоначально применен к бережливому производству как способ визуализации ввода и вывода работы, когда она проходила через фабрику. Эта визуализация была представлена на доске, известной как «жди его», Канбан. Совсем недавно и более уместно для вас, он был принят в качестве метода управления разработкой программного обеспечения.
Изначально описанный неврологом Дэвидом Дж. Андерсоном, это способ организации разработки и планирования программного обеспечения, который позволяет выявлять проблемы процесса и последовательно вносить ценные улучшения в ваш продукт - что, я знаю, звучит идеально. Проще говоря, в любой момент времени вы можете видеть, где находится работа (представленная карточками) в процессе разработки.
Как это устроено
Основная доска Kanban использует шесть столбцов, которые показывают, где каждая часть работы находится в цикле разработки продукта. Примерный пример того, как он выглядит, приведен ниже.
Посмотрите этот пример доски Канбан на Trello.
Колонка 1: отставание
Столбец «Журнал невыполненных работ» должен содержать список идей, ошибок или потребностей бизнеса по приоритетам. Карта еще не должна содержать тонну деталей, но она должна иметь достаточно информации, чтобы члены вашей команды понимали, почему это важно.
Колонка 2: Планирование
В этой колонке менеджер продукта заполняет спецификацию для функции, встречаясь с заинтересованными сторонами, инженерами и дизайнерами. Когда он будет готов, он или она переместит его в столбец «Готов к проектированию».
Колонка 3: Готов к проектированию
На этом этапе все карты должны иметь подробные спецификации. Хотя у вас все еще могут быть вопросы по техническим деталям, бизнес-требования должны быть ясными.
Колонка 4: Выполняется
Вы можете в любой момент переместить карту в «В процессе». Эта управляемая собой система «тяги» создает культуру личной ответственности и любопытства.
Колонка 5: Тестирование
Когда вы закончите работу с картой, переместите ее в «Тестирование», где другой инженер (или кто-то из команды QA) подберет ее.
Колонка 6: развернуто
Другой определяющей особенностью является то, что работа должна постоянно доставляться в промежуточную или производственную среду. Этот столбец позволяет любому члену команды увидеть, какая работа была выпущена недавно.
Преимущества и компромиссы
Когда вы выбираете между Kanban и более распространенной методологией, такой как Scrum или Waterfall, помните о следующих преимуществах и проблемах:
Преимущество: улучшает сотрудничество
В некоторых командах разработчиков, с которыми я работал, инженеры были специалистами. В каждой команде будет пара фронтенд-инженеров и бэкэнд-инженеров. Это означало, что работа часто блокировалась, потому что инженер был занят чем-то другим.
Канбан, с другой стороны, ограничивает незавершенную работу и препятствует блокированию. Каждый член команды может работать только над одним элементом за раз, и любой, кто не занят, может извлечь работу из верхней части столбца «Готовность к проектированию». Это поощряет инженеров-универсалов и сотрудничество между членами команды.
Увеличьте выгоду: не позволяйте вещам пройти, пока они не будут готовы
Канбан работает только тогда, когда вы ждете, чтобы переместить карты в следующий столбец, пока они не будут полностью закончены. (Бонус: это значительно минимизирует дефекты.)
Задача: обескураживает время на размышления
По умолчанию нет спринтов с временными рамками с четкими целями, целями даты и циклами выпуска. Вместо этого думайте о каждой карточке как о самостоятельной части работы, которую можно выполнить и выпустить в любое время.
С этим непрерывным потоком работы нет никакой опции «ждать до следующего спринта». Вам необходимо постоянно проверять доску, тянуть за следующий предмет и перемещать законченные предметы вниз по течению. Если вы не успеваете вовремя для ретроспективы и ожидания, членам команды может быть трудно поспевать за тем, как они работают.
Обойти это: брать то, что работает от Scrum
Я использовал ежедневные приемы и ретроспективы с Канбаном и обнаружил, что они повышают ценность. Если есть регулярные встречи или шаблоны, которые работают для вашей команды, не меняйте их, чтобы догматически придерживаться Канбана. Запланируйте время, чтобы обсудить приоритеты и то, как они изменились, чтобы все знали, что происходит в цикле разработки продукта.
Преимущество: повышает прозрачность
Каждый разработчик должен проявить инициативу, чтобы переместить карту в столбец «Выполняется». Это означает, что в любой момент времени руководитель группы может посмотреть, кто занят, кто не занят, и как долго выполняется какая-то часть работы.
Когда производство замедляется или останавливается, Kanban позволяет точно понять, почему. Будь то из-за того, что у бизнес-группы нет приоритетов в списке невыполненных заданий, у команды продукта нет законченных спецификаций, у команды разработчиков медленнее, чем ожидалось, или у команды QA не было возможности что-то протестировать; узкие места очевидны.
Увеличьте выгоду: позвольте прогрессу быть публичным
Одним из преимуществ является то, что Kanban очень визуально. Даже нетехнические члены команды могут посмотреть на доску Kanban и сказать, где находятся части работы в процессе. Используйте это в своих интересах и позвольте достижениям команды сиять, поднимая вашу доску в общественном месте.
Задача: не допускает долгосрочного планирования
Беспокойство о сроках и оценках - не самое продуктивное использование вашего времени, поэтому вы можете оценить, что Kanban больше ориентирован на повседневную работу. Тем не менее, оно само по себе не обеспечивает систему для построения долгосрочного плана. Это может привести к тому, что вы будете время от времени работать над проектами, а не концентрироваться на чем-то одном в течение длительного времени. Трудно провести день в проекте A, затем день в проекте B, а затем переключиться обратно на проект A.
Обойдите это: используйте его, когда ваши приоритеты могут измениться
Каждый столбец на вашей доске не зависит от других, поэтому члены команды могут перемещать вещи в любое время. Это может раздражать разработчиков в настройках Scrum (где оценки спринта делаются заранее), но Kanban процветает в такой быстро меняющейся среде.
Каждый хочет быть более продуктивным, но может быть трудно попробовать что-то новое, если вы даже не знаете, с чего начать. Я нашел Kanban полезным и надеюсь, что вы также найдете его полезным для вашего личного рабочего процесса (или даже для всей вашей команды!).
Чирикать мне, если вы решите дать ему шанс!
