не начнет создавать оба.
Разработчики, занимаясь непростыми проблемами, не очень понимают, что участвуют в их решении, пока не измажут о них свои собственные руки. Каждый программист наверняка помнит случай, когда начинали работать над «простой» проблемой, а потом выяснялось, что она сложная. Это характерно для команд по разработке программного обеспечения. Порой, взяв на себя обязательство по решению простой проблемы, команда обнаруживает, что все гораздо сложнее, чем ожидалось. Тогда разработчики оказываются перед выбором: разорвать обязательство или поставить «костыль» (некачественный, неэлегантный код) и нарастить техническую задолженность.
Разработка на основе установок поможет scrum-команде справиться с ситуацией, когда непонятно, какое из двух решений сработает лучше. Вместо того чтобы создавать модель данных или объектно ориентированное решение, команда добавляет обе задачи на доску задач, чтобы отработать два варианта. Возможно, это выглядит расточительством, но на самом деле экономит много сил в долгосрочной перспективе. Если один из этих подходов приводит к лучшему решению, а другой – к «костылям» с большим количеством технических долгов, то для команды выгодно добиваться реализации обоих вариантов – по крайней мере в течение времени, требующегося разработчикам для продумывания решений по обоим возможным путям. Это даст максимум информации для принятия верного решения, и ответственный момент для него наступит после того, как будет потрачено время на отработку проблемы.
Другой пример разработки на основе установок – регулярно используемое командами А/Б-тестирование. Такая практика часто встречается при создании пользовательских интерфейсов и улучшении работы пользователей, ее с большим успехом реализовывали в Amazon, Microsoft и других компаниях. При A/Б-тестировании команда создает два или более решения – например, два различных макета или варианта решения для веб-интерфейса (А– и Б-макеты). Команда будет случайным образом передавать A– либо Б-вариант бета-тестерам – или, в некоторых проектах, реальным пользователям – и контролировать результаты тестирования и показатели успеха. Компании неоднократно убеждались: хотя такой подход требует больше времени и усилий, чтобы создать два комплексных решения, он хорошо окупается в долгосрочной перспективе, поскольку появляется возможность провести сравнительные замеры и доказать, что одно из решений успешнее другого. Более того, зачастую менее удачное решение тоже приносит пользу, например функции, которые разработчики позднее включат в конечный продукт.
Эти примеры показывают, как команды применяют разработку на основе установок и вариантное мышление. Но важнее другое: они демонстрируют, как идеи, уже знакомые вам по Scrum и XP, дают основу для изучения Lean и бережливого мышления.
Lean (или бережливое мышление) – это название образа мыслей. Подобно другим agile-методам, оно имеет свои ценности, помогающие понять и принять его.
Lean – мышление, а не методика, поэтому в нем не представлены практики, которые помогут выполнять проекты.
Есть ценности, общие для бережливого мышления и более широкого круга agile-решений: как можно более позднее принятие решений (или принятие решений в последний ответственный момент) и усиление обучения (при помощи обратной связи и итерации).
Lean-ценность «расширение прав и возможностей команды» очень похожа на scrum-ценность «сосредоточенность» и XP-ценность «энергичная работа».
Вариантное мышление означает умение понимать разницу между вариантами и обязательствами, а также принимать такие решения по проекту, которые дадут множество вариантов в будущем.
Когда команда использует разработку на основе установок, она исследует более одного варианта решений за один раз и выбирает лучший – например, когда она выполняет А/Б-тестирование для проверки нескольких параметров пользовательского интерфейса на выборке пользователей, выбирает функции, работающие лучше всего.
Кэтрин – первый разработчик
Тимати – второй разработчик
Дэн – их руководитель
Акт I. И вот еще что…
– Ну, все. Встряхнитесь и работайте.
Кэтрин было неприятно слышать это от руководителя. Их встреча только что закончилась, и он был недоволен тем, как команда разрабатывает новую функцию, добавленную по его просьбе. Двое программистов столкнулись с нехваткой времени, но он не дал им его, тем самым поставив под удар сроки. Он не сказал, что их ждут неприятности, если они не сделают работу вовремя, но всем и так было ясно, что задержки – это плохо.
В прошлом году Кэтрин чувствовала себя гораздо счастливее. Она тогда работала в маленькой компании, имевшей всего одну команду программистов. Все вместе они трудились над созданием приложения для мобильного телефона, которое обеспечивало дополнительными функциями его камеру. Команда была небольшой, но весьма инновационной, и все чувствовали, как им хорошо работается вместе.
Их труд высоко ценили коллеги по отрасли. Поэтому казалось естественным, что крупный интернет-гигант выразил желание купить компанию. Кэтрин и ее товарищи по команде были очень рады, потому что слышали об этой компании много хорошего: там царит творческая атмосфера, в холодильниках полно прохладительных напитков, у сотрудников гибкий график работы, есть также много других льгот. Когда сделка наконец была завершена, все они получили большие бонусы (им оплатили студенческие кредиты!) и команда переехала в новый красивый офис в центре города.
– Почему все так плохо закончилось, Тимати? – спросила Кэтрин, выходя из кабинета руководителя. – Ведь было так здорово. Что случилось?
Тимати был программистом и работал в команде почти столько же времени, сколько и Кэтрин.
– Я не знаю, – сказал он. – Похоже, все тянется вдвое дольше, чем следует.
– Я не против работать больше, – вздохнула Кэтрин. – Но возникает ощущение, что, сколько бы мы ни напрягались, мы все равно опаздываем.
– Да, – согласился Тимати. – И нам никогда не выбраться из этого замкнутого круга.
– Кэти, Тим! У вас есть минутка?
Кэтрин и Тимати переглянулись.
– Это звучит не слишком обнадеживающе, – сказала она. Дэн, руководитель, снова позвал их в свой кабинет.
– Я только что разговаривал по телефону с одним из топ-менеджеров социальной сети нашей компании, и у меня отличные новости. – Так уж повелось, что все новые запросы к команде преподносились как «отличные новости!» – У него была идея по интеграции данных социальной сети с нашим приложением для камеры. Я хочу, чтобы вы взялись за это немедленно. Я пришлю письмо со списком функций, которые мы должны добавить, и обязательно включите их в следующий спринт.
Тимати сказал:
– Хорошо. Мы на середине спринта. Что нужно удалить?
Кэтрин бросила на него быстрый взгляд. Она знала, что добром это не кончится.
Во время разговора Дэн смотрел в свой экран. Он медленно поднял глаза на Тимати.
– Вы думаете, у вас недостаточно ресурсов, чтобы сделать работу в этом цикле?
– Ну, э-э, у нас есть четыре другие функции, и одна из них уже закончена… – забормотал Тимати.
Дэн оборвал его:
– Это отговорки. Все эти дни я не видел никого, кто бы задерживался допоздна или слишком перенапрягался. Я пришел в шесть утра – офис был пуст. Ты говоришь, что мы не можем уделить этому чуть больше времени? Это не слишком большая работа. Я мог бы и сам потихоньку писать код.
Кэтрин поняла, к чему он клонит. Она уже слышала нечто подобное, и в прошлый раз все закончилось не слишком хорошо. Буквально только что она превратила в программное обеспечение точно такие же «хорошие новости» в виде запроса от Дэна, пропуская модульные тесты и накапливая технический долг. И пользователи это заметили – если прежде их отзывы были четырех– и пятизвездочными, то теперь они упали до двух-трех звезд.
– Попросите всех сконцентрироваться и выполнить задание. Это не займет много времени, зато мы заслужим признательность всей компании.
Создание героев и магическое мышление
Среди руководителей бытует ошибочное мнение, будто, установив высокую планку, можно мотивировать сотрудников трудиться с утроенной энергией для достижения заданной цели. Если дать каждому члену команды большие цели и сжатые сроки, то все будут стремиться оказаться на высоте. Есть ощущение, что такой «грубо индивидуалистический» подход к построению команд позволит устранить бюрократию. Каждый человек уполномочен решать свои проблемы, и в результате вся команда становится высокоэффективной.
Такой индивидуалист-менеджер поощряет практику «геройства». Программист, который работает допоздна, по выходным и создает для команды сложные решения, получает наивысшее признание и попадает в число лучших сотрудников. Такой «герой» поднимается на вершину не благодаря командной работе, не потому, что делает лучший продукт или совершенствует деятельность всей команды, а лишь из-за сидения в офисе допоздна и в выходные.
Это непродуктивный, хотя довольно традиционный подход. Но группы по-прежнему приходят к выводу, что такое «индивидуалистское» мышление способствует созданию плохого ПО. Почему?
Эффективное программное обеспечение получается тогда, когда команды работают вместе. Мы уже знакомы с подходами к командной работе в Scrum (самоорганизация и коллективная ответственность) и XP (творческая и энергичная среда, где люди собираются вместе как целая команда). Многие agile-команды постоянно размышляют над тем, как улучшить взаимодействие и создать комфортные условия труда, помогающие разрабатывать качественное программное обеспечение.