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

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

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

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

Мои лучшие "решения/идеи" до сих пор:

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Scrum обычно интерпретируется, чтобы сказать, что нетехнические "Владельцы Продуктов" могут определять график работы, основанный исключительно на собственных проблемах. Если вы пойдете по этому пути, вы понесете много отходов, не используя возможности для совместной работы, которые принадлежат друг другу. Работа, которая принадлежит вместе, не может быть определена только пожеланиями владельца продукта. Необходимо также учитывать возможности технических и трудовых ресурсов (навыков).

Чтобы работа была выполнена наиболее продуктивно, сама работа должна быть разработана таким образом. Это означает, что в команде Lan Product Development решения принимаются не нетехническим работником, а тем, что Toyota называет кого-то из "Towering Technical Competence", который близок к продукту, рядом с клиентами и рядом с командой.

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

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

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

Ответ 7

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

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

  • Отставание
  • TODO
  • Выполняется (разработка и быстрое тестирование)
  • Обзор кода
  • Тест (строгое тестирование)
  • Тест интеграции и общие приемочные испытания
  • Deploy

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

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

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