Сравнение водопадной модели (waterfall), аджайла (agile) и бережливого производства (lean)

Время проведения: 30 мин.

Количество участников: 9-12 человек

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

Ход игры:

Скачайте файл с карточками утверждений, распечатайте и разрежьте по линиям.

Разместите три карточки с заголовками на столе или на стене в одну горизонтальную линию.

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

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

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

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

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

Удачи!

Верные ответы:

Водопадная модель

  1. Вы знаете все, что необходимо для создания продукта в начале проекта
  2. Заказчик может точно сказать вам, что он хочет, в начале проекта
  3. Вам необходимо получить обратную связь от пользователей до того, как закончится проект
  4. Менеджеры, разработчики и пользователи могут получить полное представление о проекте, посмотрев на завершенные этапы, которые отражены в документации.
  5. У вас есть отдельные группы аналитиков, дизайнеров, разработчиков и тестировщиков
  6. Передача информации между людьми может быть эффективно реализована с помощью записи того, что было сделано на каждом этапе
  7. Вы можете протестировать полученные результаты в конце проекта и добиться необходимого качества
  8. Руководство может требовать выполнения фиксированного объема работы в определенное время и ожидает, что это произойдёт
  9. Предоставление людям нескольких проектов для выполнения определенной работы — это хороший способ для достижения 100% производительности, потому что в этом случае все заняты.

Аджайл

  1. Вы не можете знать все, что нужно, для создания продукта в начале проекта
  2. Заказчики не могут точно сказать вам, что они хотят в начале проекта. Вместо этого они улучшают это понимание по мере продвижения проекта
  3. Вы хотите получать обратную связь от заказчиков и пользователей как можно чаще, и вы хотите предоставить эту информацию разработчикам как можно скорее
  4. Рабочий продукт — самый лучший способ увидеть прогресс в работе
  5. Совместная работа группы сводит к минимуму задержки по времени, а также потерю информации между людьми
  6. Включение тестирования в процесс разработки улучшает взаимодействие между разработчиками, заказчиками и тестировщиками и, таким образом, улучшает качество кода
  7. Руководители могут обозначать свои пожелания относительного того, что нужно сделать, но не требует, как это делать
  8. Фокус и работа в одном проекте повышает производительность команды

Бережливое производство

  1. Большинство ошибок связано с системой, в которой работают люди, а не с самими людьми
  2. Люди, которые выполняют работу, лучше всех понимают, как улучшить систему
  3. Способы решения специфической проблемы или задачи, который невозможно приспособить для решения других задач и который не вписывается в общую стратегию решений (Ad hoc) являются неприемлемыми
  4. Наблюдение за процессом на месте является более полезным, чем попытка отстранённо от процесса проанализировать эффективность каждого шага
  5. Успех определяется количеством времени, которое прошло с момента возникновения идеи или запроса и поставкой ценности для пользователя
  6. Руководители должны работать с командой, чтобы улучшить методы работы и повысить собственную эффективность
  7. Команды наиболее эффективны, когда объем работы ограничен их возможностями
  8. Эффективность команды повышается за счет минимизации объема выполняемой работы за единицу времени
  9. Мы должны оптимизировать и смотреть на процесс в целом, а не просто улучшать отдельные шаги в процессе
  10. Существуют принципы в разработке программного обеспечения, которые необходимо соблюдать, чтобы уменьшить потери

 

Share

Сертифицированный скрам-мастер, тренер и коуч Сфера интересов: Развитие команд и организаций, тренинги и обучение

Рекомендуем посмотреть:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *