Игра в планирование, рефакторинг кода, разработка через тестирование, непрерывная интеграция, небольшие и частые релизы, коллективное владение, одна команда и другие методы повышают частоту обратной связи и количество передаваемых сведений. Они позволяют нам своевременно понять, что что-то идет не так, чтобы внести исправления. Они дают важные уроки того, что все решения, принятые ранее, влекут за собой последствия. Команды, применяющие Agile, успешны за счет обратной связи.
Именно обратная связь помогает команде работать столь плодотворно и приводит проект к благоприятному исходу.
Простота
Следующая ценность Agile — это простота, другими словами, честность. Часто говорят, что каждую проблему в разработке можно решить, добавив еще один слой неясности. Но такие ценности, как храбрость, взаимодействие и обратная связь, существуют для того, чтобы свести количество проблем к минимуму.
Таким образом, неясность можно свести к минимуму. Решения могут быть простыми.
Это касается ПО, но также относится и к команде. Пассивная агрессия — это неясность и уклончивость. Когда вы видите проблему, но молча перекладываете ее решение на кого-то другого, вы ведете себя нечестно. Когда вы соглашаетесь с требованиями менеджера или клиента, зная о губительности последствий, вы нечестны.
Простота — это честность. Честность при написании кода и честность во взаимоотношениях и поведении. При написании кода в некотором количестве неясности есть необходимость. Неясность — это механизм, посредством которого мы снижаем сложность взаимозависимости. При работе в команде в неясности куда меньше необходимости. Большую часть времени нужно быть честным, насколько это возможно.
Сохраняйте простоту кода. Не усложняйте отношения в команде.
Методологический бестиарий
В огромном количестве существующих методик Agile легко запутаться. Я понимаю, что их тьма-тьмущая, но не обращайте на это внимания. В конце концов, независимо от того, на какие методики падет ваш выбор, вы будете подстраивать и отлаживать модель разработки под свои нужды. Таким образом, начни вы с экстремального программирования, Scrum или других 5328 методик, относящихся к Agile, вы придете к одному и тому же.
Настоятельный совет, который я могу вам дать, — это полностью перенять жизненный цикл, главным образом, технические методы. Огромное количество команд переняли лишь внешнее кольцо, определяющее взаимоотношения с клиентами, и угодили в ловушку, которую Мартин Фаулер назвал «дряблый Scrum»[56]. Признаки этой болезни: производительность медленно падает с высокого уровня в начале проекта до крайне низкого, когда проект подходит к концу. Причиной такой потери в производительности является искажение и ухудшение качества самого кода.
Оказывается, что методы взаимодействия с клиентами, предлагаемые Agile, — очень действенный способ создать огромный беспорядок. Кроме того, если вы не позаботитесь о чистоте структуры, которую выстраиваете, беспорядок будет замедлять ход работ.
Итак, выбирайте одну из методик или вообще не выбирайте. Убедитесь, что вы учитываете все дисциплины жизненного цикла. Согласуйте с командой. И вперед. Помните, что смелость, взаимодействие, обратная связь и простота позволяют с постоянством отлаживать дисциплины и методы. Не просите разрешений. Не бойтесь сделать неправильно. Просто выполняйте свою работу наперекор возникающим проблемам и настойчиво ведите проект к лучшему.
Преобразование
Переход от других методологий и моделей к Agile ведет к изменению ценностей. Ценности при использовании Agile включают в себя принятие рисков, быструю обратную связь, а также глубокое и многостороннее взаимодействие между членами коллектива, которое стирает границы внутри команды, в том числе между начальниками и подчиненными. Они также нацелены на ясное и честное поведение, а не распределение ролей и поиски крайнего. Эти ценности прямо противоположны ценностям крупных организаций, которые вкладывают значительные средства в менеджеров среднего звена, ценности которых — безопасность, преемственность, административное управление и выполнение плана.
Разве возможно перевести такую организацию на Agile? Честно говоря, это не то, в чем я достигал больших успехов, у других я подобных успехов также не наблюдал. Я видел, как затрачивалось много усилий и средств, но чтобы организация действительно осуществила переход, я видел редко. Уклад ценностей слишком отличается от тех, которых придерживаются менеджеры среднего звена, чтобы их принять.
То, что я видел, — это переход команд и отдельных специалистов, потому что команды и одиночные программисты часто следуют ценностям, которыми руководствуется Agile.
Как ни странно, руководители тоже часто разделяют ценности, присущие Agile, например: принятие рисков, ясность и взаимодействие. В том числе по этой причине они пытаются осуществить переход в своих организациях.
Дело как раз в менеджерах среднего звена. Этих ребят взяли на работу не для того, чтобы принимать риски или вносить ясность, но для того, чтобы передавать ответственность при минимальном взаимодействии. Эта проблема остро стоит во многих компаниях. Руководство и работники в организациях разделяют мировоззрение, свойственное Agile, но среднее звено мыслит наоборот. Я ни разу не видел, чтобы менеджеры среднего звена стояли в основе изменений. И вправду, с чего бы? Сопротивление таким изменениям — это их работа.
Чтобы донести свою мысль, расскажу вам несколько историй.
Саботаж
Еще тогда, в 2000 году, я участвовал в переходе одной организации на Agile. Мы заручились поддержкой начальства и программистов. Переход сулил большие надежды. Возникли сложности с техническими руководителями и архитекторами. Эти ребята, неправильно оценив положение дел, подумали, что их значимостью стали пренебрегать.
Значимость архитекторов, технических руководителей проектов и многих других в команде, работающей по Agile, отличается, но никак не преуменьшена. К сожалению, ребята не понимали этого, возможно, и по нашей вине. Может, мы не донесли до них то, насколько они были значимы для команды, или они просто не хотели учиться новым навыкам, которые бы им пригодились.
Как бы то ни было, они тайком строили план саботажа, чтобы не допустить перехода на Agile. Не буду вдаваться в подробности этого плана. Только скажу, что как-то раз их застукали за этим и немедленно выперли с работы.
Мне бы очень хотелось сказать вам о том, что после этого переход на Agile стал продвигаться семимильными шагами и закончился большим успехом. Но, увы, не могу.
Волчонок
У нас отлично получилось перевести на Agile одно из подразделений компании куда крупнее. Оно переняло опыт экстремального программирования и проделало за эти годы такую работу, что удостоилось статьи в журнале Computer world. Собственно, за этот успех вице-президент по инженерно-техническому обеспечению, руководивший этим переходом, получил повышение.
Его заменил новый вице-президент. И, подобно возмужавшему волчонку, которому посчастливилось возглавить стаю, он занялся тем, что уничтожил все наследие своего предшественника. Это коснулось и Agile. Он полностью отказался от него и вернул команде старую модель разработки, которая отличалась не в лучшую сторону.
Это привело к тому, что многие члены команды стали искать новое место работы, чего, я полагаю, и добивался новый вице-президент.
Плакса
Последнюю историю мне рассказали. Я не присутствовал в самый важный момент. Мне рассказали мои сотрудники, работавшие в то время.
В 2003 году моя компания переводила на Agile одну известную брокерскую фирму. Все шло замечательно. Велась подготовка руководителей высшего и среднего звена, а также разработчиков. Они готовились вместе. Ничего не предвещало беды.
Потом пришла пора подвести итоги. Руководство и разработчики собрались в большой аудитории. Целью было оценить ход и успешность перехода на Agile. Начальство задало вопрос: «Как обстоят дела?»
С разных сторон послышались ответы: «Все отлично!»
Потом повисло гробовое молчание, которое резко прервалось всхлипами, доносящимися сзади. Кто-то заплакал. И тогда эмоциональный подъем обрушился, и аудитория погрузилась в уныние. Вдохновения как не бывало. «Это так сложно, — донеслось до собравшихся. — Мы это просто не тянем».
После этого начальство свернуло переход.
Мораль
Мораль всех этих историй: ожидайте любых странностей.
Притворяйтесь
Может ли команда, применяющая Agile, работать в организации, где есть сильное среднее звено, которое против этой методологии? Я видел, как время от времени это происходило. Некоторые команды разработчиков спокойно руководствуются Agile во время выполнения своей работы и в то же время выполняют строгие условия, навязанные менеджерами среднего звена. Покуда менеджеры среднего звена довольны соблюдением правил и нормативов, они оставляют разработчиков в покое, не вмешиваясь в их работу.
Это как раз то, о чем говорили Буч и Парнас: «Притворяйтесь!»[57] Команда работает по Agile, не объявляя об этом, и в то же время делает все для того, чтобы менеджеры среднего звена оставались довольными. Вместо того чтобы бороться с ветряными мельницами, такие команды используют Agile на низком уровне, преподнося его так, что для менеджеров среднего звена он выглядит безопасным и совместимым с их ценностями.
Например, менеджеры хотят получить документ об анализе, проведенном на ранней стадии проекта. Команда, применяющая Agile, пишет большое количество первичного кода программы по всем канонам Agile, затем выпускает документ об анализе, запланировав череду историй по производству документации. Менеджеры получают необходимый им документ.