Книга: Постигая Agile

Бережливое мышление

Бережливое мышление

Lean – это образ мыслей. Давать имя способу мышления – интересная и очень полезная идея.

Вы уже знаете, что для эффективного внедрения Scrum команда должна иметь определенный настрой, а также ценности – приверженность, сосредоточенность, открытость, уважение и мужество, которые помогают ей включить именно такое мышление. XP, в свою очередь, также требует определенного образа мыслей, и XP-команды тоже используют устойчивый набор ценностей: простоту, коммуникацию, обратную связь, уважение и мужество.

Неудивительно, что и Lean приходит со своим набором ценностей, а команда, стремящаяся принять бережливое мышление, начинает именно с них.

Итак, перечислим ценности Lean.

Ликвидируйте потери

Выявите работы, выполняемые вами, но не создающие ценность, и избавьтесь от них.

Усильте обучение

Используйте обратную связь, чтобы улучшить свою работу.

Принимайте решения как можно позже

Принимайте все важные решения по проекту, обладая максимумом информации о нем, – то есть в последний ответственный момент.

Доставляйте ценность как можно раньше

Проанализируйте реальную стоимость задержек и минимизируйте ее при помощи систем вытягивания и очередей.

Раскрепостите вашу команду

Сформируйте целенаправленную и эффективную рабочую среду и объедините энергичных людей.

Добейтесь целостности

Создавайте программное обеспечение, интуитивно понятное для пользователей и работающее сообразно их ожиданиям.

Следите за общей картиной

Постарайтесь досконально разобраться в той работе, которая выполняется у вас в проекте. Примените правильные методы измерения, чтобы убедиться, что вы действительно видите даже мельчайшие детали.

Каждая ценность обладает инструментами мышления, способными помочь применить эти ценности в реальных ситуациях. Любой из этих инструментов – примерный аналог одного из принципов ХР: они используются одинаковым образом. Объясняя эти ценности, мы покажем связанные с ними инструменты мышления и то, как их использовать, чтобы помочь команде принять бережливое мышление.

Удивляет ли вас, что вы уже столкнулись со многими ценностями и инструментами мышления 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 идет дальше, уточняя идею обязательств добавлением некоторых моментов. Это, во-первых, вариантное мышление, или понимание разницы между тем, за что вы отвечаете, и тем, что вы имеете право (но не обязаны) делать. А во-вторых, развитие на основе установок. Это такое выполнение проекта, при котором команда может прорабатывать сразу несколько вариантов его развития, чтобы сравнивать их и выбирать оптимальный.

Например, когда одного из членов scrum-команды просят о поставке конкретного компонента через считаные месяцы, он не может сказать пользователям и менеджерам: «Это Scrum, поэтому я не готов планировать что-либо за пределами текущего спринта. Поговорим об этом через пару месяцев». Вместо этого scrum-команда использует бэклог продукта и поэтому может работать с бизнесом, понимая, что является ценным для заказчиков. Она берет на себя обязательство поставлять самое ценное ПО в конце текущего спринта, в следующем и в каждом новом в ближайшие несколько месяцев.

Сравните это с административно-командным стилем управления, когда менеджер проекта пишет очень подробный план, который обязывает людей работать над конкретными задачами в течение следующего месяца. Если команда берет на себя обязательства поставить определенную функцию, для которой требуется большой объем детального планирования, то у каждого участника возникает иллюзия, будто все находится под контролем. Руководитель проекта может указать конкретные задачи, которые разработчик будет выполнять, скажем, через четыре недели во вторник в 10:30. У людей появляется ощущение, что команда уже продумала все варианты и стремится пойти наилучшим путем. Проблема состоит в том, что в действительности они ни за что не отвечают. Нет достаточного объема информации, чтобы сделать это. Есть только одна вещь, не вызывающая сомнений: план, согласно которому программист будет делать что-то конкретное во вторник в 10:30 четыре недели спустя. Но это почти наверняка неверно[78].

Поэтому вместо подробного планирования каждого задания и принятия на себя ответственности за эти детализированные задачи scrum-команды самоорганизуются и коллективно обязуются предоставлять ценность. То есть никто не требует, чтобы конкретный разработчик выполнил определенную задачу, скажем, во вторник в 10:30 утра через четыре недели. Принятие решений оставляют на более поздний (последний) ответственный момент (возможно, ежедневную scrum-планерку через четыре недели).

Однако scrum-команда не принимает на себя обязательство поставить определенные задачи бэклога спринта до его начала. И даже после начала спринта владелец продукта может изъять задачи из спринта, если они больше не имеют смысла. Формируя меньшее обязательство – поставить ценность – вместо завершения конкретных невыполненных работ, она оставляет эти решения и обязательства на последний ответственный момент.

Когда спринт стартует, элементы его бэклога могут восприниматься командой как обязательства, потому что они обсуждались в ходе планирования спринта и представлены на доске задач. Но это не обязательства, а варианты. Вы знаете это, так как владелец продукта может удалить их из спринта. И если команда узнает ближе к концу спринта, что они не будут выполнены в срок, то она вытолкнет их в следующий спринт. В этом одна из причин хорошей работы Scrum: мы отделяем истинное обязательство (поставку ценного работающего программного обеспечения в конце спринта) от опциональных вариантов (предоставления конкретного функционала к определенной дате).

Заставить людей думать о вариантах вместо обязательств сложно, потому что не всегда легко понять, что означает обязательство. Никто не любит неожиданно брать на себя обязательства. Большинство из нас бывали на таких собраниях, где руководитель требует от члена команды назвать дату и тот нервно ерзает в кресле и пытается уйти от ответа. Так бывает, когда руководство считает, что проект «погорел» по вине команды, не выполнившей взятое на себя обязательство. Нервная реакция заставляет его заняться микроменеджментом, требуя от всех членов команды по отдельности принятия обязательств в отношении множества краткосрочных задач. В такой обстановке разработчики не спешат брать на себя ответственность.

Как проекты доходят до точки, в которой боссы и менеджеры проекта теряют доверие к команде, неоднократно проваливавшей свои обязательства? Это происходит потому, что, хотя отдельные люди и могут уклоняться от ответственности (особенно под прессингом руководства), команды имеют склонность к ее чрезмерной фиксации. Иногда это связано с желанием погеройствовать – программист обещает больше, чем может сделать. А порой потому, что ответственность вознаграждается: это характерно для тех, кто привык обещать, а потом как ни в чем не бывало извиняться за непредвиденные обстоятельства, помешавшие проекту. («Мы никак не могли это предугадать!») В компаниях, где привыкли обвинять и спасать свою шкуру (CYA), подход «пообещать и извиниться», конечно, не обеспечивает эффективные поставки программного обеспечения, но зато дает возможность получать высокую зарплату и сохранять свою должность.

Повторим основную мысль: руководители склонны требовать принятия обязательств, а команды часто их завышают.

Задача на scrum-доске проходит через три состояния: «сделать», «в процессе» и «сделано». Если задача находится в состоянии «сделать», то это все-таки опция, а не обязательство. И даже в ходе выполнения задания команда может решить на ежедневном scrum-митинге изменить направление работы, если это имеет смысл. В главе 4 мы говорили о том, что scrum-команда не тратит много времени на моделирование и отслеживание зависимостей между задачами, потому что они в основном полезны для составления проектного плана. Вместо этого команда может ежедневно добавлять и удалять задачи на доске задач во время scrum-митинга. Но эти задания – варианты, а не обязательства: они не имеют пока сроков и нет такого понятия, как «поздняя» задача, которая приводит оставшуюся часть проекта к срыву дедлайна. Это поощряет команду к альтернативному мышлению, потому что она привержена только цели и может в любое время изменить задачи, чтобы достичь ее более эффективным способом, основываясь на какой-либо вновь обнаруженной информации.

Приведем пример того, как scrum-команда использует вариантное мышление. Скажем, во время планирования спринта она разбила историю на четыре задачи, основанные на предположениях, сделанных о хранении данных в базе, и включающие задачу проектирования базы данных, которая, вероятно, должна быть выполнена ее администратором (Database administrator, DBA). Спустя две недели разработчик обнаруживает, что нужные данные уже есть в базе в другом формате. И для него гораздо полезнее самому создать объект или сервис, чем собирать данные в прежнем формате, который может использоваться остальной системой. Для scrum-команды это хорошая новость! Теперь она удалит задачу с доски задач на следующем ежедневном scrum-митинге, освобождая время в спринте, чтобы добавить еще один пункт бэклога или прояснить некоторые технические вопросы.

В то же время для традиционной водопадной команды тот факт, что задача должна быть выполнена кем-то другим, способен вызвать осложнения: теперь менеджер проекта вынужден перераспределять ресурсы, потому что для этой задачи уже не нужен администратор, а это может разорвать множество зависимостей внутри проекта и затронуть другие проекты. Если план проекта содержал много обязательств, которые теперь должны быть пересмотрены, то налицо проблема. Менеджеру проекта захочется вернуться к команде и потребовать, чтобы она в любом случае использовала базу данных. Или технический архитектор предполагал, что команда собиралась использовать его архитектуру, зависящую от базы данных, а теперь это обязательство нарушается.

Многие разработчики ощущают, что их попросили пойти на ненужные или даже вредные технические компромиссы некие руководители, недостаточно разбирающиеся в проекте, – например, менеджер проекта или технический архитектор. С точки зрения программиста команду просят нарушить целостность программного обеспечения. А с позиции менеджера проекта или архитектора все выглядит так, будто разработчик нарушает обязательства. У каждого есть причина обвинить другого.

Проблема заключается в том, что разработка дизайна не должна стоять на первом месте – если его рассматривают как вариант, то команде легче создать лучшее ПО, а руководителю проекта и архитектору не придется менять свои планы и чувствовать себя ущемленными.

Но как добиться того, чтобы и руководство, и члены команды брали меньше обязательств и воспринимали большее количество «окончательных» решений в качестве вариантов?

ХР дает ясный ответ на этот вопрос – применять инкрементальное (пошаговое) проектирование. Когда команда создает простые компоненты и каждый из них выполняет что-то одно, это позволяет комбинировать их множеством различных способов. Рефакторинг и разработка через тестирование помогают поддерживать эти компоненты в максимально независимом состоянии.

Иными словами, отделенные, независимые компоненты создают варианты.

При возникновении новой идеи или обнаружении нового требования, если компоненты крупные и между ними много зависимостей, то команда потратит большую часть своих усилий на разделение этого кода путем «стрельбы дробью». Но команда XP, использующая инкрементальную архитектуру, сохраняет свои варианты открытыми. Она добавит только минимальный код, который должен удовлетворять новым требованиям, проведет рефакторинг и продолжит использовать разработку через тестирование. Команда прибавит минимум зависимостей, что позволит ей в дальнейшем сохранить максимум открытых вариантов.

Так XP и scrum-команды практикуют вариантное мышление в том, как они планируют свою работу и проектируют ПО. Но есть ли что-то такое, что команда может сделать, чтобы явно создавать и применять варианты в своем проекте?

Да. Когда команда практикует разработку на основе установок, она целенаправленно тратит время на обсуждение своих возможностей и меняет планы на сегодня, чтобы иметь больше возможностей в будущем. Дополнительная работа позволит команде предложить несколько вариантов, и люди надеются, что она окупит себя, давая им максимум информации, что позволит принять верное решение позже.

Допустим, в команде есть бизнес-проблема, которая имеет ряд возможных технических решений, – например, наша scrum-команда обнаружила во время спринта, что она не нуждается в DBA для внесения изменений в базу данных. Как быть, если команда не знает, какое решение лучше – объектно ориентированное или с использованием базы данных? Это очень распространенная ситуация в проектах разработки программного обеспечения. Часто неизвестно, какое из двух решений лучше, пока команда по крайней мере не начнет создавать оба.

Разработчики, занимаясь непростыми проблемами, не очень понимают, что участвуют в их решении, пока не измажут о них свои собственные руки. Каждый программист наверняка помнит случай, когда начинали работать над «простой» проблемой, а потом выяснялось, что она сложная. Это характерно для команд по разработке программного обеспечения. Порой, взяв на себя обязательство по решению простой проблемы, команда обнаруживает, что все гораздо сложнее, чем ожидалось. Тогда разработчики оказываются перед выбором: разорвать обязательство или поставить «костыль» (некачественный, неэлегантный код) и нарастить техническую задолженность.

Разработка на основе установок поможет scrum-команде справиться с ситуацией, когда непонятно, какое из двух решений сработает лучше. Вместо того чтобы создавать модель данных или объектно ориентированное решение, команда добавляет обе задачи на доску задач, чтобы отработать два варианта. Возможно, это выглядит расточительством, но на самом деле экономит много сил в долгосрочной перспективе. Если один из этих подходов приводит к лучшему решению, а другой – к «костылям» с большим количеством технических долгов, то для команды выгодно добиваться реализации обоих вариантов – по крайней мере в течение времени, требующегося разработчикам для продумывания решений по обоим возможным путям. Это даст максимум информации для принятия верного решения, и ответственный момент для него наступит после того, как будет потрачено время на отработку проблемы.

Другой пример разработки на основе установок – регулярно используемое командами А/Б-тестирование. Такая практика часто встречается при создании пользовательских интерфейсов и улучшении работы пользователей, ее с большим успехом реализовывали в Amazon, Microsoft и других компаниях. При A/Б-тестировании команда создает два или более решения – например, два различных макета или варианта решения для веб-интерфейса (А– и Б-макеты). Команда будет случайным образом передавать A– либо Б-вариант бета-тестерам – или, в некоторых проектах, реальным пользователям – и контролировать результаты тестирования и показатели успеха. Компании неоднократно убеждались: хотя такой подход требует больше времени и усилий, чтобы создать два комплексных решения, он хорошо окупается в долгосрочной перспективе, поскольку появляется возможность провести сравнительные замеры и доказать, что одно из решений успешнее другого. Более того, зачастую менее удачное решение тоже приносит пользу, например функции, которые разработчики позднее включат в конечный продукт.

Эти примеры показывают, как команды применяют разработку на основе установок и вариантное мышление. Но важнее другое: они демонстрируют, как идеи, уже знакомые вам по Scrum и XP, дают основу для изучения Lean и бережливого мышления.

Оглавление книги