Глава 8. Lean, ликвидация потерь и целостная картина
Lean – это образ мышления, ментальная модель того, как устроен мир.
Из предыдущих глав вы узнали о Scrum и XP. Каждый из этих подходов имеет практики, которые вы можете внедрить у себя, а также ценности и принципы, способные помочь всем членам группы достичь эффективного мышления. Можете считать себя членом команды, использующей Scrum, если вы присутствуете на ежедневных Scrum-митингах, используете спринты и работаете с владельцем продукта и Scrum-мастером. То же самое касается XP: если вы занимаетесь беспощадным рефакторингом, ведете разработку через тестирование, исповедуете непрерывную интеграцию и создаете инкрементальную архитектуру, то ваша команда использует ХР.
Но что объединяет XP и Scrum? Не понимая их ценностей и принципов, вы будете в итоге выполнять множество суетливых движений ради сомнительного результата «лучше-чем-ничего». Кен Швабер убежден, что, не проникнувшись коллективной ответственностью и волей к самоорганизации, невозможно получить Scrum, и ее ценности помогают вам это понять. Так же и в случае с XP: без понимания таких его ценностей, как простота и энергичная работа, вы станете рассматривать эту практику как список мероприятий – по сути ваша команда не примет изменений и вы останетесь со сложным программным обеспечением, которое трудно поддерживать.
Lean (бережливость) – это другое. В отличие от Scrum и XP, в него не входит набор практик. Этот тип мышления имеет свои ценности и принципы (в lean-терминологии они называются «инструменты мышления»), иногда его называют «бережливое мышление». Термин «бережливое» применяется в производстве в течение многих десятилетий. Он был приспособлен для разработки программного обеспечения Томом и Мэри Поппендик в первом десятилетии двадцать первого века. Мы будем использовать термин Lean (на английском языке, с заглавной буквы), чтобы обозначить эту адаптацию lean-идей применительно к гибкой разработке программного обеспечения.
В этой главе вы узнаете о Lean, ценностях, которые помогут вам постичь бережливое мышление, и инструментах, способных помочь вашей команде выявлять потери и удалять их, а также увидеть целиком систему, которую можно использовать для создания программного обеспечения.
Бережливое мышление
Lean – это образ мыслей. Давать имя способу мышления – интересная и очень полезная идея.
Вы уже знаете, что для эффективного внедрения Scrum команда должна иметь определенный настрой, а также ценности – приверженность, сосредоточенность, открытость, уважение и мужество, которые помогают ей включить именно такое мышление. XP, в свою очередь, также требует определенного образа мыслей, и XP-команды тоже используют устойчивый набор ценностей: простоту, коммуникацию, обратную связь, уважение и мужество.
Неудивительно, что и Lean приходит со своим набором ценностей, а команда, стремящаяся принять бережливое мышление, начинает именно с них.
Итак, перечислим ценности Lean.
Ликвидируйте потери
Выявите работы, выполняемые вами, но не создающие ценность, и избавьтесь от них.
Усильте обучение
Используйте обратную связь, чтобы улучшить свою работу.
Принимайте решения как можно позже
Принимайте все важные решения по проекту, обладая максимумом информации о нем, – то есть в последний ответственный момент.
Доставляйте ценность как можно раньше
Проанализируйте реальную стоимость задержек и минимизируйте ее при помощи систем вытягивания и очередей.
Раскрепостите вашу команду
Сформируйте целенаправленную и эффективную рабочую среду и объедините энергичных людей.
Добейтесь целостности
Создавайте программное обеспечение, интуитивно понятное для пользователей и работающее сообразно их ожиданиям.
Следите за общей картиной
Постарайтесь досконально разобраться в той работе, которая выполняется у вас в проекте. Примените правильные методы измерения, чтобы убедиться, что вы действительно видите даже мельчайшие детали.
Каждая ценность обладает инструментами мышления, способными помочь применить эти ценности в реальных ситуациях. Любой из этих инструментов – примерный аналог одного из принципов ХР: они используются одинаковым образом. Объясняя эти ценности, мы покажем связанные с ними инструменты мышления и то, как их использовать, чтобы помочь команде принять бережливое мышление.
Компания получит то, что она ценит, и Аgile-манифест помогает переключить восприятие ценности с процесса на людей, с документации на код, от договоров к сотрудничеству и от планов к действиям.
Удивляет ли вас, что вы уже столкнулись со многими ценностями и инструментами мышления Lean? Надеемся, что нет. Lean – это важная часть Agile. Когда Том и Мэри Поппендик занимались адаптацией идей бережливого производства к разработке программного обеспечения, они активно заимствовали их из других частей Agile, включая XP. Но еще важнее то, что производственные идеи, которые они использовали, были важной частью разработки ПО и управления качеством в течение десятилетий. Кен Швабер также опирался на множество подобных идей при создании Scrum. Напомним, в частности, что ежедневный Scrum-митинг – это аналог формализованной проверки состояния дел.
Поскольку данная книга описывает несколько гибких методологий, мы уже рассмотрели некоторые важные части Lean. Вновь коснемся их – и единственная причина, по которой они занимают относительно немного места в этой главе, состоит в том, что вы уже достаточно глубоко их изучили. Это бесспорно ключевые элементы бережливого мышления.
.
Рис. 8.1. Вы уже немало знаете о Lean, потому что есть много совпадений между ценностями бережливого мышления, Scrum и XP
Еще раз взгляните на список ценностей Lean. Одна из них – принимать решения как можно позже – наверняка покажется вам очень знакомой. Scrum и XP в значительной степени опираются на похожую идею. Scrum-команды применяют ее к планированию. Команды XP – к проектированию систем и разработке кода. Lean-практики делают это тоже. По сути эта ценность использует ту же концепцию, называемую последним ответственным моментом.
Еще одна знакомая вам ценность – «усильте обучение». Вам уже известны два основных инструмента ее мышления – обратная связь и итерации. С данными концепциями мы встречались при знакомстве со Scrum и XP. Эта ценность имеет также два других инструмента мышления: синхронизацию и развитие на основе установок. Синхронизация очень похожа на непрерывную интеграцию и коллективную собственность в XP, а развитие на основе установок мы рассмотрим чуть ниже.
Вы узнали также о ценности, называющейся «раскрепощение команды», и используемых в ней приемах мышления: самоопределении, мотивации, лидерстве и экспертизе. Эти идеи почти идентичны тем, что лежат в основе ХР-практик команды как целого и ее энергичной работы – в стремлении избежать работы допоздна, оказывающей столь серьезное отрицательное воздействие на программное обеспечение. В главе 4 говорилось, что команды также дорожат этим как частью такой scrum-ценности, как сосредоточенность. Разработчики, сами управляющие своей жизнью, создадут более качественное программное обеспечение. Позже вы узнаете, что важный аспект видения общей картины состоит в необходимости делиться информацией о проекте со всеми, включая руководителей. Именно поэтому scrum-команды так ценят открытость.
Здесь написано то, о чем уже говорилось в главе 4, но нелишне напомнить.
Обязывают не планы, а наши обязательства. План – это просто удобный способ их фиксации. Обязательства даются людьми и документируются в планах проекта. А это не просто бумажка. Это зафиксированная информация, и все держат ее в голове.
Так что же это значит? Когда вы создаете план, то сначала принимаете окончательное решение и лишь потом записываете его.
Еще раз посмотрите на рисунок 8.1. В сноске к нему сказано, что приверженность (ответственность) – это важная часть XP и Lean, а Scrum прямо называет их своей ценностью. При этом Lean идет дальше, уточняя идею обязательств добавлением некоторых моментов. Это, во-первых, вариантное мышление, или понимание разницы между тем, за что вы отвечаете, и тем, что вы имеете право (но не обязаны) делать. А во-вторых, развитие на основе установок. Это такое выполнение проекта, при котором команда может прорабатывать сразу несколько вариантов его развития, чтобы сравнивать их и выбирать оптимальный.
Команды должны брать на себя обязательства[77], верно?
Например, когда одного из членов scrum-команды просят о поставке конкретного компонента через считаные месяцы, он не может сказать пользователям и менеджерам: «Это Scrum, поэтому я не готов планировать что-либо за пределами текущего спринта. Поговорим об этом через пару месяцев». Вместо этого scrum-команда использует бэклог продукта и поэтому может работать с бизнесом, понимая, что является ценным для заказчиков. Она берет на себя обязательство поставлять самое ценное ПО в конце текущего спринта, в следующем и в каждом новом в ближайшие несколько месяцев.