Чистый Agile. Основы гибкости Мартин Роберт
Всегда готовы
Самое последнее, чего от нас ожидают клиенты и руководство — что мы, программисты, будем как ненормальные переносить сроки поставки программного обеспечения. Но такие опоздания в мире разработки происходят сплошь и рядом. Причина таких задержек часто в том, что разработчики пытаются оснастить программу сразу всем функционалом, а не делать в первую очередь наиболее важные функции. Покуда есть функции, которые реализованы, протестированы или документированы лишь наполовину, программой пользоваться нельзя.
Другая причина переноса сроков — это доводка программ до стабильного состояния. Разработчики зачастую не принимают в расчет непрерывное тестирование, когда они наблюдают за тем, чтобы не было сбоев. Если в течение какого-то времени не обнаружено никаких сбоев, разработчики могут смело рекомендовать программное обеспечение к развертыванию.
Agile помогает решить эти проблемы с помощью простого правила, которое гласит, что программа должна быть технически готова к развертыванию в конце каждой итерации. «Технически готова» означает, что с точки зрения разработчиков продукт достаточно стабилен в техническом плане для развертывания. Код написан чисто, а тесты успешно пройдены.
Это значит, что работа, проделанная в течение итерации, включает в себя написание всего кода, прохождение всех тестов, написание всей документации и доводку до стабильного состояния всех историй, реализованных во время этой итерации.
Если в конце каждой итерации программа технически готова к развертыванию, то само развертывание производится по решению клиента, а не из технических соображений. Клиент может посчитать, что для развертывания не хватает функционала, или может отложить развертывание по причинам, связанным с условиями рынка или обучением пользователей. В любом случае ПО соответствует необходимому качеству и технически готово к развертыванию.
Возможно ли такое, что программа технически готова к развертыванию в конце каждой недели или двух?
Конечно, да! Просто команде не нужно браться за непосильное количество историй, чтобы успеть выполнить все задачи и обеспечить развертываемость программы до окончания итерации. Также разработчикам стоит автоматизировать большую часть работ по тестированию.
Как и с точки зрения бизнеса, так и с точки зрения клиентов ожидание постоянной технической готовности продукта вполне естественно. Когда клиент видит, что функция работает, он думает, что работа над ней завершена. Он никак не ожидает того, что нужно подождать еще пару месяцев, чтобы обеспечить гарантию качества и стабильности. Ему не понять того, что функция заработала лишь потому, что программисты для демонстрации возможностей пошли в обход нерабочего кода.
Стабильная производительность
Вы, наверное, заметили, что зачастую команды программистов продвигаются очень быстро первые несколько месяцев, пока проект еще нов. Когда не существует основного кода, который замедляет работу, можно написать много рабочего кода за короткое время.
К сожалению, через некоторое временя в коде появляется бардак. Если в коде не поддерживать порядок, то он будет тянуть команду назад и замедлять ход проекта. Больше бардака — меньше скорость работы команды. Чем меньше скорость, тем сильнее поджимают сроки, а следовательно, больше спешки, приводящей к еще большему беспорядку. Принцип снежного кома приводит к тому, что команда практически впадает в ступор.
Руководители, озадаченные медленной работой, могут принять решение добавить специалистов в команду и увеличить производительность. Но, как мы уже знаем, расширение команды замедляет работу еще на несколько недель.
Есть надежда, что по прошествии нескольких недель новички выйдут на требуемый уровень производительности и проект пойдет быстрее. Только вот кому придется их обучать? Тем, кто и сотворил бардак. Новички, конечно, вберут от своих учителей не только самое лучшее.
Что еще хуже, они будут равняться на имеющийся код. Они посмотрят на уже написанный код и сделают вывод, как нужно работать в этой команде. А затем будут точно так же «бардачить». Именно поэтому производительность неуклонно падает, несмотря на подключение новых специалистов.
Менеджеры могут повторить эти действия еще несколько раз, ведь делать одно и то же и ждать иного результата — это показатель вменяемости руководства в некоторых организациях. В конечном итоге боссы узнают правду, но будет уже поздно. Уже ничто не сможет остановить неотвратимое погружение в бездну медлительности.
Отчаявшись, менеджеры спросят разработчиков, что можно сделать для повышения производительности. У разработчиков уже готов ответ. Уж они-то понимают, что делать. Они только и ждут того, чтобы их спросили.
И они отвечают: «Надо все переделывать».
Представьте, в какой ужас приходят менеджеры. Сколько денег и времени было вложено в проект! И что мы видим? Разработчики советуют выбросить все наработки и начать проект с чистого листа!
И как считаете, верит ли руководство разработчикам, когда те обещают, что «в этот раз будет все по-другому»? Конечно, нет! Они ж не дураки, чтобы поверить этому. Но что же им теперь делать? Производительность уже и так ниже плинтуса. Такими темпами работа не может продолжаться. Поэтому после многочисленных стенаний они соглашаются на рефакторинг.
У разработчиков засверкал в глазах огонь. «Слава богу! Наконец-то можно вернуться в те времена, когда трава зеленее и код чище», — скажут они. Но, конечно же, все не так просто, как кажется. Команда разбивается на два лагеря. Отбирается лучшая десятка — ударная группа, те самые орлы программирования, которые больше всех ответственны за беспорядочный код. Им выделяют отдельную комнату. Теперь они поведут всех остальных в мир рефакторинга. Остальные же их на дух не переносят, потому что из-за них приходится сопровождать тот отстой, который уже написан.
Откуда наша ударная группа берет требования? Есть ли на сегодняшний день какой-нибудь документ, где представлены требования? Да. Это код, который уже написан. Этот код — единственный документ, который точно дает понять, как должна выглядеть программа после рефакторинга.
Поэтому орлы вчитываются в написанный код, пытаясь сообразить, что с этим кодом не так и как нужно писать новый. Между тем другие программисты вносят изменения в старый код, устраняют ошибки и добавляют новый функционал.
Гонка продолжается. Ударная группа пытается поймать движущуюся добычу. И как Зенон показал в своей апории об Ахиллесе и черепахе, поймать движущуюся добычу не так-то просто. Каждый раз, когда они доходят до этапа разработки, на котором находился написанный код, этот код уже изменился.
Чтобы доказать, что Ахиллес все равно догонит черепаху, нужно применить математический анализ. В разработке ПО это не всегда удается. Я работал в компании, где новое программное обеспечение не получалось развернуть в течение десяти лет. Клиентам обещали представить новый пакет программ еще восемь лет назад. Однако им постоянно не хватало функционала в новых программах, старые справлялись со своими задачами лучше. Поэтому клиенты не стали пользоваться новым пакетом программ.
Несколько лет спустя клиенты просто перестали обращать внимание на обещания о предоставлении новой системы.
С их точки зрения, подходящей системы никогда не было и не могло появиться.
В то же время компания, занимавшаяся написанием программ, оплачивала работу сразу двух команд разработчиков: тех самых ударных групп и сопровождающих. В конечном итоге руководство очень расстроилось и уведомило клиентов о том, что компания собирается развернуть новый пакет программ, несмотря ни на какие возражения. У клиентов началась истерика, но она не шла ни в какое сравнение с той, которую закатили разработчики, та самая ударная группа, а точнее сказать — то, что осталось от их команды. Всю команду, которая занималась разработкой с самого начала, повысили до руководящих постов. Нынешние члены команды дружно встали и в один голос заявили: «Нельзя это поставлять, вы что? Это же фуфло. Надо все переделывать!»
Да-да, еще одна байка от Дяди Боба. Она основана на реальных событиях, но я чуть-чуть приврал для красного словца. И все же основной посыл вполне правдив. Масштабный рефакторинг — это чудовищно дорого и редко востребовано.
Клиенты и менеджеры не рассчитывают, что разработчики сбавят темпы. Скорее, они думают, что если реализация функции заняла одну или пару недель в начале проекта, то и через год подобная функция будет реализована в те же сроки. Они ожидают, что производительность будет стабильна на протяжении всего проекта.
Разработчики должны ожидать этого не меньше. Благодаря непрерывному поддержанию чистоты архитектуры, проекта и кода настолько, насколько это возможно, сохраняется высокая производительность, и команда не попадает в ловушку медлительности и перепроектирования.
Далее вы увидите, что такие методы Agile, как тестирование, парное программирование, рефакторинг и простота структуры проекта, помогают избежать попадания в эту ловушку. А игра в планирование — это противоядие от давления сроков, подталкивающего разработчиков в эту ловушку.
Недорогие изменения
Программное обеспечение — это словосочетание. Со словом «программное» все понятно. Рассмотрим слово «обеспечение». Оно означает, что пользователь обеспечен функционалом, необходимым для успешного выполнения своих задач. Получается, что программное обеспечение — это программы, обладающие необходимым функционалом. А полнота функционала невозможна без изменяемости кода. Программное обеспечение изобрели потому, что возникла необходимость легко и быстро вносить изменения в функциональность техники. Если мы хотим, чтобы функционал изменялся только на аппаратном уровне, то пользуемся понятием «аппаратное обеспечение».
Разработчики беспрерывно сетуют на то, что требования к продукту изменяются. Мне часто доводилось слышать заявления вроде: «Это изменение полностью рушит архитектуру нашей программы». Солнышко, у меня для тебя плохие новости. Если изменение требований ломает архитектуру твоей программы, то твоей архитектурой можно только подтереться.
Мы, разработчики, должны радоваться изменениям, потому что ради них и работаем.
Изменение требований — основное правило игры. Эти изменения дают нам работу и кормят нас. Наша работа заключается в способности мириться с изменениями требований и находить решения, которые будут относительно недороги.
Эффективность программного обеспечения измеряется в том числе и тем, насколько безболезненно в него можно внести какие-либо изменения. Клиенты, пользователи и руководители ожидают, что программное обеспечение будет можно легко изменить и что стоимость таких изменений будет соизмеримой и как можно ниже.
Далее вы узнаете о том, как методы Agile, разработка через тестирование, рефакторинг и простота проектирования при одновременном применении и с наименьшими усилиями помогают вносить изменения в программы без ущерба для них.
Постоянное совершенствование
Со временем люди повышают уровень своего мастерства. Художники лучше пишут картины, певцы лучше исполняют песни, строители лучше возводят здания и так далее. То же должно быть справедливым и для отрасли разработки программного обеспечения. Чем дольше существует программа, тем лучше она должна становиться.
Структура и архитектура программного обеспечения со временем должны становиться только лучше.
Структура кода должна становиться лучше и, соответственно, должно произойти улучшение производительности программы. Разве это не очевидно? Разве это не то, что вы ожидаете от команды, работающей над чем-либо?
То, что мы с течением времени работаем все хуже — самое серьезное обвинение и наиболее очевидное свидетельство нашей некомпетентности.
Самое безответственное отношение, которое только может быть, пожалуй, проявляется в случае, когда разработчики настроены на то, что по мере продвижения код будет становиться беспорядочным, а программа — неработоспособной, нестабильной и уязвимой.
Постоянное и уверенное совершенствование — вот чего от нас ждут клиенты, пользователи и руководители. Они ожидают, что «детские болезни» программы со временем пройдут, что в дальнейшем она будет становиться только лучше. Методы Agile, а именно разработка через тестирование, парное программирование, рефакторинг и простота структуры проекта, призваны укрепить здоровые ожидания.
Компетенция без страха и упрека
По какой причине большая часть программ со временем не становится лучше? Эта причина — страх. Если быть точнее, страх перед изменениями.
Представьте, что вы смотрите на экран, на котором находится написанный ранее код. Первая мысль, которая приходит в голову: «Господи, какой ужас! Нужно почистить его». Но следующая мысль будет примерно такой: «Нет, я в это не полезу!» А почему? Да потому что вы думаете, что если влезть в код, то он перестанет работать. А если он перестанет работать, виноваты будете вы. Так вы отказываетесь от того единственного, что может улучшить код, — от его очистки.
В вас говорит страх. Вы боитесь кода, и этот страх вынуждает вас вести себя некомпетентно. Вы чувствуете некомпетентность и боитесь проводить очистку кода, потому что исход непредсказуем. Вы позволили коду, который создали своими собственными руками, стать таким самостоятельным, что боитесь что-либо делать для его улучшения. Это в высшей мере безответственно.
Клиенты, пользователи и менеджеры ожидают, что вы профессионал без страха и упрека. Они ожидают, что если в коде будут ошибки или избыточность, вы это увидите, исправите и вычистите. Вы не допустите разрастания и усугубления несовершенств и сделаете все возможное для поддержания высокого качества и чистоты кода.
Так как же избавиться от этого страха? Представьте, что у вас есть кнопка, а возле нее две лампочки — красная и зеленая. Представьте, что когда вы нажимаете на кнопку, то загорается одна из них. Зеленая — если программа работает правильно, красная — если неправильно. Представьте, что нажатие на кнопку и получение результата занимает лишь считаные секунды. Насколько часто вы будете на нее нажимать? Вы будете нажимать на нее без остановки. Вы будете нажимать на нее постоянно. Каждый раз, когда вы внесете изменения в код, вы нажмете на кнопку, чтобы понять, все ли работает правильно.
Теперь представьте, что на экране вы видите уродливый код. Первая мысль, которая проносится у вас в голове: «Надо его почистить». И после этого вы просто берете и чистите его, нажимая кнопку после каждого внесенного изменения, чтобы удостовериться в том, что все работает.
Больше нет никакого страха. Вы спокойно чистите код. Чтобы устранить недостатки кода, можно использовать методы Agile: рефакторинг, простоту структуры проекта и парное программирование.
Где взять эту кнопку? Разработка через тестирование дает вам ту самую кнопку. Если вы применяете этот метод дисциплинированно и решительно, то достигнете компетенции без страха и упрека.
Контроль качества
Контроль качества должен показать, что неполадок нет. Продукт должен быть сделан так, чтобы после прохождения тестирования специалист сообщил, что все работает должным образом. Каждый раз, когда при прохождении контроля качества обнаруживаются какие-то ошибки, разработчики должны выяснить, что пошло не так во время работы, и устранить недостатки, чтобы в следующий раз такого не было.
Специалисты по контролю качества (Quality Assurance) должны задаться вопросом, почему они застряли в конце системы проверки процесса, которая всегда работает. Так что пусть проверяют кого-нибудь другого, для этого есть более достойные кандидаты.
Методы Agile, а именно приемочное тестирование, разработка через тестирование, непрерывная интеграция, позволят не бояться контроля качества.
Автоматизация тестирования
На рис. 2.1 можно увидеть руки. Это руки руководителя QA-отдела. В них он держит оглавление плана для тестирования, проводимого вручную. В нем содержится 80 тысяч тестов, которые должна проводить армия индусов раз в полгода. Чтобы провести это тестирование, нужно потратить миллион долларов.
QA-менеджер принес мне этот документ, когда вышел от своего начальника. Его начальник, в свою очередь, до этого был в кабинете финансового директора. Это был 2008 год. Начало мирового финансового кризиса. Финансовый директор каждые полгода сокращал этот миллион вдвое. Руководитель отдела контроля качества, протягивая мне план, попросил отобрать из списка тестов половину, которую можно не проводить.
Я объяснил ему, что неважно, какие тесты будут проводить, а какие нет. Важно то, что мы так не узнаем, работает ли половина программ.
Рис. 2.1. Оглавление плана тестирования вручную
Тестирование вручную всегда в итоге провальное и неизбежно приводит к такому положению дел. Вы только что прочитали наиболее очевидное доказательство того, что тестирование вручную несостоятельно, поскольку оно дорого стоит и всегда попадает под сокращение финансирования.
К тому же существует еще один коварный нюанс в доказательство того, что тестирования вручную лучше избегать.
Разработчикам редко удается представить продукт на контроль качества вовремя. Получается, что у специалистов по качеству остается меньше времени на требуемые тесты, чем отводилось изначально. Поэтому им приходится на свое усмотрение выбирать, какие тесты нужны больше, чтобы закончить проверку в положенные сроки. Некоторые тесты остаются без внимания. Это провал.
Кроме того, люди не роботы. Требовать от них выполнять ту же работу, что и машины, — дорого, неэффективно и бесчеловечно. Для специалистов, проводящих контроль качества, есть работа и занятия гораздо интереснее — там, где можно проявить воображение и творчество, присущие человеку. Но вернемся к нашим баранам.
Клиенты и пользователи ожидают, что каждый новый релиз пройдет тщательное тестирование. Никто даже не подумает, что разработчики решили что-либо не тестировать лишь по той причине, что не было времени или средств. Поэтому нужно автоматизировать все тесты, какие только возможно. Вручную стоит тестировать только то, что нельзя подвергнуть автоматической проверке, и тогда, когда требуется творческий подход, который применяется в исследовательском тестировании[32].
Методы Agile, а именно приемочное тестирование, разработка через тестирование, непрерывная интеграция, позволят оптимизировать тестирование.
Друг за друга горой
Как технический директор я ожидаю от команды слаженной работы. Что значит «слаженная работа»? Представьте футбольную команду, гоняющую мяч по полю. Один из игроков спотыкается и падает. Что делают остальные игроки? Они закрывают образовавшуюся брешь, защищая проход к воротам, и стараются увести мяч как можно дальше.
На борту корабля у каждого своя работа. Незаменимых нет, каждый умеет выполнять не только свою, но и чужую работу. Потому что на корабле необходимо выполнение всех работ.
Так же и в команде разработчиков. Если Боб захворал, его подменит Джек. Это значит, что Джеку нужно знать, чем занимается Боб, где Боб хранит все свои исходные файлы, скрипты и тому подобное.
Я ожидаю от каждого члена любой команды разработчиков готовности подменить товарища. В свою очередь, каждый член команды разработчиков может положиться на своих коллег, если вдруг что-то случится. Личное дело каждого сделать так, чтобы кто-то из команды мог вас подменить.
Если Боб спец по части баз данных и вдруг заболел, я не опасаюсь того, что работа над проектом из-за этого подвиснет. Кто-то, даже если он особо не «шарит» в базах данных, должен занять место Боба. Я ожидаю, что никто в команде не станет утаивать сведения, — сведениями нужно делиться. Если требуется перевести половину команды на другой проект, я уверен, что половина всех сведений никуда не исчезнет вместе с ушедшими, но останется в команде.
Методы Agile, а именно парное программирование, «одна команда» и коллективное владение, призваны оправдать ожидания технического директора.
Честность оценок
Я ожидаю, что будут какие-то оценки сроков и что они будут честными. Самая честная оценка — это «я не знаю». Тем не менее эта оценка не полноценна. Нельзя знать все. Вы хоть что-то, да знаете. Так что я ожидаю, что ваши оценочные суждения будут основаны на имеющихся знаниях.
Например, вы можете не знать, сколько времени займет та или иная задача, но можете сопоставить ее с другой и сделать вывод на ее основе. Можно не знать, сколько времени уйдет на создание страницы входа в личный кабинет, но можно предугадать, что на страницу смены пароля уйдет примерно половина времени, потраченного на страницу входа. Относительные оценки, как та, что приведена выше, весьма ценны. Мы еще в этом убедимся на страницах этой книги.
Вместо относительной оценки можно высказать предположения с некоторым вероятностным разбросом. Например, вы можете предположить, что на страницу входа уйдет где-то от пяти до пятнадцати дней, а в среднем на это уходит двенадцать дней. Такие оценки сочетают в себе все имеющиеся знания, из которых можно вывести некоторую вероятность и передать сведения руководству.
Методы Agile, а именно «игра в планирование» и «одна команда», помогут провести оценку запланированных задач.
Умение говорить «нет»
Хотя и очень важно стремиться найти решение задачи, лучше сказать «нет», если такого решения не найдено. Просто осознайте, что вас взяли на работу даже не потому, что вы хорошо пишете код, а потому что вы можете сказать «нет», когда это нужно. Вы, программисты, — как раз те, кто знает, что возможно, а что нет. Как технический директор я ожидаю от вас сведений, дабы не упасть в пропасть. Я рассчитываю на это независимо от того, поджимают ли сроки, независимо от того, что желают услышать менеджеры. Просто ответьте «нет», когда это действительно нужно.
Метод Agile «одна команда» научит честно говорить «нет», если того требует положение дел.
Тяжело в учении, легко в бою
Как технический директор я ожидаю от вас стремления постоянно учиться. В нашей сфере все быстро меняется. И мы должны быть способны меняться вместе с ней. Так что век живи — век учись! Иногда компания сможет себе позволить отправить сотрудника на курсы или конференции. А иногда — закупить обучающую литературу и видеоуроки. Но даже если этого всего не будет, нужно искать возможность учиться самому, не дожидаясь помощи дяди из вашей компании.
Метод Agile «одна команда» поможет достичь новых вершин в обучении.
Мудрый коуч
Как технический директор я ожидаю от вас и ваших коллег взаимного обучения. Правда в том, что лучше всего мы учимся тогда, когда сами кого-то учим. Поэтому когда в команду приходят новички, не стесняйтесь их учить чему-то. Учитесь помогать друг другу. И снова на помощь приходит метод Agile «одна команда», который научит вас друг друга поддерживать.
Билль о правах
Во время встречи в Сноуберде Кент Бек заявил, что цель Agile — построить мост над пропастью, существующей между клиентами и разработчиками. Для этого Кент Бек, Уорд Каннингем, Рон Джеффрис и некоторые другие составили «Билль о правах».
Обратите внимание на то, что права клиентов и права разработчиков дополняют друг друга. Они подходят друг к другу, словно шестерни одного механизма. Благодаря им существует некий баланс ожиданий между одними и другими.
Права клиента
У клиента есть следующие права:
• Ознакомиться с общим планом, знать, что и когда можно получить и за какие деньги.
• Получать наилучшую, насколько это возможно, отдачу от каждой итерации.
• Отслеживать ход работ, назначать необходимые тесты, получить рабочее и многократно протестированное программное обеспечение.
• Изменять решения, функциональность и приоритеты, не неся непомерных расходов.
• Получать сведения о графике работ, изменениях сроков, чтобы вовремя принять решение о том, как сократить объем работ и успеть к нужному числу. Отменить проект в любое время и получить полезный рабочий код, который оправдывает текущие вложения средств.
Права разработчика
У разработчика есть следующие права:
• Знать, что требуется от команды, а также иметь четкое представление о поставленных приоритетах.
• Выполнять работу качественно, несмотря ни на какие обстоятельства.
• Получать помощь от коллег, руководителей и самих клиентов.
• Проводить оценку задачи и уточнять ее в зависимости от обстоятельств.
• Брать на себя личную ответственность и не позволять возлагать на себя лишнее.
Все эти утверждения звучат весьма громко. Давайте рассмотрим их по очереди.
Клиенты
В данном контексте слово «клиент» относится к представителям бизнеса. Сюда относятся непосредственно клиенты, менеджеры, начальники, менеджеры проекта и им подобные, то есть все, кто способен нести ответственность за соблюдение сроков и расходование средств, либо те, кто платит деньги и получает выгоду от использования программы.
Клиенты могут потребовать предоставить им общий план на ознакомление, также имеют право знать, что и когда можно получить и за какие деньги.
Многие утверждают, что такое предварительное планирование не является частью методологии Agile. Самое первое из прав клиента уже опровергает это высказывание. Безусловно, в бизнесе требуется планирование. И, конечно, в план должны входить график работ и их стоимость. Разумеется, план должен быть как можно более точным и осуществимым.
Именно на последнем пункте мы часто не знаем, что делать, так как единственный способ построить точный и выполнимый план можно только в процессе выполнения проекта. Невозможно, почти ничего не делая, создать нормальный план. Так что мы, разработчики, должны убедиться, что наши планы, оценки и графики работ правильно создают представление об уровне нашей неопределенности, и найти способы снизить этот уровень, чтобы гарантировать это право.
Проще говоря, нельзя соглашаться с невозможностью изменить объем и сроки работ. И объем работ, и сроки должны быть гибкими. Мы представляем такую гибкость с помощью кривой вероятностей. Например, согласно нашей оценке, вероятность того, что мы выполним первые десять историй к назначенному числу — 95 %. С вероятностью 50 % мы выполним вовремя следующие пять. И с вероятностью 5 % мы выполним еще пять историй в требуемый срок.
У клиентов есть право ознакомиться с этим планом, основанным на вероятности, потому что они не могут вести дела без плана.
Клиенты имеют право получать наилучшую, насколько это возможно, отдачу от каждой итерации.
Agile позволяет разбить объем работ на временные отрезки, называемые итерациями. Клиенты имеют право ожидать от разработчиков работы над наиболее важными задачами в любое время, а от каждой итерации — максимально возможную пользу для бизнеса. Приоритеты устанавливаются клиентами на этапе планирования в начале каждой итерации. Клиенты выбирают истории, которые приносят наибольшую отдачу от капиталовложений и которые команда разработчиков может, по ее оценкам, выполнить за итерацию.
Клиенты имеют право на отслеживание хода работ, назначение необходимых тестов, получение рабочего и многократно протестированного программного обеспечения.
Это право кажется очевидным с точки зрения клиента. Конечно, у них есть право отслеживать, как продвигается ход работ. Безусловно, у них есть право определять показатели того, что работа действительно продвигается. Несомненно, у них есть право незамедлительно и неоднократно проверять, действительно ли ход работ соответствует требуемым показателям.
Клиенты имеют право на изменения решений, функциональность и приоритеты, не неся при этом непомерных расходов.
В конце концов, мы говорим об отрасли разработки программного обеспечения. Цель программного обеспечения — легко изменять функциональность техники, которую мы используем. Первым делом ПО изобрели затем, чтобы функциональности придать гибкость. Поэтому, конечно же, у клиентов есть право на изменение своих требований.
Клиенты имеют право на получение сведений о графике работ, изменениях оценки сроков, чтобы вовремя принять решение о том, как сократить объем работ и успеть к нужному числу.
Клиент может отменить проект в любое время и получить полезный рабочий код, который оправдывает текущие вложения средств.
Обратите внимание, что у клиентов нет права требовать, чтобы их график соответствовал графику команды разработчиков. Их право на управление графиком ограничено правом на изменение объема работ. Самое главное, чем наделяет клиента это право — правом знать, что график работ находится под угрозой срыва, и иметь возможность своевременно привести его в соответствие с текущими условиями.
Разработчики
В данном контексте разработчиком признается каждый, кто принимает участие в написании кода. Это понятие включает в себя программистов, QA-специалистов и бизнес-аналитиков.
Разработчики имеют право на ознакомление с тем, что требуется от команды, а также на четкое представление о поставленных приоритетах.
Опять же сосредоточимся на знании. У разработчиков есть право на получение точных требований и сведений о том, какие из них важны и насколько. Конечно, требования ограничены возможностью их выполнимости примерно так же, как и сроки сдачи проекта. Как и с оценкой сроков, не всегда получается точно выразить требования. Не стоит забывать и о том, что у клиентов есть право изменять свои решения.
Это право применимо только в рамках одной итерации. За пределами итерации требования и приоритеты будут смещаться и изменяться. Но в пределах итерации у разработчиков есть право считать, что они незыблемы. Однако всегда нужно помнить, что разработчики могут отказаться от этого права, если считают изменения требований несущественными.
Разработчики имеют право на качественное выполнение работы, несмотря ни на какие обстоятельства.
Это должно быть самое главное право среди всех прочих. У разработчиков есть право делать свою работу хорошо. Клиенты не имеют права требовать от команды вести разработку спустя рукава. Или, другими словами, у клиентов нет права вынуждать разработчиков портить свою профессиональную репутацию или переступать через профессиональную этику.
Разработчики имеют право на помощь от коллег, руководителей и самих клиентов.
Такая помощь может выражаться по-разному. Программисты могут просить друг у друга помощи в решении задач, сверке результатов, в изучении фреймворка и во многом другом. Разработчики могут попросить клиентов лучше объяснить требования или уточнить приоритеты. По большей части, этот постулат дает разработчикам право на взаимодействие. И с правом просить о помощи приходит и ответственность — помогать, когда просят.
Разработчики имеют право на оценку задачи и ее уточнение в зависимости от обстоятельств.
Никто не сможет оценить задачу за вас. И если вы даете оценку задаче, у вас всегда есть возможность ее изменить по мере появления новых факторов. Ведь оценки основаны на предположениях. Конечно, эти догадки небезосновательны, но они и остаются догадками. Эти догадки становятся точнее со временем. Оценка не может быть обязательством.
Разработчики имеют право самостоятельного принятия на себя ответственности и недопущения возложения на себя лишнего.
Профессионалы принимают предложения по работе, а не назначение заданий. Разработчик имеет полное право говорить «нет», если его не устраивает какая-либо работа или задание. Может быть такое, что разработчик не уверен в своих способностях выполнить ту или иную задачу или, может быть, считает, что кто-то другой справится лучше, чем он. Или, допустим, разработчик отказывается из личных или моральных соображений[33].
В любом случае за право выбора приходится платить. Принятие предложения налагает ответственность. Согласившийся разработчик принимает на себя ответственность за качественное выполнение задания, за постоянное уточнение оценок, чтобы выверять график работ, и за взаимодействие со всей своей командой. Он не должен стесняться просить о помощи, когда она ему необходима.
Программирование в команде подразумевает тесное сотрудничество, где есть старшие и младшие программисты. У команды есть право согласованно решать, кто чем будет заниматься. Технический руководитель может попросить разработчика взяться за задание, но ни в коем случае никого не принуждать.
Заключение
Agile — это набор методов, помогающий разработчикам достигать и поддерживать высокий уровень профессионализма. Специалисты, которые придерживаются этих методов, принимают и отвечают разумным ожиданиям руководителей, заинтересованных сторон и клиентов. Agile также наделяет определенными правами как разработчиков, так и клиентов и накладывает на них некоторые обязательства. Взаимное соблюдение прав и принятие ожиданий, признание методов Agile — основа этической нормы для сферы разработки ПО.
Agile не процесс. Agile не модное увлечение. Agile не просто набор правил. Скорее, Agile — это набор прав, ожиданий и методов, который составляет основу профессиональной этики специалистов, связанных с разработкой программного обеспечения.
Глава 3. Методы взаимодействия с клиентами
Существует куча методов взаимодействия с клиентами, которые разработчику нужно соблюдать, чтобы преуспеть. Среди них планирование, небольшие и частые релизы, приемочное тестирование и «одна команда».
Планирование
Как провести оценку проекта? Самое простое: его нужно разбить на составные части, а затем провести их оценку. Подход-то хорош, но что делать, если эти части слишком велики, чтобы достоверно их оценить? Тогда нужно просто разбить эти части на меньшие по объему и оценивать уже их. Уверен, вы подумаете, что это попахивает рекурсией.
Как далеко можно зайти в такой разбивке? Проект можно делить вплоть до каждой строчки кода. Это как раз то, чем занимаются программисты. Программистом можно назвать того, кто постиг искусство разбиения задач на отдельные строки кода.
Если вы хотите провести наиболее точную и достоверную оценку проекта, разбейте его вплоть до отдельных строк кода. Да, это займет какое-то время, но зато вам станет доподлинно известно, сколько времени займет проект, ведь вы его уже выполнили.
Конечно, это уже никакая не оценка. Оценки построены на догадках: нам нужно знать, сколько времени займет выполнение проекта, не выполняя его непосредственно. Хочется, чтобы оценка проекта не стоила дорого. Поэтому оценка по определению не может быть точной. Неточность позволяет нам сократить сроки, необходимые для проведения оценки. Чем ниже степень точности, тем меньше времени понадобится на оценку.
Это не означает, что оценка должна быть неточной. Нужно давать как можно более точную оценку, но точную настолько, чтобы это не было непомерно дорого. Вот пример для лучшего понимания. По моим оценкам, я закончу свой жизненный путь в течение следующей тысячи лет. Это совершенно верно, но точность очень низка. Я буквально не потратил ни минуты на то, чтобы провести настолько достоверную оценку, потому что она совсем неточная. Такая хоть и достоверная, но неточная оценка обозначает временной отрезок, в течение которого оцениваемое событие произойдет почти наверняка.
Задача разработчиков — потратить как можно меньше времени, чтобы произвести достоверную оценку, и при этом в наибольшей степени сократить временной промежуток.
Трехвариантный анализ
Есть один метод, который неплохо подходит для больших задач. Это трехвариантный анализ. Такие оценки включают в себя три положения: лучший случай, допустимый случай и худший случай. С помощью такого анализа можно предречь исход с различной вероятностью. Худший случай — это когда мы уверены в сроках на 95 %. Допустимый — на 50 %, а лучший — на 5 %.
Например, я могу быть на 95 % уверен, что задание будет выполнено в течение трех недель. Только на 50 % я могу быть уверен, что оно будет выполнено за две недели. И 5 % вероятности, что получится уложиться в одну неделю.
Можно представить вероятность и иначе. Представим, что у нас 100 схожих заданий. Пять из них будут выполнены в течение недели, 50 — в течение двух недель, а 95 из них — в течение трех недель.
Существует целый математический метод, связанный с управлением трехвариантными оценками. Кому интересно, могу предложить изучить технику оценки и анализа программ и проектов (PERT)[34]. Это мощный метод управления крупными проектами и портфелями проектов. Если вы отдельно не изучали эту технику, не стоит думать, что прочитав о ней, вы уже все знаете. PERT выходит далеко за рамки графиков, которые вы видели в Microsoft Project.
Несмотря на то что трехвариантный анализ хорошо подходит для долгосрочной оценки всего проекта, он слишком неточен для повседневного управления, которое необходимо в течение проекта. Для этого у нас есть другой подход — единицы сложности историй.
Истории и единицы сложности
Метод единиц сложности историй позволяет соблюсти достоверность и точность благодаря коротким циклам обратной связи, с помощью которых можно многократно выверить оценку в сравнении с действительностью. Сначала точность невысока, но через несколько циклов она повышается до приемлемого уровня. Но прежде чем мы углубимся в метод, поговорим немного о самих историях.
Пользовательская история — это сокращенное описание функции программы с точки зрения пользователя. Например:
Когда я веду машину, то нажимаю сильнее на педаль газа, чтобы поехать быстрее.
Это один из наиболее распространенных видов пользовательских историй. Некоторым людям нравится так. Другие предпочитают ее в более коротком виде: «ускориться». Оба вида достаточно хороши. Обе истории представляют собой упрощенную версию того, что описывается большим количеством слов. Многое из того, что описано в истории, еще не произошло. Это произойдет ближе к моменту разработки функции программы. А вот само действие начинается тогда, когда историю уже пишут. В то время разработчики и заинтересованные стороны обсуждают некоторые возможные подробности истории и затем записывают все в упрощенном виде.
Еще рано точно говорить о подробностях, поэтому подробности опущены, а описание упрощено. Мы стараемся отложить уточнение подробностей как можно на более долгий срок, до тех пор пока не начнется разработка по этой истории. Поэтому оставим историю в сокращенном виде как предпосылку для дальнейших действий[35].
Как правило, мы записываем истории на каталожных карточках. Понимаю-понимаю. С чего бы мы использовали такую примитивную древность, когда в современном мире у нас есть компьютеры, планшеты и прочее, спросите вы? Но выходит, что возможность держать карточки у себя в руках, передавать их друг другу через стол, писать на них и делать с ними многое другое представляется чрезвычайно важной.
Иногда автоматизированные средства могут их заменить, я расскажу о них в другой главе. Но сейчас будем считать, что истории написаны на карточках.
Вспомните, что во Вторую мировую войну боевые действия планировались[36] с помощью карточек, поэтому я считаю этот метод проверенным.
Истории для банкоматов
Давайте представим, что мы находимся на нулевой итерации и наша команда пишет истории для банкомата. Что представляют собой эти истории? Первые три довольно легко вычислить: выдача наличных, внесение наличных и перевод. Конечно, нужно научить банкомат идентифицировать пользователя. Можно назвать эту историю «вход». А раз есть вход, значит, вероятно, должен быть и выход.
Теперь представим, что у нас есть пять карточек. Их будет почти наверняка больше, как только мы начнем по-настоящему углубляться в работу банкомата. Мы можем представить, что есть такие задачи, как аудит, платеж по кредиту и много всего прочего. Но давайте пока что остановимся на пяти карточках.
Что у нас на них? То, о чем мы недавно упоминали — вход, выход, выдача наличных, внесение наличных и перевод. Конечно, это не все слова, которые мы перечислили во время нашего исследования. Во время встречи мы обговорили много подробностей. Мы обсуждали, как пользователь осуществляет вход посредством того, что вставляет карту в приемник и вводит пин-код. Мы обсуждали, что собой представляет внесение наличных, как их вставляют в купюроприемник и как он пересчитывает эти средства. Мы обсуждали, как выдаются наличные средства и что делать в случае, если купюры застряли или просто закончились. Мы прорабатывали многие из этих подробностей.
Пока что все эти подробности неточны, поэтому мы их и не записываем. Мы записываем только слова. Нет ничего плохого в том, что вы сделаете несколько пометок на карточке, если вам нужны напоминания по каким-то вопросам, но это необязательно. На карточки не накладывается формальных ограничений.
Отказ от подробностей возможен благодаря дисциплине. И это непросто. Каждый член команды посчитает нужным так или иначе обсудить все подробности, ничего не упустив. Сдерживайте эти порывы!
Как-то раз я работал с менеджером проекта, который настаивал на том, что нужно записывать на карточке подробности абсолютно каждой истории. Карточки с историями были разбиты на единицы сложности, а сами единицы сложности были написаны мельчайшим шрифтом. Их было невозможно прочесть, и они стали непригодными. На них было столько нюансов, что оценить задания просто не оставалось шансов. Составить график работ по ним не получалось. Пользы от них не было никакой.
Хуже того, в каждую карточку с историей была вложена уйма усилий, поэтому от них нельзя было просто избавиться.
Именно временная нехватка подробностей делает историю осуществимой, планируемой и оцениваемой. Истории должны создаваться с небольшими затратами, потому что многие из них придется изменить, разделить, объединить или даже забыть. Просто не забывайте о том, что они являются заменителями, а не требованиями.
Теперь у нас есть кипа карточек, созданных во время нулевой итерации. Остальные создадут позже, по мере возникновения новых идей и функций. На самом деле создание историй никогда не прекращается. Истории постоянно пишут, изменяют, отбрасывают и, что самое главное, развивают в ходе проекта.
Оценка историй
Представьте, что эти карточки лежат на столе напротив вас, а вокруг стола сидят остальные разработчики, тестировщики и заинтересованные стороны. Все вы встретились для того, чтобы оценить истории, помещенные на эти карточки. Еще состоится много встреч вроде этой. Они будут проводиться каждый раз, когда будут добавлены новые истории или уточнено что-то насчет старых. Стоит ожидать, что такие встречи будут непринужденными, но закономерными для каждой итерации.
Однако еще начало нулевой итерации, и это самая первая, оценочная встреча. До этого оценка историй не проводилась.
Итак, мы выбираем из кипы историю средней сложности. Допустим, это история «вход». Многие из нас присутствовали при написании этой истории, поэтому слышали разнообразные подробности, которые, как представляли себе заинтересованные стороны, должны быть приведены в ней. Мы, скорее всего, попросим партнеров рассмотреть эти подробности сейчас, чтобы убедиться в том, что понимаем сложившиеся обстоятельства одинаково.
Потом мы оценим реализацию истории в пунктах. История «вход» получит 3 единицы по сложности разработки соответствующей функции (рис. 3.1). Почему 3? А почему бы и нет? История «вход» средняя по сложности, поэтому она получает средний балл. Три — это средний балл при шестибалльной шкале оценки историй.
Рис. 3.1. История «вход» получает три единицы сложности
Теперь история «вход» становится эталоном. С ней будут сравнивать все истории при проведении оценки. Так, например, выход из системы гораздо проще, чем вход в нее. Поэтому история «выход» получает единицу. Выдача наличных, вероятно, в два раза сложнее, чем вход, поэтому эта история получает 6 единиц. Внесение наличных представляет собой примерно то же самое, что и выдача, однако эту историю реализовать чуть легче. Отдадим ей 5 единиц. И, наконец, реализация перевода не сложнее, чем реализация входа, поэтому она получает те же 3 единицы.
Мы записываем эти числа в одном из верхних углов карточки с историей, которую мы оценивали. Я еще расскажу подробнее о том, как даются оценки. А сейчас давайте считать, что у нас есть кипа карточек с историями, которые мы оцениваем в единицах от 1 до 6. Почему от 1 до 6? А почему бы нет? Существует много схем, по которым можно оценивать сложность. Обычно чем проще система оценок, тем лучше.
В этой связи, возможно, у вас появится вопрос: а что в действительности измеряют единицы сложности? Возможно, вы подумаете, что время — часы, дни, недели или что-то подобное. Но нет. Скорее это единица измерения затрачиваемых усилий, а не времени. Действительно, они позволяют измерить сложность выполнения истории.
Единицы сложности историй должны быть линейными. История на карточке, оцениваемая в 2 единицы, должна быть вдвое легче той, что оценена в 4. Впрочем, линейность не обязана блюстись в совершенстве. Помните, что это оценка, поэтому точность намеренно остается размытой. На историю, оцененную в 3 единицы, Джим может потратить два дня, если больше не появится ошибок, на которые приходится отвлекаться. А Пэт сможет выполнить ее за день, если работает из дома. Эти оценки слишком расплывчаты, неотчетливы и неточны, поэтому их нельзя связывать с определенными промежутками времени.
Но в таких расплывчатых и неотчетливых оценках есть своя прелесть. Эта прелесть — закон больших чисел[37]. При многократном выполнении задания размытость сводится на нет! Это преимущество мы будем использовать позднее.
Планирование первой итерации
Между тем пришло время планировать первую итерацию. Встречу по ее планированию можно считать началом. Эта встреча по плану должна составлять одну двадцатую продолжительности всей итерации. То есть если итерация длится две недели, на нее требуется затратить полдня.
На встрече должна быть вся команда, в том числе заинтересованные стороны, программисты, тестировщики и менеджер проекта. Заинтересованные стороны должны заблаговременно прочитать оцениваемые истории и отсортировать их в порядке выполнения в зависимости от своих потребностей. Бывает, что команды оценивают приоритет историй в зависимости от требований клиента тем же способом, что и сложность выполнения задач. Есть команды, которые большее внимание уделяют приоритетам.
На встрече задача заинтересованных сторон заключается в том, чтобы выбрать истории, которые программисты и тестировщики будут выполнять во время итерации. Чтобы это сделать, им нужно знать, сколько единиц программисты, по их мнению, смогут выполнить. Количество историй за итерацию называется скоростью. Конечно, поскольку это только первая итерация, никто не может сказать, какова будет скорость хода работ. Поэтому приходится делать предположения. Предположим, что скорость будет 30 единиц за итерацию.
Важно осознавать, что скорость не является обязательством. Команда не дает обещание, что 30 единиц будут выполнены за итерацию. Она даже не обещает постараться выполнить эти 30 единиц. Эта скорость не более чем предположение о том, сколько единиц в лучшем случае будут выполнены к концу итерации. А такое предположение не может отличаться высокой достоверностью.
Прибыль от вложений
Теперь заинтересованные стороны нарисовали квадрат и поделили его на четыре участка (рис. 3.2).
Рис. 3.2. Квадрат с четырьмя участками
Приоритетные и несложные истории можно начинать выполнять хоть сейчас. Приоритетные, но более сложнее можно немного отложить на потом. Неприоритетные и несложные можно сделать за день. А о тех, что не представляют особой ценности, да еще и сложны, можно забыть.
С помощью этого квадрата выполняется расчет окупаемости инвестиций (ROI). Здесь нет формальностей и не нужно никакой математики. Заинтересованные стороны просто смотрят на карточку и делают вывод, основываясь на оценках приоритета и сложности истории.
Например: «Вход довольно важен, но также и сложен. С ним подождем. Выход тоже важен, но будет попроще. О! Давайте его! Выдача наличных… сложно, очень сложно. Но нам в первую очередь важно показать как раз эту функцию. Поэтому делайте ее».
Мы только что увидели, как заинтересованные стороны расставляют приоритеты. Заинтересованные стороны рассматривают карточки с историями и ищут те, от которых можно получить наибольшую отдачу. Они останавливаются, когда выбранные истории в сумме дают 30 единиц сложности. Это план на итерацию.
Промежуточная проверка
Читать бесплатно другие книги:
