Мы Решили Внедрить Принципы Agile-Lean В Процесс Разработки «На Лету» И Вот Что Из Этого Получилось.

В настоящее время на слуху термин «бережливое производство» (Lean).

Все мы знаем результаты использования этой идеи в Toyota, которая позволила производить небольшие партии компонентов точно в срок (Just-In-Time, JIT).

В книге «Секреты Microsoft» (1995) авторы (Кусумано и Ричард Селби) описали подходы к контролю качества, аналогичные Lean, используемые в Toyota. Выпуск небольшими партиями идеально подходит для разработки программного обеспечения.

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

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

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

Перегруженность разработчиков, большое количество повторных доработок уже реализованных задач, превышение продолжительности проекта, сложность прогнозирования сроков этапов разработки.

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

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

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

Все процессы согласования и принятия управленческих решений осуществлялись в рамках внедренной системы.

Мы решили стабилизировать существующую ситуацию.

Внедрять полноценный Lean было уже поздно, да и опыта такого не было.

Мы решили адаптировать элементы Agile-Lean в текущий процесс управления проектами, и вот что из этого получилось.

Отправная точка

Набор артефактов:

1. Бэклог проекта — это журнал требований, реализованных в рамках проекта, инцидентов, обнаруженных в ходе работы.

   Обычно требования представляются в виде пользовательской истории.

   Excel использовался как инструмент планирования верхнего уровня.

   Там для удобства, чтобы все было в одном месте, диаграмма Ганта и диаграмма горения вынесены на отдельную страницу.

2. Журнал спринта — это журнал требований и инцидентов, реализованных во время спринта.

3. Скрам-доска.

   В качестве инструмента использовалась доска Trello с расширением Plus For Trello для контроля трудоемкости.

1. Менеджер проекта — сотрудник, который планирует процесс реализации требований и координирует действия всех участников до завершения проекта.

2. Скрам-мастер обычно является руководителем группы разработки, управляет процессом разработки и отвечает за конечный результат работы разработчиков.

3. Команда разработчиков состоит из опытных разработчиков и новичков, которые совершенствуют свои компетенции в процессе участия в проекте.

4. Команда консультантов – это команда сотрудников, погруженных в бизнес-процессы заказчика.

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

1. Ежедневная встреча команды.

2. Ретроспектива в конце спринта.

3. Ежеквартальные ретроспективы.

1. Продолжительность: 1 месяц.

2. Ежедневные обновления продуктивной системы по мере завершения работы над блоками задач.

Во время карантина этот подход не удался.

Удаленная работа наложила отпечаток на эффективность работы команды, и мы столкнулись с трудностями, которые необходимо было решить.

«Хьюстон, у нас проблемы».

Фактически мы стояли на месте.

Вероятность успеха, если все сделать вовремя, стремилась к 0.



Чтобы исправить ситуацию, было решено провести экстренную ретроспективу и собрать все существующие проблемы.

Были выявлены следующие точки улучшения:

1. Сильная перегрузка разработчиков.

   Постоянно превышаю 8-часовой рабочий день, выхожу на работу по выходным.

   Снижается мотивация и возрастает напряжение в коллективе.

2. Недостаточный качество финального кода , необходимо улучшить контроль качества.

3. Многие задачи возвращаются на доработку; В процессе тестирования выявляются требования, не зафиксированные в описании задачи.

   Описание требований нуждается в доработке.

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

   Дивизию надо оставить.

5. Много времени уходит на разработку и доработку, консультанты бездействуют .

6. Недостаточная компетентность разработчиков в администрировании и настройке ОС, тестовых стендах и стендах разработки.

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

   Необходимо повышать компетенции разработчиков.

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

Именно в этот момент возникла идея использовать подход JIT для улучшения сложившейся ситуации.

Какие преимущества Agile-Lean мы постараемся использовать в нашем проекте?

Сильные стороны:

1. Получите результаты в ограниченное время.

2. Устраните ненужные действия, которые могут снизить затраты.

3. Расширение прав и возможностей команды разработчиков, чтобы помочь им принимать решения.

4. Гибкость проекта, возможность подстроить его под требования заказчика.

1. Повышенные требования к вовлеченности команды в процесс.

2. Строгая документация, что несколько противоречит принципам Agile, когда продукт важнее документации.

3. Необходимость детального планирования перед каждым спринтом.

4. Необходимо выделить сотрудников, которые будут контролировать процесс, но не будут участвовать в производстве, что ослабит команду.

5. Длительность процесса разработки может увеличиться, к этому нужно быть готовым.

Давайте адаптируем 7 принципов Lean

• Устранение потерь.

  Убытком считается все, что не добавляет ценности потребителю: чрезмерная функциональность; ожидание (пауза) в процессе разработки; неясные требования; бюрократизация; медленная внутренняя коммуникация.

• Акцент на обучении.

  Короткие циклы разработки, раннее тестирование, частая обратная связь от заказчика.

• Очень сильно запоздалое принятие решения.

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

• Очень сильно быстрая доставка клиенту.

  Короткие итерации.

• Мотивация команды.

  Людей нельзя рассматривать исключительно как ресурс.

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

• Интеграция.

  Передача полной информации клиенту.

  Стремитесь к целостной архитектуре.

  Рефакторинг.

• Целостное видение.

  Стандартизация, налаживание взаимоотношений между разработчиками.

  Распространение принципов бережливого производства разработчиками.

  «Думайте широко, действуйте быстро, делайте меньше ошибок; научиться быстро.

  "

1. Уберите ненужные вещи

1. Все, что не представляет ценности для конечных пользователей.

   Сюда входят неясные и несрочные требования, а также редко возникающие дефекты.

   Мы откладываем их или отказываемся от них вообще после согласования с заказчиком.

2. Ненужный код, дублирование кода.

3. Неясные цели и требования.

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

4. Программные дефекты.

   Любые дефекты появляются, когда код не проходит достаточное тестирование качества.

5. Разработчик переключается между задачами.

   Задача не должна быть слишком маленькой или слишком большой.

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

1. Детальная разработка требований и согласование описания требований с лидом разработки, дополнительная расшифровка требований тимлидом на понятный разработчикам язык.

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

3. Расширение взаимодействия между разработчиками, консультантами и руководителем команды.

   Регулярные встречи 1:1, еженедельные встречи для мини-тренингов и небольших вебинаров, еженедельная упрощенная ретроспектива для обсуждения и решения текущих трудностей на месте.

4. Формирование задач из набора требований в рамках одного реализуемого процесса.

   Расчет: разработчик занят одной задачей не менее 8 часов.

2. Создавайте и делитесь знаниями

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

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

3. Улучшение качества кода

Для повышения качества были приняты следующие предложения:

1. Парное программирование.

   Прямое взаимодействие тимлида и разработчиков, совместный анализ требований, проектирование, решение сложных задач.

2. Степень готовности (Определение готовности, DoD).

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

3. Максимальное количество задач в работе (Work In Progress, WIP) для каждого разработчика.

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

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

4. Сократите спринты

Ускорить разработку становится проще, если у вас есть стабильный рабочий процесс и конкретные сроки разработки и публикации.

Поэтому мы решили ввести ряд ограничений на спринт:

1. Спринт длится 1 рабочую неделю.

2. Спринт планируется по трудоемкости, которую может охватить команда разработчиков (на основе собранной статистики за предыдущие спринты).

   Дополнительно выделяется время на устранение критических дефектов.

3. Все реализованные улучшения тестируются на специальной копии производственной системы с производственными данными (PreProd), и только после успешного тестирования публикуются в производственной среде (Prod).

4. Публикация на производственном стенде осуществляется только один раз в последний день спринта.

5. После каждого спринта проводится сокращенная ретроспектива продолжительностью 30 минут для сбора обратной связи от команды.

5. Расширьте возможности команды

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

Мнение каждого участника процесса важно и должно учитываться другими участниками процесса.

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

Эту ситуацию следует считать общей проблемой и решать совместно.

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

6. Не торопитесь с принятием решений

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

Решение, принятое под влиянием эмоций, может привести к большому количеству проблем.

7. Регулярная оптимизация процессов

Чтобы улучшить процесс разработки, необходимо выделить роль, которая будет этим заниматься.

Для реализации этого принципа все задачи разработки были сняты с тимлида команды разработки и переданы команде, объём задач на спринт был сокращен, потому что команда разработки фактически была ослаблена.

Руководитель команды теперь выступает в роли наставника:

1. Организует периодическое обучение и анализ сложных ситуаций.

2. Инициирует передачу опыта между разработчиками.

3. Помогает консультантам в формировании требований, а разработчикам в реализации этих требований.

4. Занимаюсь развитием разработчиков и расширением их компетенций.

5. Занимается подбором и разработкой инструментов, повышающих эффективность процесса разработки.

Основная проблема бережливого производства — сдвиг сроков

Но необходимо учитывать, что Lean ориентирован на постоянное совершенствование в течение длительного периода времени; эффект проявится не сразу.

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

Это необходимо учитывать, если вы планируете внедрить Lean в текущий проект. Самый правильный вариант — помнить о перспективе внедрения «бережливой разработки» еще на этапе планирования проекта и выделять дополнительное время на построение процесса.

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

Полученные результаты

Мы получили положительный отзыв от заказчика.

Сроки разработки вернули к заявленному плану за счет исключения ряда несущественных требований.

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

Методология Lean Agile представляет собой ориентированную на клиента, адаптивную и гибкую систему и не предлагает жестких правил, которым необходимо следовать.

Вам всегда придется адаптировать эту методологию к вашим существующим процессам, требованиям проекта и характеристикам клиентов.

Но в любом случае необходимо воспитывать среди своих сотрудников профессионала.

Он будет сосредоточен на совершенствовании процесса разработки и мотивирован на улучшение своих навыков и навыков команды разработчиков.

Бережливое развитие основано на сотрудничестве.

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

Для команды, работающей удаленно, необходимо выстроить взаимодействие:

1. Обеспечить единую общую среду для общения и обмена знаниями.

2. Организуйте совместные видеоконференции, желательно с камерой, чтобы увидеть эмоции участников.

3. Не пренебрегайте неформальным общением.

Заказчику необходимо понимать процесс вашей разработки и публикации, а также понимать сроки реализации требований.

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

1. Скорость разработки стала предсказуемой и составила примерно 4 больших задачи (в среднем до 6 часов на задачу) на одного сотрудника в неделю; ранее мощность команды в среднем составляла 2-3 выполненных задачи в неделю на одного сотрудника.

   Да, задачи большие и это не совсем Agile, но в нашей ситуации это помогло.

2. Количество публикаций сократилось примерно вдвое.

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

3. Количество задач, возвращаемых на доработку, сократилось вдвое.

4. Каждую неделю закрывались 3 крупные задачи из «техдолга».

5. Количество дефектов, зафиксированных конечными пользователями, сократилось в три раза.

Спасибо за внимание, коллеги! Хотелось бы увидеть в комментариях ваш опыт использования Agile-Lean (или их адаптации) на ваших проектах.

Теги: #проекты #разработка #большие данные #руководитель команды #agile #agile результаты #разработка #планирование #agile development #ретроспектива #agilean #agilean

• Получите Доступ К Защищенным Данным Клиентов В Любое Время С Помощью Cloud Act

  19 Oct, 24

• Смитсоновский Музей Собирает Деньги На Kickstarter Для Подготовки Скафандра Нила Армстронга К Выставке.

  19 Oct, 24

• Как Мы Внедрили Dlp-Систему В Международном Нефтегазовом Холдинге

  19 Oct, 24

• Игра На Собеседовании: Стратегии Найма. Часть I

  19 Oct, 24

• Дайджест Университета Итмо: Наши Разработки В 2017 Году. Часть 2

  19 Oct, 24

• Интернет-Голосование По Html

  19 Oct, 24

• Робот С Открытым Исходным Кодом: Ваш Следующий Личный Помощник

  19 Oct, 24

• ... Возьмите Кувалду И Приведите Клавиатуру В Нерабочее Состояние. Часть 2

  19 Oct, 24

• Вышла В Свет Книга «Олимпиадное Программирование».

  19 Oct, 24

• Китайские Часы-Телефон

  19 Oct, 24