Клиент будет здесь менее чем через час. Все за дело! Нет ничего невозможного! Вы сможете сохранить вашу компанию, верно?
Если вы не инженер-строитель, который к тому же виртуозно управляется с клеем, то вы потерпите неудачу. Некоторые задачи невозможно выполнить, несмотря ни на какую мотивацию.
Есть люди, умудряющиеся убедить свои команды, что мотивация – это все, что нужно для достижения цели. Управление такого типа (то, что мы называем магическим мышлением) опасно. Когда вы работаете в команде, которая действует так, словно вы и впрямь на многое способны, вы будете регулярно ожидать того, чего невозможно достичь. Часто это происходит из-за нереалистичных или неразумных сроков. Но иногда проблема в технической неосуществимости (или, по крайней мере, невозможности обойтись без очень большого объема работы – как в том случае, когда весь ваш код находится в ужасной форме и «с душком»).
Это мури. Еще раз прочтем определение, которое мы дали ранее: «неразумность, невозможность, перегруженность, излишняя сложность, пересиливание, принуждение, превышение, чрезмерность».
Бережливое мышление помогает определить мури и понять, что любое усилие, которое вы тратите, пытаясь сделать невозможное, – это потери. Самый эффективный способ устранить их – это в первую очередь исключить магическое мышление, которое побуждает стремиться к невозможному.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с вашей командой).
• Определите все ММФ в вашем проекте. Как они достигаются? Вы пишете истории пользователей на карточках или стикерах и помещаете их на доску задач? Есть ли у вас индивидуальные требования в спецификации? Найдите большую функцию или историю и решите, сможете ли вы разбить ее на более мелкие куски.
• Ищите потери в вашем проекте. Запишите примеры муда, мура и мури.
• Найдите любые ММФ, которые ваша команда уже завершила, и создайте карту потока ценности для них. Хорошо, если вы сможете собрать всю команду, чтобы сделать это вместе. Затем создайте карту потока ценности для другой ММФ. Каковы сходства и различия между двумя потоками ценности?
• Найдите узкое место, на которое ваша команда регулярно натыкается. (Карты потока ценности могут оказаться для этого очень полезными.) Организуйте дискуссию о том, как вы можете облегчить эту проблему в будущем.
• Посмотрите на даты, за которые вы и ваша команда сейчас отвечаете. Вы действительно взяли на себя те обязательства, про которые думаете, что вы их взяли? Есть ли варианты поставить что-то другое, одновременно выполнив эти обязательства?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
• Вы можете узнать больше о 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. Это обеспечивает прочный фундамент, который в сочетании с Канбаном дает возможность улучшить процессы. Когда команды используют Канбан для усовершенствования, они сосредоточены на устранении потерь из процессов (в том числе муда, мура и мури – потери неровности, перегрузки и бесполезности, о которых мы узнали в главе 8).
Канбан – это технологический термин, адаптированный Дэвидом Андерсоном для разработки программного обеспечения. Вот как он описывает взаимоотношения с Lean в своей книге «Канбан. Альтернативный путь в Agile»: «Канбан-метод представляет собой сложную адаптивную систему, предназначенную для активации lean-решений в рамках организации». Есть команды, которые применяют Lean и бережливое мышление для разработки программ без использования Канбана, но на сегодняшний день это наиболее распространенный метод (и эффективный для многих agile-практиков) внедрения бережливого мышления в организацию.
Канбан отличается от гибких методологий, таких как Scrum и ХР. Scrum преимущественно ориентирован на управление проектами: объем работы, который должен быть проделан, чтобы эта работа была выполнена, и результат, необходимый пользователям и стейкхолдерам. ХР ориентирована на разработку программного обеспечения, ее ценности и практики строятся вокруг создания благоприятных условий для развития и формирования привычек, помогающих разработчику писать простой и легко изменяемый код.
Канбан помогает команде улучшить способы разработки программного обеспечения. Команда, использующая этот метод, имеет четкое представление о том, какие действия совершает при создании программного продукта, как взаимодействует с остальной компанией, как образуются потери, вызванные неэффективностью и неравномерностью, и каким образом со временем исправить ситуацию, устранив основную причину этих потерь. Когда команда улучшает способ создания ПО, это традиционно называется процессом усовершенствования. Канбан – хороший пример применения гибких идей (таких как последний ответственный момент) для создания метода усовершенствования процесса, который команды могут легко принять.
Практики Канбана позволяют стабилизировать и улучшить систему разработки программного обеспечения. Актуальный список основных практик можно найти в группе Kanban Yahoo!
Во-первых, следуйте основополагающим принципам:
• Начните с того, что вы делаете сейчас, уважайте имеющиеся роли, обязанности и должностные инструкции.
• Договоритесь об эволюционном развитии.
• Поощряйте лидерство на всех уровнях.
Затем принимайтесь за основные практики:
• визуализацию;
• ограничение числа задач в работе (WIP);
• управление потоком;
• сделайте правила явными;
• введите петли обратной связи;
• развивайтесь совместно и экспериментируйте (используя моделирование или научный подход).
На начальном этапе не требуется внедрять все шесть практик. Частичная реализация признается поверхностной и предполагает постепенное углубление, поскольку большинство практик принимаются и выполняются с большим потенциалом.
В этой главе вы узнаете о Канбане, его принципах, взаимоотношениях с Lean и практиках. Мы расскажем, как сосредоточение на потоке и теории массового обслуживания поможет вашей команде внедрить бережливое мышление в практику и создать культуру постоянного совершенствования.