Как часто выпускать релизы с помощью Lean/Kanban?[закрыто]

Question

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

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

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

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

Answer 4

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

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

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

Answer 5

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

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

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

1. Отставание
2. ДЕЛАТЬ
3. В процессе (разработка и быстрое тестирование)
4. Обзор кода
5. Тест (Тщательное тестирование)
6. Интеграционное тестирование и общие приемочные тесты
7. Развертывать

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

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

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