Как часто выпускать с Lean / Kanban?

Question

Я довольно новичок в Lean / Kanban, но за последние несколько недель изучил онлайн-ресурсы и задал вопрос, на который я не нашел хорошего ответа. В противном случае Lean / Kanban очень хорошо подходит для нашей компании, которая уже использует Scrum, но достигла некоторых ограничений в этой методологии. Я надеюсь, что кто-то здесь может дать мне хорошую идею.

На мой взгляд, одним из самых больших преимуществ Scrum по сравнению с Waterfall является использование спринтов. Когда все готово каждые 14 дней, вы получаете короткие циклы обратной связи и можете часто выпускать. Однако, как я понял из прочтения о Lean, с этим связаны некоторые расходы (например, время, затрачиваемое на встречи по планированию спринтов, встречи с участием команды и некоторые проблемы с поиском чего-то полезного для всех в конце спринтов). 1003 *

Lean / Kanban удалит эти отходы, но только за счет невозможности их выпуска каждые 14 дней. Или я пропустил важный момент? В Канбан, как вы можете работать над новыми задачами разработки и выпустить одновременно? Как убедиться, что вы не отправили что-то, что сделано только наполовину? И как вы можете проверить это правильно?

Мои лучшие «решения / идеи» на данный момент:

• Не выпускайте часто и допускайте потери, связанные с выполнением новых задач разработки. Хотя на самом деле это не решение вопроса.
• Развивайтесь в ветвях, а затем сливайтесь в основной ствол. Позволяет постоянно поддерживать как минимум две ветви.
• Используйте некоторую интеллектуальную систему автоматической маркировки, чтобы автоматически создавать только определенные законченные задачи, а не другие.

Как итог, мой вопрос : Когда вы используете Lean / Kanban, можете ли вы часто выпускать без использования отходов? Или релиз часто не является частью Lean / Kanban?

Дополнительная информация, относящаяся к моей компании : Мы используем Team Foundation System & Source Control и ранее имели некоторые неприятности в отношении ветвления и слияния. Может ли это быть решено просто путем привлечения некоторого опыта в этой области?

Answer 1

Проблема, которую вы описываете, кажется больше программой управления исходным кодом - как отделить готовые функции от выполняемых функций, чем с Канбаном. Похоже, вы накладываете серьезное наказание на запуск многих веток - это относится к системам контроля версий, не основанным на идее нескольких ветвей. В системах управления распределенными источниками, таких как GIT и Mercury, все - это ветвь, и иметь их и работать с ними легче.

Полагаю, вы прочитали этот блог о Канбан против SCRUM и соответствующем практическом руководстве?

И, в ответ на ваш вопрос, да, вы можете часто выпускать с Канбаном.

Answer 2

Вы должны понимать тяговые системы, которыми Kanban предназначен для управления.

Запрос клиента (или владельца продукта или аналогичного) на функцию в работающей системе - это то, что запускает процесс.

Запрос является сигналом, который отправляется на развертывание. Развертывание ищите проверенный элемент со свойствами, соответствующими запросу. Если их там нет, вы пишете тесты и смотрите на разработку, если есть слот для разработки, который можно использовать для реализации чего-то, что выполняет тест. Когда разработка завершает свою разработку (возможно, сначала ищет подходящий анализ и т. Д.), Тест выполняет тестирование и развертывание развертывается.

Запросы, идущие в обратном направлении через систему, являются разрешениями для начала работы. Как только запрос поступил, это вызывает много действий, где каждое действие должно быть выполнено как можно быстрее. Там у вас есть турбо развертывание.

Точно так же, как запрос на автомобиль поступает к дилеру, который смотрит на судно, который сигнализирует автомобильному заводу, который сигнализирует поставщикам.

Kanban не направляет запросы через систему. Речь идет о вытягивании функциональности из системы в обмен на запрос, поступающий через последний шаг.

Answer 3

Это нечто большее, чем просто управление исходным кодом, но ваш выбор TFS ограничит вас. Когда проект Бертона был задуман еще в 2004 году, Microsoft не обращала внимания на Agile, а тем более на Lean. Это будет ваше самое слабое механическое звено в течение некоторого времени. Ваши хаки должны были быть подняты благодаря собственному принятию Mercurial компанией CodePlex после того, как она была предложена сообществу Microsoft в качестве плаката для внедрения TFS.

Более существенным вопросом здесь является Work Design. Он включает порядок, который вы выбираете для реализации функций (график работы), а также расстановку приоритетов и стоимость задержки, а также форму и размер рабочих элементов.

Скрам обычно интерпретируется как утверждение, что нетехнические «Владельцы продукта» могут определять график работы, основываясь исключительно на своих собственных проблемах. Если вы пойдете по этому пути, вы понесете много потерь, не используя возможности делать совместную работу, которая принадлежит друг другу. Совместная работа не может быть определена только пожеланиями Владельца продукта. Технические и трудовые (навыки) возможности также должны быть приняты во внимание.

Чтобы работа выполнялась наиболее продуктивно, сама работа должна быть спроектирована таким образом. Это означает, что в группе разработки продуктов Lan решения принимаются не нетехническим работником, а тем, кого Тойота называет «высокой технической компетенцией», который близок к продукту, близок к клиентам и близок к команде. .

Эта роль резко контрастирует с предложением Скрама. Главный инженер в команде Lean сам является голосом клиента, и роль Владельца продукта не нужна.

«Владелец продукта» компании Scrum - это признание недостаточно развитой роли в организациях по разработке программного обеспечения, но это далеко не устойчивое решение, которое последовательно избегает потерь. Роль «Архитектора программного обеспечения» также часто оказывается недостаточной, поскольку в некоторых субкультурах разработчиков архитектор слишком отстранен от работы.

Ваши проблемы непрерывного развертывания решаются лишь частично с помощью технологий и инструментов. Также обратите внимание на организационные вопросы и, возможно, подумайте о цели Scrum как о переходном подходе от водопада, а не как о том, который может служить вашей организации бесконечно.

Answer 4

То, как мы работали с еженедельными выпусками по устойчивому инженерному проекту, в котором использовался Kanban, заключалось в реализации стратегии ветвления. Разработчики работали в ветке песочницы и делали одну проверку для каждого рабочего элемента. Наши тестеры проверяли рабочий элемент в песочнице; если он пройдет регрессионные тесты, регистрация будет перенесена в нашу ветку release. Мы заблокировали ветку релиза с полудня понедельника до выхода релиза (обычно к среде, иногда к четвергу, дата выпадения была пятница) и повторно запустили регрессивные тесты для всех перенесенных проверок, а также интеграционные тесты для продукта сбросить релиз, как только пройдут все тесты.

Эта стратегия позволяет разработчикам постоянно работать над проблемами, не отвлекаясь от их веток в процессе выпуска. Это также позволило им работать над вопросами, решение которых заняло больше недели; если он не был зарегистрирован и проверен / одобрен, он не был перенесен.

Если бы я запускал Kanban для новой версии проекта, я бы использовал похожую стратегию, но сгруппировал все связанные проверки как «функцию», перенеся функцию массово в ветку релиза один раз. эта функция была завершена, а затем выполнили дополнительное модульное / интеграционное / приемочное / регрессионное тестирование в ветке релизов, прежде чем выпустить релиз с этой функцией. Обратите внимание, что ключевой концепцией Kanban является ограничение выполняемой работы, поэтому я мог бы ограничить свою команду работой над одной функцией за раз (это, вероятно, будет несколько рабочих элементов / пользовательских историй).

Answer 5

Команда, которой я управляю, использует Kanban, и мы выпускаем ее каждые две недели. Если вы строго относитесь к тому, что интегрируется в вашу ветвь кода (прохождение тестов, одобрение клиентов и т. Д.), Kanban позволяет выпускать в любое время. Вы должны убедиться, что истории, движущиеся по вашей системе, не являются взаимозависимыми, чтобы сделать это, но с моей командой это обычно не проблема - большая часть нашей работы включает в себя обслуживание, которое состоит из нескольких несвязанных исправлений ошибок / функций в выпуске.

Answer 6

Как мы это делаем:

У нас есть трубопровод со следующими этапами

1. Отставание
2. TODO
3. Выполняется (Разработка и быстрое тестирование)
4. Проверка кода
5. Тест (Строгое тестирование)
6. Интеграционные испытания и общие приемочные испытания
7. Deploy

Каждая история разрабатывается как ветвь, основанная на последней версии, которая покидает стадию развертывания. Затем они интегрируются как часть подготовки интеграционного теста.

QA выходит из стадии проверки кода и может готовить релизы в любом темпе. Я думаю, что у нас примерно один выпуск в неделю.

Удаляя ветку "master" из git и не производя слияния перед этапом проверки кода, мы убедились, что нет возможности "проникнуть" в релизы кода. Что, как интересный побочный продукт, заставило нас визуализировать большую часть работы, которая раньше была скрыта.

Answer 7

Для управления источником я настоятельно рекомендую Perforce . Это делает ветвление и интеграцию изменений из других ветвей относительно простым и обеспечивает лучший интерфейс для управления исходным кодом, который я видел до сих пор.

Также помогает непрерывная интеграция, т. Е. Множество мелких, более ежедневных коммитов, вместо огромных и потенциально сложных слияний. Такие инструменты, как CruiseControl , могут помочь выделить, когда источник сломан из-за плохой фиксации. Кроме того, если каждый внесет много небольших изменений, конфликтующие изменения будут редкими.

Я бы также посоветовал не пытаться следовать таким вещам, как Lean, Scrum, Kanban & Co. слишком тесно Просто решите проблемы самостоятельно, обращаясь к этим идеям за руководством, а не инструкцией. Специфика ваших проблем, скорее всего, потребует некоторой гибкости для лучшего управления.