четверг, 11 июля 2013 г.

Lean №3 - Итерации

Итеративный подход является следствием Feedback практики. Чем меньше итерация, тем более быстрый feedback мы можем получить. Тем меньше потерь, быстрее сходятся точки зрения, мы более гибкие к изменениям.

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

Как следствие идеи на проверку
  1. Просить feedback не только после ретроспективы но и после каждого events - планирование, grooming, workshop, daily, какие-то специфические встречи. Это позволит менять формат events в лучшую сторону - мы уже год мало что меняем в них. 
  2. Помимо полугодовых аттестации в Компании проводить feedback встречи с сотрудниками (кто захочет) каждый месяц, например. Это было бы полезно. Но обычно никто не хочет развиваться. 

Идеи по Lean
  1. 3 принципа итераций 
    1. Исполнение работы маленькими порциями. Чем меньше порция результатов тем быстрее они проходят полный рабочий цикл. Если мы пытаемся тестировать все задачи спринта в конце спринта - это fail. Если дизайнер нарисовал прототипы сразу всех страниц и отгрузил их то любое замечание отправит большую часть его работы с корзину. Тоже самое с форматом требований, спеками, тестами и тп. 
    2. Вариативный подход. Всегда реагируем на факты, а не полагаемся на наши планы. Нужно уметь подстаиваться, быть готовым к изменениями. 
    3. Итерация - это точки синхронизации людей, команд и тп. Покажи продукт пользователю и синхронизируй vision. Покажи реализацию команде ASAP и у нее будет больше шансов тебя поправить. Провалидируй предположения с Impact mapping карты и меньше будет глобальных изменений 
  2. "У Заказчика постоянно меняют требования - значит он не знает что он хочет - значит он идиот". Наоборот, это vision, понимание, точки зрения на продукт сходятся. И чем меньше итерация тем это дешевле стоит для команды. 
  3. Изменяемый Scope работ - это хорошо. Это позволяет быстрее добится схождения точек зрения на продукт между Заказчиком и Исполнителем. Это позволяет реализовать только то что реально нужно, и то что не нужно будет удалено. 
  4. "Но Scope не должен менятся во время спринта" - это уже задача PO и PO support team. Нужен root-cause анализ почему scope истории изменился во время спринта? Чаще всего это следствие плохой аналитики по истории, или не согласованности точек зрения на эту историю с Заказчиком или пользователем. 

Комментариев нет:

Отправить комментарий