В процессах разработки, как и в других сферах деятельности, не всегда получается сразу «нащупать» верный путь, зачастую приходиться испытать множество терний. От выбора подходящей методологии разработки зависит будущая жизнь продукта или услуги. Мы собрали 13 преимуществ от внедрения Kanban для разработки программного обеспечения.
Разберем следующий пример, рассмотрев две ситуации.
Первая ситуация – представим конвейерную фабрику в советское время, деятельность которой напрямую зависела от госплана. Этот план четко определял количество продукции для производства. Как результат, переполненные склады из-за того, что составители госплана часто могли ошибаться со спросом. Продукцию не успевали продавать.
Вторая ситуация – шоурум Toyota в наши дни. Покупатель выбирает модель и вносит оплату. Однако на складе Toyota в этот момент нет вашего цвета автомобиля. Заказ отправляется в головной офис Toyota. Вам сообщают сроки, когда машина будет доставлена. Только с этого момента автомобиль начинают производить. Специально для вас. Налицо принцип: сперва продажа, потом производство. Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.
Складские запасы Toyota не будут переполнены, как в первой ситуации, у них не будет необходимости долго хранить заранее произведенные запчасти. Все потому, что то, что производится прямо сейчас на линии – это необходимая норма для какой-то недавно проданной машины.
Одной из ключевых составляющих JIT-принципа является Kanban. Доски и карточки Kanban – это своеобразные светофоры в системе just in time. Kanban дает возможность бизнесу быть реактивным по отношению к потребностям клиента вместо прогнозирования потребностей, как это случилось в первой описанной ситуации.
Можно спроецировать похожий пример на область разработки ПО:
Вместо запчастей — задачи на разработку или баги. Тестировщик получает несколько задач для проверки. Когда у QA заканчиваются задачи на проверку, он должен поставить в известность программистов, чтобы получить новые задачи от них. Если программисты не успевают закончить новые задачи, тестировщик просто остается на какое-то время без работы.
Случается и обратная ситуация: у QA скапливается очень много задач и он/она не успевает все вовремя проверять. В этом случае, срок выпуска продукта также откладывается.
В разработке ПО сбалансировать Kanban намного сложнее, чем на производстве. Сказывается специфики работы: если станки выпускают однотипные детали, то программисты работают с кодом собственными усилиями головного мозга, в котором что-то около 100 млрд нейронов и один, но весомый человеческий фактор.
Преимущества Kanban в полной мере я открыл для себя в 2008 году, после чего использую Kanban-доски везде: от личного планирования, разработки и даже внедрения Kanban в керамической мастерской.
Вот 13 причин, по которым стоит внедрять Канбан в IT компании, которые занимаются разработкой ПО:
Переход на Kanban доски с обычных списков задач сразу показал нам узкое место: в колонке Testing скапливалась большая очередь задач. Наш QA не справлялся с проверкой задач. Он брал задачи на проверку с большой задержкой. После того, как тестировщик возвращал задачу на доработку, программист уже успевал ее забыть. Приходилось снова смотреть код и вспоминать детали. Как понимаете, это драгоценное время. Команде потребовался еще один тестировщик.
Kanban доска позволяет увидеть узкие места в вашем процессе, где образуются очереди. В Hygger.io c этой задачей помогают справиться WIP лимиты. Если у вас больше или меньше задач, чем нужно — колонка подсвечивается красным или желтым цветом соответственно.
Часто большое значение имеет порядок выпуска фич. В списках, построенных на приоритетах, тяжело точно управлять порядком. Если у программиста будет одновременно пять задач с главным приоритетом, ему будет сложно сориентироваться, какую из этих задач взять в работу первой.
Kanban доска как раз предлагает выход из ситуации, когда порядок имеет значение. Это визуальное решение — вертикальная колонка с задачами. Чем выше задача, тем она важнее. Kanban, кстати, предполагает определение приоритетов, как один из важных аспектов методологии. Постоянно меняются требования, многие задачи могут терять актуальность и «спускаться» вниз. Какие-то таски могут наоборот резко «подняться». Менеджер должен постоянно «держать руку на пульсе», чтобы программисты выполняли самое нужное.
Kanban учит отдавать главное внимание главным вещам. Тому, что реально добавляет ценности продукту. Мы смогли «опустить» вниз множество бесполезных багов и доработок. Это дало результат.
Отличать важные баги от менее приоритетных – непростая задача для менеджера продукта, но здесь ему на помощь приходит функция Swimlanes. Это горизонтальные колонки на Kanban доске. Как правило, у программистов на доске присутствуют такие Swimlanes:
Система схожа с квадрантом Эйзенхауэра. Важные и срочные вопросы — это Blockers. Важные, но несрочные — Tasks and Bugs. Неважные и срочные, а также неважные и несрочные — это Someday. К слову, отсутствие горизонтальных колонок — один из факторов, подтверждающих чего не хватает Trello для Agile разработки.
Программист должен быть сконцентрирован на своей работе. Поэтому хорошо, когда он получает очередь задач и ему не нужно думать, что делать дальше, об этом уже подумал менеджер. Просто нужно брать в работу следующую задачу или баг.
Иногда Kanban предполагает самостоятельный выбор программистами любых задач сверху. Тогда профессиональный уровень всех людей должен быть равным, чтобы не получилось, что самая сложная задача «падает» на junior специалиста.
Фильтр My Tasks помогает установить фокус на свои задачи. Он помогает быстро увидеть свои задачи на доске.
Перед вашими глазами — вся картина по проекту. Открыв доску, можно оперативно получить ответы на важные вопросы:
Kanban помогает стать более гибкими. Это особенно нужно, когда продукт выходит «в свет» и получает много полезной обратной связи. Это сообщения в поддержку, поведенческая аналитика, результаты а/б тестирования, отзывы и т.д. Как только мы «заливаем» новую фичу на продакшн, сразу же начинаем ее менять на основе обратной связи. Раньше программист не хотел делать «левые» задачи, боясь «завалить» сроки по спринту. По Kanban программист работает как процессор: один такт — одна задача.
Чем чаще такты, тем команда разработки становится более гибкой. Для нашей команды идеальный такт составляет 8-12 часов. Крупные задачи обязательно декомпозируются.
Scrum забирал много времени на оценку фич перед стартом спринта. С Kanban потребности в оценке нет. Когда сделаем, тогда и будет сделано.
Scrum предполагает много коммуникации. Начало спринта сопровождается планированием: анализом и оценкой задач. Каждую неделю обязательны стенд-апы. После окончания спринта проводится ретроспектива. По итогу, вся коммуникация отнимает около 30% времени. А ведь это время команда могла бы потратить на работу.
С Kanban команда начинает работать более согласованно. Сейчас тестировщик проверяет фичу практически сразу после того, как ее сделал программист. Аналогично и в других областях: у дизайнеров, UX, редакторов, сейлзов.
Раньше же QA проверяли фичу не тогда, когда программист ее сделал, а спустя длительное время. Программист за это время успевал забывать все на свете, включая детали этой задачи.
В Scrum мы «заливаем» фичи на production только в конце спринта. Примерно раз в 3 недели. В Kanban — практически сразу после приемки тестировщиком. Раз в несколько дней.
Так мы быстрее узнаем, зашла фича пользователям или нет. Если нет — где-то произошла ошибка. А нам важно ошибаться первыми. Это вовсе не означает, что мы любители ошибаться. Но если мы узнаем об ошибке первыми, мы первыми будет знать и решать, что делать.
Не нужно постоянно «дергать» программистов. Открыли Kanban доску, быстро глянули кто и чем занят, все статусы, и спокойно можно вернуться к менеджменту. А программист продолжает оставаться в состоянии потока, и в предвкушении взятия новых вершин.
Раньше программисты не знали, чем заняты коллеги. Сейчас с Kanban программист может так же, как и менеджер зайти на доску и посмотреть, что делают коллеги. Такая информация нужна им для координации совместных усилий на проекте.
Раньше программист занимался сразу несколькими задачами параллельно. Мог выбрать таск по настроению, а мог и вовсе в понедельник забыть о том, чем занимался в пятницу.
Сейчас WIP лимиты и панорамный вид грамотно ограничивают программиста: он не может делать более одной задачи сразу.
Может показаться, что мы настаиваем на том, что Kanban лучше Scrum. Но это не так. Всему свое время. Опыт Hygger позволяет утверждать: Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.
Kanban — не панацея для любого бизнеса. Если вы приставили лестницу не к той стене, то как бы круто вы не поднимались по ней, вы все равно окажетесь не там, где нужно. Поэтому Kanban — необходимое, но не достаточное условие для успеха продукта или проекта.
Что такое Kanban?
Разберем следующий пример, рассмотрев две ситуации.
Первая ситуация – представим конвейерную фабрику в советское время, деятельность которой напрямую зависела от госплана. Этот план четко определял количество продукции для производства. Как результат, переполненные склады из-за того, что составители госплана часто могли ошибаться со спросом. Продукцию не успевали продавать.
Вторая ситуация – шоурум Toyota в наши дни. Покупатель выбирает модель и вносит оплату. Однако на складе Toyota в этот момент нет вашего цвета автомобиля. Заказ отправляется в головной офис Toyota. Вам сообщают сроки, когда машина будет доставлена. Только с этого момента автомобиль начинают производить. Специально для вас. Налицо принцип: сперва продажа, потом производство. Другими словами, работает принцип точно в срок just in time (JIT). Сперва цели и сроки, затем план и работа.
Складские запасы Toyota не будут переполнены, как в первой ситуации, у них не будет необходимости долго хранить заранее произведенные запчасти. Все потому, что то, что производится прямо сейчас на линии – это необходимая норма для какой-то недавно проданной машины.
Одной из ключевых составляющих JIT-принципа является Kanban. Доски и карточки Kanban – это своеобразные светофоры в системе just in time. Kanban дает возможность бизнесу быть реактивным по отношению к потребностям клиента вместо прогнозирования потребностей, как это случилось в первой описанной ситуации.
Можно спроецировать похожий пример на область разработки ПО:
Вместо запчастей — задачи на разработку или баги. Тестировщик получает несколько задач для проверки. Когда у QA заканчиваются задачи на проверку, он должен поставить в известность программистов, чтобы получить новые задачи от них. Если программисты не успевают закончить новые задачи, тестировщик просто остается на какое-то время без работы.
Случается и обратная ситуация: у QA скапливается очень много задач и он/она не успевает все вовремя проверять. В этом случае, срок выпуска продукта также откладывается.
В разработке ПО сбалансировать Kanban намного сложнее, чем на производстве. Сказывается специфики работы: если станки выпускают однотипные детали, то программисты работают с кодом собственными усилиями головного мозга, в котором что-то около 100 млрд нейронов и один, но весомый человеческий фактор.
Для чего разработке ПО нужен Kanban?
Преимущества Kanban в полной мере я открыл для себя в 2008 году, после чего использую Kanban-доски везде: от личного планирования, разработки и даже внедрения Kanban в керамической мастерской.
13 причин перейти на Kanban
Вот 13 причин, по которым стоит внедрять Канбан в IT компании, которые занимаются разработкой ПО:
1.Определение узких мест
Переход на Kanban доски с обычных списков задач сразу показал нам узкое место: в колонке Testing скапливалась большая очередь задач. Наш QA не справлялся с проверкой задач. Он брал задачи на проверку с большой задержкой. После того, как тестировщик возвращал задачу на доработку, программист уже успевал ее забыть. Приходилось снова смотреть код и вспоминать детали. Как понимаете, это драгоценное время. Команде потребовался еще один тестировщик.
Kanban доска позволяет увидеть узкие места в вашем процессе, где образуются очереди. В Hygger.io c этой задачей помогают справиться WIP лимиты. Если у вас больше или меньше задач, чем нужно — колонка подсвечивается красным или желтым цветом соответственно.
2. Точный порядок выпуска фич
Часто большое значение имеет порядок выпуска фич. В списках, построенных на приоритетах, тяжело точно управлять порядком. Если у программиста будет одновременно пять задач с главным приоритетом, ему будет сложно сориентироваться, какую из этих задач взять в работу первой.
Kanban доска как раз предлагает выход из ситуации, когда порядок имеет значение. Это визуальное решение — вертикальная колонка с задачами. Чем выше задача, тем она важнее. Kanban, кстати, предполагает определение приоритетов, как один из важных аспектов методологии. Постоянно меняются требования, многие задачи могут терять актуальность и «спускаться» вниз. Какие-то таски могут наоборот резко «подняться». Менеджер должен постоянно «держать руку на пульсе», чтобы программисты выполняли самое нужное.
3. Приоритет главным задачам
Kanban учит отдавать главное внимание главным вещам. Тому, что реально добавляет ценности продукту. Мы смогли «опустить» вниз множество бесполезных багов и доработок. Это дало результат.
Отличать важные баги от менее приоритетных – непростая задача для менеджера продукта, но здесь ему на помощь приходит функция Swimlanes. Это горизонтальные колонки на Kanban доске. Как правило, у программистов на доске присутствуют такие Swimlanes:
- Blockers — задачи и баги, которые надо править в режиме реального времени. Пример – сломанная регистрация.
- Tasks and Bugs – обычные текущие задачи и баги.
- Someday — задачи, которые потеряли актуальность по той или иной причине.
Система схожа с квадрантом Эйзенхауэра. Важные и срочные вопросы — это Blockers. Важные, но несрочные — Tasks and Bugs. Неважные и срочные, а также неважные и несрочные — это Someday. К слову, отсутствие горизонтальных колонок — один из факторов, подтверждающих чего не хватает Trello для Agile разработки.
4. Концентрация на работе
Программист должен быть сконцентрирован на своей работе. Поэтому хорошо, когда он получает очередь задач и ему не нужно думать, что делать дальше, об этом уже подумал менеджер. Просто нужно брать в работу следующую задачу или баг.
Иногда Kanban предполагает самостоятельный выбор программистами любых задач сверху. Тогда профессиональный уровень всех людей должен быть равным, чтобы не получилось, что самая сложная задача «падает» на junior специалиста.
Фильтр My Tasks помогает установить фокус на свои задачи. Он помогает быстро увидеть свои задачи на доске.
5. Панорамный вид
Перед вашими глазами — вся картина по проекту. Открыв доску, можно оперативно получить ответы на важные вопросы:
- Кто чем занят в данный момент времени?
- Что будет в работе дальше у каждого отдельного специалиста?
- Какие задачи были переоткрыты из-за багов?
- Кто находится без задач?
- У кого большая очередь задач?
- Где случились какие-либо изменения за последние сутки?
- Когда будет сделана конкретная задача?
- Как скоро закончатся задачи у конкретного специалиста?
- На какие задачи уже потрачено больше времени, чем было запланировано?
6. Гибкость
Kanban помогает стать более гибкими. Это особенно нужно, когда продукт выходит «в свет» и получает много полезной обратной связи. Это сообщения в поддержку, поведенческая аналитика, результаты а/б тестирования, отзывы и т.д. Как только мы «заливаем» новую фичу на продакшн, сразу же начинаем ее менять на основе обратной связи. Раньше программист не хотел делать «левые» задачи, боясь «завалить» сроки по спринту. По Kanban программист работает как процессор: один такт — одна задача.
Чем чаще такты, тем команда разработки становится более гибкой. Для нашей команды идеальный такт составляет 8-12 часов. Крупные задачи обязательно декомпозируются.
7. Не нужно оценивать фичи
Scrum забирал много времени на оценку фич перед стартом спринта. С Kanban потребности в оценке нет. Когда сделаем, тогда и будет сделано.
8. Больше дела
Scrum предполагает много коммуникации. Начало спринта сопровождается планированием: анализом и оценкой задач. Каждую неделю обязательны стенд-апы. После окончания спринта проводится ретроспектива. По итогу, вся коммуникация отнимает около 30% времени. А ведь это время команда могла бы потратить на работу.
9. Командный дух
С Kanban команда начинает работать более согласованно. Сейчас тестировщик проверяет фичу практически сразу после того, как ее сделал программист. Аналогично и в других областях: у дизайнеров, UX, редакторов, сейлзов.
Раньше же QA проверяли фичу не тогда, когда программист ее сделал, а спустя длительное время. Программист за это время успевал забывать все на свете, включая детали этой задачи.
10. Ошибаться раньше — быстрее находить решение
В Scrum мы «заливаем» фичи на production только в конце спринта. Примерно раз в 3 недели. В Kanban — практически сразу после приемки тестировщиком. Раз в несколько дней.
Так мы быстрее узнаем, зашла фича пользователям или нет. Если нет — где-то произошла ошибка. А нам важно ошибаться первыми. Это вовсе не означает, что мы любители ошибаться. Но если мы узнаем об ошибке первыми, мы первыми будет знать и решать, что делать.
11. Больше потока
Не нужно постоянно «дергать» программистов. Открыли Kanban доску, быстро глянули кто и чем занят, все статусы, и спокойно можно вернуться к менеджменту. А программист продолжает оставаться в состоянии потока, и в предвкушении взятия новых вершин.
12. Больше знаний – лучше для проекта
Раньше программисты не знали, чем заняты коллеги. Сейчас с Kanban программист может так же, как и менеджер зайти на доску и посмотреть, что делают коллеги. Такая информация нужна им для координации совместных усилий на проекте.
13. Концентрация на одной задаче
Раньше программист занимался сразу несколькими задачами параллельно. Мог выбрать таск по настроению, а мог и вовсе в понедельник забыть о том, чем занимался в пятницу.
Сейчас WIP лимиты и панорамный вид грамотно ограничивают программиста: он не может делать более одной задачи сразу.
В качестве заключения
Может показаться, что мы настаиваем на том, что Kanban лучше Scrum. Но это не так. Всему свое время. Опыт Hygger позволяет утверждать: Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.
Kanban — не панацея для любого бизнеса. Если вы приставили лестницу не к той стене, то как бы круто вы не поднимались по ней, вы все равно окажетесь не там, где нужно. Поэтому Kanban — необходимое, но не достаточное условие для успеха продукта или проекта.
Комментарии (12)
Throwable
20.03.2018 12:57Scrum хорошо подходит на старте разработки продукта, а Kanban — когда продукт уже вышел на арену.
Именно, когда весь функционал — это большое количество небольших независимых напрямую друг от друга задач. А вот например когда вам нужно провести полный редизайн системы для последующего роста, вы задолбаетесь делить задачи и сортировать по их зависимости друг от друга.
Scrum основан на ряде априорных допущений и упрощений, которые в общем случае не верны, и зачастую создает лишь видимость эффективной работы. К сожалению, нет объективных и достаточно надежных показателей, позволяющих оценить эффективность внедрегия scrum.HumanoIT Автор
20.03.2018 16:56Да, соглашусь — всяк сверчок знай свой шесток. У всякой методологии есть свой класс задач, для которых она подходит. Строительство стадиона тяжело делать на базе Agile. То есть можно, никто не запрещает, но скорее всего вылезет много косяков. Или внутренний софт для банка, у которого фиксированный набор требований и вряд ли они будут меняться по пути.
ZaEzzz
20.03.2018 13:16Я, конечно, понимаю маркетоидность статьи, но попрошу не вводить народ в заблуждение.
Если коротко, то я не скажу что лучше — Kanban или Scrum. И так же не буду делать выводы когда они лучше — мы на старте работами по канбану, но после релиза вышли на скрам. Каждый просто выбирает для себя под конкретно свои задачи в зависимости от эффективности.
А теперь по полочкам все маркетоидные пункты:Мы работаем по Scrum'у чуток подтюненому под себя (это же методология, а не свод законов с расстрелом) и:
1. Определение узких мест — все видно прекрасно.
2. Точный порядок выпуска фич. Соблюдается. А соблюдается-ли он в канбане? Фича разработана, но вылетела в доработку. Пока ее дорабатывали (дефектед бай дизайн) выпустили еще три фичи. Точный порядок соблюден? Или я что-то не так понимаю.
3-5. Swimlanes(3). Очень редко этим пользуюсь и только для специфичных вещей. Но разве это фича канбана и служит для перехода на это методологию? Та же история с фильтрами(4), но ими пользуемся ощутимо чаще. А панорамный вид(5) без скриншота — это вин! У меня для него 4к монитор.
6. Гибкость. Scrum достаточно гибок. Настраивайте его под себя и свои потребности бизнеса. Мы можем релизить фичи по несколько раз в день по спиральной модели — скраму это не мешает.
7. Не нужно оценивать фичи. Очень интересно было бы послушать как вы собираетесь сообщить срок реализации фичи. Мы при оценке обсуждаем план реализации. Грубо говоря на оценке уже идет процесс разработки и реализации задачи/юзерстори.
8. Больше дела. Потеря времени на коммуникациях больше происходит от лени. У нас уходит 10% в сумме за спринт. Вместе с оценкой задач, ежедневными митингами и рестроспективой.
9. Командный дух. Высосано из пальца. Что будет делать ваш тестировщик, если сейчас пять разработчиков работают над пятью тяжелыми монументальными задачами?
10. Ошибаться раньше… Дубль пункта 6.
11. Больше потока. Это фича канбана? Ведите скрам доску, туду лист или еще что — вот вам и просмотр потока.
12. Больше знаний – лучше для проекта. Странно — у нас та же история — любой участник команды может просто взять и глянуть. Кстати, это дубль нескольких пунктов. Вообще пункты как-то пересекаются некрасиво.
13. Концентрация на одной задаче. Вау! У нас тоже так.HumanoIT Автор
20.03.2018 16:52Привет! Спасибо за то, что описали свой опыт.
На самом деле в статье я сравнивал Scrum и Kanban лишь в 7, 8 и 10 пунктах. Все остальное одинаково применимо и в Скраме тоже. Те же WIP лимиты можно использовать и в Спринтах. Инструменты позволяют использовать для Спринтов канбан-доски и все их преимущества. А их немало — и про них написал в статье.
Кстати, так не всегда было. Давным давно я работал по Скраму на таком софте, который не поддерживает Канбан — Acunote.
ps. Эта статья скорее для тех, кто не юзает ни Скрам ни Канбан и хочет попробовать Канбан.ZaEzzz
20.03.2018 20:53Вы прямо указываете на Scrum в пунктах 7, 8 и 10, но что же мы видим в начале стати?
Как и когда наступает момент истины в споре Scrum vs Kanban и почему гибкая Agile-методология Kanban смортится привлекательнее.
Далее идет 13 причин за канбан. Логично, что все повествование идет в ключе «Чем Kanban лучше Scrum'а». У вас все перемешивается все в одну кучу. Имеются моменты, которые никак вообще не выделяются именно в Agile методологиях — они там просто тоже есть, но «это же фича канбана». И все в таком духе. Особенно повеселил фильтр своих задач — да, это именно в канбане такое есть.
Кстати, помню работал по скраму на жестком таком софте, называется «Магнитно маркерная доска». И оно работает! Эффективно работает!
Эта статья скорее для тех, кто не юзает ни Скрам ни Канбан и хочет попробовать Канбан.
Будем честными — это статья для вас. Точнее для того, чтобы она была.
Давайте представим, что я не пробовал ни бананы, ни ананасы. Но откуда у вас уверенность, что я хочу попробовать ананас? Ваша статья описывает фрукт. Возможно даже манго. А вы все настаиваете что на ананасе.
К чему это я. Я прекрасно понимаю, что вы рекламируете свою платформу. Если бы вы описали логику Agile и как ее можно применять в вашем продукте, какие есть отличительные черты именно вашего продукта при использовании этих методологий, некоторый толмут что и как устроено для легкого старта, то, скорее всего, я бы даже зашел посмотреть ваш сайт и демо, если есть. Но в самой статье я вижу что автор «на собственном опыте» выдал кашу, которая откровенно вводит в заблуждение смешивая теплое с мягким. Знаете, может быть вы не заметили, но вы даже модели разработки затронули и приплели к методологии. Такой подход заставляет думать, что в вашем продукте все не очень хорошо с логикой. Как в тайге — там тоже все в кучу свалили, хотя некоторые моменты мне честно понравились.
P.S. Почему я пишу эти комментарии? Да просто после одной статьи МС я решил ради интереса попробовать, что же они там предлагают. Внезапно они ввели в заблуждение, и у меня баланс в облаке незаметно ушел в минус. Теперь если я вижу, что идет недостоверная информация, то я пишу об этом — у меня, в худшем случае, это время чаепития, а у вас — подбор корректного ответа.HumanoIT Автор
20.03.2018 22:11Как и когда наступает момент истины в споре Scrum vs Kanban и почему гибкая Agile-методология Kanban смортится привлекательнее.
За это извиняюсь — редакторы делали рерайт этой статьи с другого сайта и для SEO вставили ссылку на другую статью, где я сравниваю Канбан и Скрам. В этой статье я описываю преимущества Канбана безотносительно Скрама. В той статье я сравниваю Канбан и Скрам.
По поводу остального — ваше право так считать. Ну и естественно этот блог мы завели с рекламной целью — чтобы продвигать свой продукт.ZaEzzz
20.03.2018 22:41За это извиняюсь — редакторы делали рерайт этой статьи с другого сайта и для SEO вставили ссылку на другую статью, где я сравниваю Канбан и Скрам.
Прошлую статью я не стал комментировать — там есть комментарии с аналогичными мыслями, а так же вы сами в комментарии рассказали, что не изучили конкурентов. Косвенно, но рассказали (Основное отличие от Jira).
А теперь, после правок, расскажите как вы с пунктом 7 сообщите заказчику когда будет готова его FJ Camry в модификации AT38.
ARadzishevskiy
20.03.2018 18:12+2шоурум Toyota в наши дни… Однако на складе Toyota в этот момент нет вашего цвета автомобиля.
Очень хороший пример, для использования Канбан. я бы сказал знаковый. Если у Вас есть коробочная версия продукта и Вам необходимо ее только кастомизировать (покрасить кнопки в другой цвет)- подходит отлично.
Если продолжать сравнивать автопром, прийти в Toyot и попросить разработать новый автомобиль, на новой платформе, с абсолютно новыми характеристиками, подозреваю, что они не будут пользоваться Канбан.
На мой взгляд, Канбан в ИТ как раз удобно использовать, на этапе внедрения, когда надо быстро вносить изменения. При этом уже возникли условия, когда 1) Есть ТЗ, на основании которого можно легко вносить изменения (перепроектировать) 2) Исполнители уже общаются с заказчиком, даже очень занятым (он созрел, ему это уже кровно необходимо) 3) В итерациях основного этапа разработки, команда набила руку, внесла изменения в процесс (оптимизировала конвейер) 4) Изменения необходимо вносить очень быстро, небольшими партиями и т.д.
sshikov
20.03.2018 18:33>Переход на Kanban доски с обычных списков задач сразу показал нам узкое место: в колонке Testing скапливалась большая очередь задач. Наш QA не справлялся с проверкой задач.
Можно подумать, что без канбана вы этого не знали. Любой вменяемый тимлид/РП и так знает узкие места проекта, более того, если он в состоянии воспользоваться скажем MS Project, то критический путь будет виден на диаграмме до начала работ. А если не будет, это значит что кто-то, кто отвечает за планирование работы, не умеет точно оценивать трудоемкость. Но только если он не научится этого делать, никакая организация процесса его не спасет все равно.
nki
Исправьте, какая-то возможность лишняя.
HumanoIT Автор
Спасибо) поправили.
Ugrum
Возможности лишними не бывают!