В процессах разработки, как и в других сферах деятельности, не всегда удается сразу «найти» правильный путь; вам часто приходится испытывать множество шипов.
Будущая жизнь продукта или услуги зависит от выбора подходящей методологии разработки.
Мы собрали 13 преимуществ внедрения Канбана для разработки программного обеспечения.
Что такое Канбан?
Давайте рассмотрим следующий пример, рассмотрев две ситуации.Первая ситуация – представим себе конвейерный завод в советское время, деятельность которого напрямую зависела от государственного плана.
В этом плане четко определялось количество производимой продукции.
В результате склады были переполнены из-за того, что государственные планировщики часто могли ошибаться со спросом.
Времени продавать продукцию не было.
Вторая ситуация – Сегодня автосалон Toyota. Покупатель выбирает модель и производит оплату.
Однако в настоящее время у Toyota нет на складе автомобиля вашего цвета.
Заказ отправляется в головной офис Toyota. Вам сообщают, когда будет доставлен автомобиль.
Только с этого момента автомобиль начинают производить.
Специально для Вас.
Принцип очевиден: сначала продажа, потом производство.
Другими словами, принцип «точно в срок» работает. точно в срок (JIT) .
Сначала цели и сроки, потом план и работа.
Склады Toyota не будут затоварены, как в первой ситуации, и им не придется долго хранить готовые детали.
Это потому, что то, что сейчас производится на конвейере, является обязательным стандартом для какого-то недавно проданного автомобиля.
Одним из ключевых компонентов принципа JIT является Канбан .
Канбан-доски и карточки подобны светофорам в системе «точно вовремя».
Канбан позволяет бизнесу реагировать на потребности клиентов, а не прогнозировать потребности, как это произошло в первой описанной ситуации.
Аналогичный пример можно применить к области разработки программного обеспечения:
Вместо запчастей — задачи на разработку или баги.
Тестировщик получает несколько заданий для проверки.
Когда у QA заканчиваются задачи проверки, он должен уведомить программистов, чтобы получить от них новые задачи.
Если программисты не успевают выполнять новые задачи, тестировщик просто остается на какое-то время без работы.
Бывает и обратная ситуация: у QA накопилось много задач и он не успевает все проверить вовремя.
В этом случае дата выпуска продукта также задерживается.
В разработке программного обеспечения сбалансировать Канбан гораздо сложнее, чем в производстве.
Сказывается специфика работы: если машины производят однотипные детали, то программисты работают с кодом собственными усилиями мозга, в котором около 100 миллиардов нейронов и один, но существенный, человеческий фактор.
Зачем разработке программного обеспечения нужен Канбан?
Я открыл для себя все преимущества Канбана в 2008 году, после чего использую Канбан-доски повсюду: от личного планирования, разработки и даже внедрения Канбана в керамической мастерской.
13 причин перейти на Канбан
Вот 13 причин, почему стоит внедрять Канбан в ИТ-компаниях, занимающихся разработкой программного обеспечения:1.Выявление узких мест
Переход на канбан-доски из обычных списков задач сразу показал нам узкое место: в столбце «Тестирование» скопилась большая очередь задач.Наш QA не справился с проверкой задачи.
Задания на рассмотрение он принимал с большой задержкой.
После того как тестировщик вернул задачу на доработку, программист уже успел ее забыть.
Пришлось еще раз посмотреть код и вспомнить детали.
Как вы понимаете, это драгоценное время.
Команде нужен был еще один тестер.
Канбан-доска позволяет увидеть узкие места в вашем процессе, где образуются очереди.
Hygger.io поможет вам справиться с этой задачей лимиты незавершенного производства .
Если у вас задач больше или меньше, чем нужно, столбец выделяется красным или желтым цветом соответственно.
2. Точный порядок выпуска функций
Порядок выпуска функций часто имеет большое значение.В списках, основанных на приоритетах, сложно точно управлять порядком.
Если у программиста одновременно есть пять задач с высшим приоритетом, ему будет сложно разобраться, за какую из этих задач взяться в первую очередь.
Канбан-доски предлагают выход из ситуаций, когда порядок имеет значение.
Это визуальное решение представляет собой вертикальную колонку с задачами.
Чем выше задача, тем она важнее.
Канбан, кстати, предполагает расстановку приоритетов как один из важных аспектов методологии.
Требования постоянно меняются, многие задачи могут потерять актуальность и «пойти под откос».
Напротив, некоторые задачи могут резко «подняться».
Менеджер должен постоянно «держать руку на пульсе», чтобы программисты делали самое необходимое.
3. Приоритетность основных задач
Канбан учит концентрироваться на главном.Что действительно повышает ценность продукта.
Нам удалось «опустить» множество бесполезных ошибок и улучшений.
Это дало результаты.
Отличить важные ошибки от менее приоритетных — непростая задача для продакт-менеджера, но здесь ему на помощь приходит функция Дорожки для плавания .
Это горизонтальные столбцы на доске Канбан.
Как правило, у программистов на доске имеются следующие дорожки:
- Блокировщики — это задачи и ошибки, которые необходимо исправлять в режиме реального времени.
Пример — сломанная регистрация.
- Tasks and Bugs — регулярные текущие задачи и ошибки.
- Когда-нибудь — задачи, потерявшие по тем или иным причинам актуальность.
Важными и актуальными вопросами являются Блокеры.
Важные, но не срочные - Задачи и Баги.
Неважное и срочное, а также неважное и несрочное – это Когда-нибудь.
Кстати, отсутствие горизонтальных колонн является одним из факторов, подтверждающих Чего не хватает Trello для Agile-разработки? .
4. Концентрация на работе
Программист должен быть сосредоточен на своей работе.Поэтому хорошо, когда он получает очередь задач и ему не нужно думать, что делать дальше, об этом уже подумал руководитель.
Вам просто нужно взяться за очередное задание или ошибку.
Иногда в Канбане программисты самостоятельно выбирают какие-либо задачи из списка.
Тогда профессиональный уровень всех людей должен быть равным, чтобы самая сложная задача не «валилась» на младшего специалиста.
Фильтр Мои задачи помогает вам сосредоточиться на своих задачах.
Это поможет вам быстро увидеть свои задачи на доске.
5. Панорамный вид
Перед вашими глазами вся картина проекта.Открыв доску, вы сможете быстро получить ответы на важные вопросы:
- Кто чем занимается в данный момент?
- Что будет дальше в работе каждого отдельного специалиста?
- Какие задачи были переоткрыты из-за ошибок?
- Кто без задач?
- У кого большая очередь задач?
- Где произошли какие-либо изменения за последние 24 часа?
- Когда будет выполнена конкретная задача?
- Как быстро конкретный специалист справится со своими задачами?
- Какие задачи уже заняли больше времени, чем планировалось?
6. Гибкость
Канбан помогает вам стать более гибким.Это особенно необходимо, когда продукт выходит в свет и получает много полезных отзывов.
Это сообщения поддержки, поведенческая аналитика, результаты A/B-тестирования, обзоры и т. д. Как только мы загружаем новую функцию в продакшн, мы сразу же начинаем ее изменять на основе отзывов.
Раньше программист не хотел делать «левые» задачи, опасаясь «пропустить» сроки спринта.
Согласно Канбану, программист работает как процессор: один такт — одна задача.
Чем чаще галочки, тем более гибкой становится команда разработчиков.
Для нашей команды идеальное время выполнения — 8-12 часов.
Большие задачи необходимо декомпозировать.
7. Не нужно оценивать возможности
Скраму потребовалось много времени, чтобы оценить фичи перед началом спринта.С Канбаном нет необходимости в оценке.
Когда мы это сделаем, тогда это будет сделано.
8. Больше дел
Scrum предполагает много общения.Начало спринта сопровождается планированием: анализом и оценкой задач.
Стендапы обязательны каждую неделю.
После окончания спринта проводится ретроспектива.
В результате все общение занимает около 30% времени.
Но команда могла бы потратить это время на работу.
9. Командный дух
Благодаря Канбану команда начинает работать более слаженно.Сейчас тестировщик проверяет фичу практически сразу после того, как ее сделал программист. То же самое и в других областях: дизайнеры, UX, редакторы, продажи.
Раньше QA проверял фичу не тогда, когда ее сделал программист, а через долгое время.
За это время программист успел забыть все на свете, включая детали этой задачи.
10. Совершить ошибку раньше – значит быстрее найти решение.
В Scrum мы выпускаем функции в производство только в конце спринта.
Примерно раз в 3 недели.
В Канбане — практически сразу после приемки тестировщиком.
Раз в несколько дней.
Так мы быстро узнаем, дошла ли функция до пользователей или нет. Если нет, то где-то была ошибка.
И нам важно первыми совершать ошибки.
Это не значит, что мы любим совершать ошибки.
Но если мы первые узнаем об ошибке, мы первыми узнаем и решим, что делать.
11. Больше потока
Не нужно постоянно «дергать» программистов.Открыли Канбан-доску, быстро посмотрели, кто чем занимается, все статусы, и можно легко вернуться к управлению.
А программист продолжает оставаться в состоянии потока и в ожидании взятия новых вершин.
12. Чем больше знаний, тем лучше для проекта
Раньше программисты не знали, чем занимаются их коллеги.Теперь с Канбаном программист, как и менеджер, может выйти к доске и посмотреть, что делают его коллеги.
Такая информация им нужна для координации совместных усилий по проекту.
13. Сосредоточьтесь на одной задаче
Раньше программист работал над несколькими задачами параллельно.Я мог выбрать задачу по настроению, а мог и вовсе забыть в понедельник то, что делал в пятницу.
Теперь ограничения WIP и панорамные виды разумно ограничивают программиста: он не может выполнять более одной задачи одновременно.
В заключение
Может показаться, что мы настаиваем на том, что Канбан лучше, чем Скрам.Но это неправда.
Всему свое время.
Опыт Хиггер позволяет нам сказать: Scrum хорошо подходит в начале разработки продукта, а Kanban хорошо подходит, когда продукт уже вышел на арену.
Канбан — не панацея для каждого бизнеса.
Если вы приставите лестницу не к той стене, то, как бы круто вы ни поднимались по ней, вы все равно окажетесь не в том месте.
Поэтому Канбан — необходимое, но недостаточное условие успеха продукта или проекта.
Теги: #kanban #agile #Управление проектами #Управление задачами #Управление разработкой #Управление проектами #Управление продуктом
-
[Covid-19] Ваша Задача – Сгладить Пик
19 Oct, 24 -
Хабрафутбол-4: Старт
19 Oct, 24
