• Найдите любые ММФ, которые ваша команда уже завершила, и создайте карту потока ценности для них. Хорошо, если вы сможете собрать всю команду, чтобы сделать это вместе. Затем создайте карту потока ценности для другой ММФ. Каковы сходства и различия между двумя потоками ценности?
• Найдите узкое место, на которое ваша команда регулярно натыкается. (Карты потока ценности могут оказаться для этого очень полезными.) Организуйте дискуссию о том, как вы можете облегчить эту проблему в будущем.
• Посмотрите на даты, за которые вы и ваша команда сейчас отвечаете. Вы действительно взяли на себя те обязательства, про которые думаете, что вы их взяли? Есть ли варианты поставить что-то другое, одновременно выполнив эти обязательства?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о Lean, ценностях бережливого мышления и картах потока ценности в книге Мэри и Тома Поппендик Lean Software Development: An Agile Toolkit (Addison-Wesley, 2003).
• Узнайте больше о Lean и картах потоков создания ценности в книге Алана Шэллоувея, Гая Бивера и Джеймса Тротта Lean-Agile Software Development: Achieving Enterprise Agility (Addison-Wesley, 2009).
• Вы сможете узнать больше о ММФ, о том, как разбить или разложить пользовательские истории, в книге Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (М.: Вильямс, 2012).
• Узнайте больше о возможностях вариантного мышления в романе об управлении рисками проекта Олава Маасена, Криса Матса и Криса Хипихапу Commitment (Hathaway te Brake Publications, 2013).
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Большинство людей, работающих в командах разработки программного обеспечения, никогда не сталкивались с мышлением, имеющим собственное название. Помогая им понять, что Lean – это мышление, а не методология, вы сделаете первый шаг к его принятию командой.
• Привычка говорить о потерях – одна из самых трудных частей бережливого мышления. В то время как большинство коучей соглашаются, что команды должны оставаться позитивными, «выяснение отношений» может оказаться полезным, когда дело доходит до помощи команде научиться определять потери (особенно когда речь идет о неразумности и невозможности).
• Вы можете вести дискуссию о потерях в положительном ключе, помогая найти примеры того, что можно считать потерями с точки зрения
• Часть вашей работы как коуча состоит в том, чтобы избегать трений между командой и компанией. Если имеются случаи, когда даже обсуждение проблем с топ-менеджерами может привести к серьезным последствиям для команды, то внедрение Agile способно вызвать более серьезные проблемы. Максимально
• Еще один способ оставаться позитивным – это помогать обеим сторонам (и командам, и менеджерам) отделять процессы или системы от людей, работающих в них. Потери, неэффективность, обратная связь – это про то, что нужно сделать с процессом, а вовсе не суждения о людях, выполняющих свою работу.
Глава 9. Канбан, поток и постоянное совершенствование
Канбан – это не методология разработки программного обеспечения, прием описания жизненных циклов или подход к управлению проектами. Вам необходимо наличие какого-то базового процесса, к которому можно применить Канбан, для постепенного изменения и улучшения этого процесса.
Канбан – это метод улучшения процессов, используемых гибкими командами. Команды, применяющие его, начинают понимать, как они создают программное обеспечение, и постепенно улучшают его. Канбан, так же как Scrum и ХР, затрагивает образ мышления человека. В частности, он требует бережливого мышления. Мы уже узнали, что Lean – это образ мышления, ценности и принципы. Команды, использующие Канбан, начали с применения мировоззрения Lean. Это обеспечивает прочный фундамент, который в сочетании с Канбаном дает возможность улучшить процессы. Когда команды используют Канбан для усовершенствования, они сосредоточены на устранении потерь из процессов (в том числе м