Скрам хорош, как средство ежедневной синхронизации всех действий команды.
Для менеджера — это хороший инструмент держать руку на пульсе и понимать ситуацию ежедневно.
Например, если аналитика запаздывает, можно направить разработку на фикс накопившихся багов или закрытие TODO-листа.
Получается, что это не столько кайдзен (филосифия), сколько инструмент подходящий для конкретной задачи — понимать, что происходит в проекте и управлять его ресурсами.
Однако, следует понимать, что скрам решает вопрос управления в краткосрочной перспективе, для осознания глобального движения и целей лучше проводить ретроспективы (например раз в 2 недели или месяц).
Ещё скрам отлично работает в сочетании с классической канбан-доской (видеть статусы всех задач на доске, распределение разработчиков-булавок на задачах-стикерах).
Пожалуй, классический пример применения кайдзен в разработке по части избегания инноваций — это не ставить разработчику сразу огромную задачу (а потом выслушивать на скраме, что он всё ещё её делает и надо наверно еще дня 3-4 и так недели две). А разбивать её на подзадачи длиной 1-2 дня и контролировать их исполнение на скраме с оперативным решением вопросов тим-лидом команды, если у разработчика появляются вопросы/стопоры в реализации).
По части улучшения продукта — может быть:
* регулярный сбор аналитики по проблемам, с которыми обращаются в тех. поддержку пользователи системы и решение этих проблем
* UX-тестирования новых прототипов на реальных пользователях
* культура код-ревью старшим разработчиком/тим-лидом
* культура TODO-пометок при написании кода по новым задачам с использованием старых компонентов и реализации этих пометок
* культура обобщения кода и компонентов при развитии проекта
Для менеджера — это хороший инструмент держать руку на пульсе и понимать ситуацию ежедневно.
Например, если аналитика запаздывает, можно направить разработку на фикс накопившихся багов или закрытие TODO-листа.
Получается, что это не столько кайдзен (филосифия), сколько инструмент подходящий для конкретной задачи — понимать, что происходит в проекте и управлять его ресурсами.
Однако, следует понимать, что скрам решает вопрос управления в краткосрочной перспективе, для осознания глобального движения и целей лучше проводить ретроспективы (например раз в 2 недели или месяц).
Ещё скрам отлично работает в сочетании с классической канбан-доской (видеть статусы всех задач на доске, распределение разработчиков-булавок на задачах-стикерах).
Пожалуй, классический пример применения кайдзен в разработке по части избегания инноваций — это не ставить разработчику сразу огромную задачу (а потом выслушивать на скраме, что он всё ещё её делает и надо наверно еще дня 3-4 и так недели две). А разбивать её на подзадачи длиной 1-2 дня и контролировать их исполнение на скраме с оперативным решением вопросов тим-лидом команды, если у разработчика появляются вопросы/стопоры в реализации).
По части улучшения продукта — может быть:
* регулярный сбор аналитики по проблемам, с которыми обращаются в тех. поддержку пользователи системы и решение этих проблем
* UX-тестирования новых прототипов на реальных пользователях
* культура код-ревью старшим разработчиком/тим-лидом
* культура TODO-пометок при написании кода по новым задачам с использованием старых компонентов и реализации этих пометок
* культура обобщения кода и компонентов при развитии проекта