Файл: Роберт мартин.pdf

Глава 2. Почему же Agile?
94
Рис. 2.1. Оглавление плана тестирования вручную
Тестирование вручную всегда в итоге провальное и неизбежно приводит к такому положению дел . Вы только что прочитали наи- более очевидное доказательство того, что тестирование вручную несостоятельно, поскольку оно дорого стоит и всегда попадает под сокращение финансирования .
К тому же существует еще один коварный нюанс в доказательство того, что тестирования вручную лучше избегать .
Разработчикам редко удается представить продукт на контроль качества вовремя . Получается, что у специалистов по качеству остается меньше времени на требуемые тесты, чем отводилось из- начально . Поэтому им приходится на свое усмотрение выбирать, какие тесты нужны больше, чтобы закончить проверку в положен- ные сроки . Некоторые тесты остаются без внимания . Это провал .
Кроме того, люди не роботы . Требовать от них выполнять ту же ра- боту, что и машины, — дорого, неэффективно и бесчеловечно . Для

Разумные ожидания
95
специалистов, проводящих контроль качества, есть работа и заня- тия гораздо интереснее — там, где можно проявить воображение и творчество, присущие человеку . Но вернемся к нашим баранам .
Клиенты и пользователи ожидают, что каждый новый релиз прой- дет тщательное тестирование . Никто даже не подумает, что раз- работчики решили что-либо не тестировать лишь по той причине, что не было времени или средств . Поэтому нужно автоматизиро- вать все тесты, какие только возможно . Вручную стоит тестиро- вать только то, что нельзя подвергнуть автоматической проверке, и тогда, когда требуется творческий подход, который применяется в исследовательском тестировании
1
Методы Agile, а именно приемочное тестирование, разработка через тестирование, непрерывная интеграция, позволят оптими- зировать тестирование .
Друг за друга горой
Как технический директор я ожидаю от команды слаженной ра- боты . Что значит «слаженная работа»? Представьте футбольную команду, гоняющую мяч по полю . Один из игроков спотыкается и падает . Что делают остальные игроки? Они закрывают образо- вавшуюся брешь, защищая проход к воротам, и стараются увести мяч как можно дальше .
На борту корабля у каждого своя работа . Незаменимых нет, каж- дый умеет выполнять не только свою, но и чужую работу . Потому что на корабле необходимо выполнение всех работ .
1
Agile Alliance . Exploratory testing .Ссылка: https://www.agilealliance.org/glossary/
exploratory-testing

Глава 2. Почему же Agile?
96
Так же и в команде разработчиков . Если Боб захворал, его под- менит Джек . Это значит, что Джеку нужно знать, чем занимается
Боб, где Боб хранит все свои исходные файлы, скрипты и тому подобное .
Я ожидаю от каждого члена любой команды разработчиков готов- ности подменить товарища . В свою очередь, каждый член коман- ды разработчиков может положиться на своих коллег, если вдруг что-то случится . Личное дело каждого сделать так, чтобы кто-то из команды мог вас подменить .
Если Боб спец по части баз данных и вдруг заболел, я не опасаюсь того, что работа над проектом из-за этого подвиснет . Кто-то, даже если он особо не «шарит» в базах данных, должен занять место
Боба . Я ожидаю, что никто в команде не станет утаивать сведения, — сведениями нужно делиться . Если требуется перевести половину команды на другой проект, я уверен, что половина всех сведений никуда не исчезнет вместе с ушедшими, но останется в команде .
Методы Agile, а именно парное программирование, «одна команда» и коллективное владение, призваны оправдать ожидания техниче- ского директора .
Честность оценок
Я ожидаю, что будут какие-то оценки сроков и что они будут чест- ными . Самая честная оценка — это «я не знаю» . Тем не менее эта оценка не полноценна . Нельзя знать все . Вы хоть что-то, да знаете .
Так что я ожидаю, что ваши оценочные суждения будут основаны на имеющихся знаниях .
Например, вы можете не знать, сколько времени займет та или иная задача, но можете сопоставить ее с другой и сделать вывод

Разумные ожидания
97
на ее основе . Можно не знать, сколько времени уйдет на создание страницы входа в личный кабинет, но можно предугадать, что на страницу смены пароля уйдет примерно половина времени, потраченного на страницу входа . Относительные оценки, как та, что приведена выше, весьма ценны . Мы еще в этом убедимся на страницах этой книги .
Вместо относительной оценки можно высказать предположения с некоторым вероятностным разбросом . Например, вы можете предположить, что на страницу входа уйдет где-то от пяти до пятнадцати дней, а в среднем на это уходит двенадцать дней .
Такие оценки сочетают в себе все имеющиеся знания, из кото- рых можно вывести некоторую вероятность и передать сведения руководству .
Методы Agile, а именно «игра в планирование» и «одна команда», помогут провести оценку запланированных задач .
Умение говорить «нет»
Хотя и очень важно стремиться найти решение задачи, лучше сказать «нет», если такого решения не найдено . Просто осознайте, что вас взяли на работу даже не потому, что вы хорошо пишете код, а потому что вы можете сказать «нет», когда это нужно . Вы, программисты, — как раз те, кто знает, что возможно, а что нет . Как технический директор я ожидаю от вас сведений, дабы не упасть в пропасть . Я рассчитываю на это независимо от того, поджимают ли сроки, независимо от того, что желают услышать менеджеры .
Просто ответьте «нет», когда это действительно нужно .
Метод Agile «одна команда» научит честно говорить «нет», если того требует положение дел .

Глава 2. Почему же Agile?
98
Тяжело в учении, легко в бою
Как технический директор я ожидаю от вас стремления постоянно учиться . В нашей сфере все быстро меняется . И мы должны быть способны меняться вместе с ней . Так что век живи — век учись!
Иногда компания сможет себе позволить отправить сотрудника на курсы или конференции . А иногда — закупить обучающую ли- тературу и видеоуроки . Но даже если этого всего не будет, нужно искать возможность учиться самому, не дожидаясь помощи дяди из вашей компании .
Метод Agile «одна команда» поможет достичь новых вершин в обу- чении .
Мудрый коуч
Как технический директор я ожидаю от вас и ваших коллег вза- имного обучения . Правда в том, что лучше всего мы учимся тогда, когда сами кого-то учим . Поэтому когда в команду приходят но- вички, не стесняйтесь их учить чему-то . Учитесь помогать друг другу . И снова на помощь приходит метод Agile «одна команда», который научит вас друг друга поддерживать .
БИЛЛЬ О ПРАВАХ
Во время встречи в Сноуберде Кент Бек заявил, что цель Agile — построить мост над пропастью, существующей между клиентами и разработчиками . Для этого Кент Бек, Уорд Каннингем, Рон
Джеффрис и некоторые другие составили «Билль о правах» .
Обратите внимание на то, что права клиентов и права разработчи- ков дополняют друг друга . Они подходят друг к другу, словно ше-

Билль о правах
99
стерни одного механизма . Благодаря им существует некий баланс ожиданий между одними и другими .
Права клиента
У клиента есть следующие права:
z
Ознакомиться с общим планом, знать, что и когда можно полу- чить и за какие деньги .
z
Получать наилучшую, насколько это возможно, отдачу от каж- дой итерации .
z
Отслеживать ход работ, назначать необходимые тесты, полу- чить рабочее и многократно протестированное программное обеспечение .
z
Изменять решения, функциональность и приоритеты, не неся непомерных расходов .
z
Получать сведения о графике работ, изменениях сроков, чтобы вовремя принять решение о том, как сократить объем работ и успеть к нужному числу . Отменить проект в любое время и по- лучить полезный рабочий код, который оправдывает текущие вложения средств .
Права разработчика
У разработчика есть следующие права:
z
Знать, что требуется от команды, а также иметь четкое пред- ставление о поставленных приоритетах .
z
Выполнять работу качественно, несмотря ни на какие обстоя- тельства .

Глава 2. Почему же Agile?
100
z
Получать помощь от коллег, руководителей и самих клиентов .
z
Проводить оценку задачи и уточнять ее в зависимости от об- стоятельств .
z
Брать на себя личную ответственность и не позволять возлагать на себя лишнее .
Все эти утверждения звучат весьма громко . Давайте рассмотрим их по очереди .
Клиенты
В данном контексте слово «клиент» относится к представителям бизнеса . Сюда относятся непосредственно клиенты, менеджеры, начальники, менеджеры проекта и им подобные, то есть все, кто способен нести ответственность за соблюдение сроков и расхо- дование средств, либо те, кто платит деньги и получает выгоду от использования программы .
Клиенты могут потребовать предоставить им общий план на
ознакомление, также имеют право знать, что и когда можно
получить и за какие деньги.
Многие утверждают, что такое предварительное планирование не является частью методологии Agile . Самое первое из прав клиента уже опровергает это высказывание . Безусловно, в бизнесе требует- ся планирование . И, конечно, в план должны входить график работ и их стоимость . Разумеется, план должен быть как можно более точным и осуществимым .
Именно на последнем пункте мы часто не знаем, что делать, так как единственный способ построить точный и выполнимый план можно только в процессе выполнения проекта . Невозможно, почти

Билль о правах
101
ничего не делая, создать нормальный план . Так что мы, разработ- чики, должны убедиться, что наши планы, оценки и графики работ правильно создают представление об уровне нашей неопределен- ности, и найти способы снизить этот уровень, чтобы гарантировать это право .
Проще говоря, нельзя соглашаться с невозможностью изменить объ- ем и сроки работ . И объем работ, и сроки должны быть гибкими . Мы представляем такую гибкость с помощью кривой вероятностей . На- пример, согласно нашей оценке, вероятность того, что мы выполним первые десять историй к назначенному числу — 95 % . С вероятно- стью 50 % мы выполним вовремя следующие пять . И с вероятностью
5 % мы выполним еще пять историй в требуемый срок .
У клиентов есть право ознакомиться с этим планом, основанным на вероятности, потому что они не могут вести дела без плана .
Клиенты имеют право получать наилучшую, насколько это воз-
можно, отдачу от каждой итерации.
Agile позволяет разбить объем работ на временные отрезки, назы- ваемые итерациями . Клиенты имеют право ожидать от разработ- чиков работы над наиболее важными задачами в любое время, а от каждой итерации — максимально возможную пользу для бизнеса .
Приоритеты устанавливаются клиентами на этапе планирования в начале каждой итерации . Клиенты выбирают истории, которые приносят наибольшую отдачу от капиталовложений и которые команда разработчиков может, по ее оценкам, выполнить за ите- рацию .
Клиенты имеют право на отслеживание хода работ, назначение
необходимых тестов, получение рабочего и многократно проте-
стированного программного обеспечения.

Глава 2. Почему же Agile?
102
Это право кажется очевидным с точки зрения клиента . Конечно, у них есть право отслеживать, как продвигается ход работ . Без- условно, у них есть право определять показатели того, что работа действительно продвигается . Несомненно, у них есть право не- замедлительно и неоднократно проверять, действительно ли ход работ соответствует требуемым показателям .
Клиенты имеют право на изменения решений, функциональность
и приоритеты, не неся при этом непомерных расходов.
В конце концов, мы говорим об отрасли разработки программного обеспечения . Цель программного обеспечения — легко изменять функциональность техники, которую мы используем . Первым делом ПО изобрели затем, чтобы функциональности придать гиб- кость . Поэтому, конечно же, у клиентов есть право на изменение своих требований .
Клиенты имеют право на получение сведений о графике ра-
бот, изменениях оценки сроков, чтобы вовремя принять ре-
шение о том, как сократить объем работ и успеть к нужному
числу.
Клиент может отменить проект в любое время и получить по-
лезный рабочий код, который оправдывает текущие вложения
средств.
Обратите внимание, что у клиентов нет права требовать, чтобы их график соответствовал графику команды разработчиков . Их право на управление графиком ограничено правом на изменение объема работ . Самое главное, чем наделяет клиента это право — правом знать, что график работ находится под угрозой срыва, и иметь воз- можность своевременно привести его в соответствие с текущими условиями .

Билль о правах
103
Разработчики
В данном контексте разработчиком признается каждый, кто при- нимает участие в написании кода . Это понятие включает в себя программистов, QA-специалистов и бизнес-аналитиков .
Разработчики имеют право на ознакомление с тем, что требу-
ется от команды, а также на четкое представление о постав-
ленных приоритетах.
Опять же сосредоточимся на знании . У разработчиков есть право на получение точных требований и сведений о том, какие из них важны и насколько . Конечно, требования ограничены возможно- стью их выполнимости примерно так же, как и сроки сдачи про- екта . Как и с оценкой сроков, не всегда получается точно выразить требования . Не стоит забывать и о том, что у клиентов есть право изменять свои решения .
Это право применимо только в рамках одной итерации . За преде- лами итерации требования и приоритеты будут смещаться и из- меняться . Но в пределах итерации у разработчиков есть право считать, что они незыблемы . Однако всегда нужно помнить, что разработчики могут отказаться от этого права, если считают из- менения требований несущественными .
Разработчики имеют право на качественное выполнение рабо-
ты, несмотря ни на какие обстоятельства.
Это должно быть самое главное право среди всех прочих . У раз- работчиков есть право делать свою работу хорошо . Клиенты не имеют права требовать от команды вести разработку спустя ру- кава . Или, другими словами, у клиентов нет права вынуждать разработчиков портить свою профессиональную репутацию или переступать через профессиональную этику .