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

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

Краткий обзор Agile
59
просто невозможно узнать, насколько сложно будет выполнить задание, до тех пор пока мы не принялись за него и не завершили .
Но, как мы видим, не все так плохо .
В конце этой итерации будут выполнены некоторые фрагменты ранее запланированных задач . За счет этого мы можем предвари- тельно измерить количество работы, выполняемой за одну итера- цию . А это уже данные о том, как работа продвигается на самом деле . Если допустить, что все итерации будут схожи между собой, можно применить полученные данные для корректировки перво- начального плана и рассчитать дату окончания проекта (рис . 1 .5) .
Высокий уровень анализа и проектирования
Разбиение на подзадачи
Расчетная дата
[
]
Рис. 1.5. Расчет новой даты завершения проекта
Этот расчет, вероятно, может огорчить . Почти всегда сроки будут в значительной мере выходить за рамки тех, которые были намечены изначально . С другой стороны, новые сроки основаны на действи-
тельных данных, поэтому не получится оставить их без внимания .
Получившиеся сроки также не стоит принимать слишком близко к сердцу, так как они основаны лишь на одном замере . Погрешности при предварительном расчете данных довольно велики .

Глава 1. Введение в Agile
60
Чтобы уменьшить такие погрешности, должно пройти две, три и более итераций . По мере выполнения работ мы получаем боль- ше данных о том, сколько историй выполняется за одну итера- цию . Мы обнаружим, что их количество различается от итерации к итерации, но в среднем получается довольно стабильный расчет скорости продвижения . После четырех или пяти итераций у нас будет более ясное представление о сроках завершения проекта
(рис . 1 .6) .
По мере прохождения итераций погрешности сводятся на нет, до тех пор пока не станет ясно, что первоначальный срок выполнения проекта в корне неверен .
[
]
Высокий уровень анализа и проектирования
Разбиение на подзадачи
Расчетная дата
Рис. 1.6. Чем больше итераций, тем проще рассчитать сроки сдачи проекта
Надежда против управления
Защита от самообмана — главная цель Agile . Мы применяем Agile, чтобы избавиться от ложных надежд, которые в итоге приведут проект к краху .

Краткий обзор Agile
61
Надежды убивают проект . Надежды не позволяют команде сообщать менеджерам адекватные сведения о продвижении проекта . Когда ме- неджер спрашивает, как продвигаются дела, именно надежда толкает программистов на ответ «все хорошо!» . Надежда — никудышный способ управления проектом по разработке программного обеспе- чения . А Agile — это ушат с холодной водой, который непрерывно и своевременно возвращает к действительности .
Некоторые думают, что Agile способствует скорости выполнения проекта . Это не так . Agile никогда не ставил своей целью выпол- нить и сдать проект поскорее . Agile помогает вовремя понять то, где и насколько мы облажались . Это нужно для того, чтобы успешно справиться с поставленными задачами . Теперь посмотрим, в чем заключается задача руководителя . Для ведения проекта руководи- тели собирают данные и потом уже на их основе принимают наи- лучшие решения . Благодаря Agile можно получить необходимые данные . Много данных .
Руководители используют эти данные для того, чтобы привести проект к наилучшему исходу . Наилучший исход из возможных — не всегда то же самое, что и желаемый . Наиболее благополучный исход может очень разочаровать, особенно заинтересованные стороны, изначально вложившиеся в проект . Но наилучший ис- ход из возможных по определению является лучшим, что можно получить от проекта .
Как справиться с правилом креста?
Теперь вернемся к правилу креста в управлении проектами: хорошо, быстро, дешево, готово . Учитывая данные, полученные при выпол- нении проекта, руководство команды программистов может опреде- лить, насколько хорошо, быстро, дешево и когда будет готов проект .

Глава 1. Введение в Agile
62
Руководители, отталкиваясь от таких сведений, могут вносить из- менения в объем и график работ, коллектив и задавать планку для качества результата .
Изменения графика
Начнем с графика работ . Можно задать вопрос: а что, если про- ект будет завершен не первого ноября, а первого марта? Обычно такие разговоры напрягают . Помните, что сроки устанавливают по объективным деловым причинам . Причины, конечно же, остались теми же . Перенос сроков зачастую означает, что компания потер- пит какие-то убытки .
С другой стороны, менеджеры временами устанавливают сроки произвольно, исходя из удобства . Например, в ноябре будет про- ходить выставка, и компания просто хочет показать себя и пред- ставить свой проект . Вероятно, в марте будет проходить настолько же подходящая для него выставка . Помните, что все равно еще рано говорить о сроках окончания . Прошло только несколько итераций проекта . Лучше сказать заинтересованным сторонам, что проект будет готов в марте, чем дождаться, когда они оплатят стенд на выставке, проходящей в ноябре .
Много лет назад я вел группу разработчиков, которые работали над проектом для телефонной компании . В разгар проекта стало ясно, что сдачу проекта придется отложить на полгода . Мы сообщили об этом руководству компании как можно раньше, насколько это вообще было возможно .
Руководство компании впервые столкнулось с тем, что их преду- предили о переносе сроков вовремя . Они просто зааплодировали нам стоя .
Невероятно . Но было именно так . Один раз .

Краткий обзор Agile
63
Расширение команды
Как правило, никакие компании не хотят переноса сроков . Сроки установлены по объективным деловым причинам, и эти причины все еще имеют место . Можно увеличить количество сотрудников .
На первый взгляд кажется, что если команду расширить вдвое, то и дело пойдет вдвое быстрее .
Но на самом деле прямой взаимосвязи нет . Закон Брукса
1
гласит:
«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше» .
То, что происходит в реальности, можно увидеть на схеме, изо- браженной на рис . 1 .7 . Команда уже какое-то время работает над проектом с определенной отдачей . Приходят новички . Произво- дительность проседает в течение нескольких недель, потому что новичкам необходимо учиться, и они донимают расспросами тех, кто уже работает давно . Хочется верить, что потом новички доста- точно осваиваются и вносят свой вклад в проект .
Руководители делают ставку на то, что площадь под этой кривой будет строго положительна . Конечно, понадобится достаточно времени и усилий, для того чтобы компенсировать первона- чальные потери .
Другой фактор: безусловно, расширение коллектива стоит денег .
Зачастую это непозволительная роскошь для бюджета проекта .
Итак, давайте предположим, что команду нельзя расширять . Тогда следует ожидать изменения качества .
1
Брукс Ф . Мифический человеко-месяц, или Как создаются программные системы . СПб .: Питер, 2020 . https://ru .wikipedia .org/wiki/Мифический_че- ловеко-месяц .

Краткий обзор Agile
65
Поэтому планку качества нужно поднять до максимума и не сни- жать . Если нужно ускорить продвижение, тут без вариантов — из- вольте повышать качество .
Изменения объема работ
Это последнее из того, что можно поменять . Возможно, но это не точно, некоторые запланированные функции совсем не обязатель- но нужно предоставить именно первого ноября .
Расспросим всех заинтересованных лиц: «Господа, если вы хотите получить весь нужный вам функционал, он будет только в марте .
Если вам нужно получить полностью весь функционал к ноябрю, некоторые функции придется исключить» . На что нам наверняка ответят: «Нет, мы ничего исключать не будем! Нам нужно все!
И нужно к первому ноября» . Однако мы справедливо на то возраз- им: «Да, но вы не понимаете . Если вам нужно все, что вы хотите, придется подождать марта» . Заинтересованные стороны, вероятнее всего, продолжат бодаться: «Нет, мы хотим получить все необхо- димое! И к первому ноября!»
Такой спор будет продолжаться какое-то время, потому что никто не хочет давать задний ход . У партнеров есть моральное право требовать в этом разговоре то, что им нужно, зато у программистов есть данные . И при грамотном раскладе побеждает тот, кто владеет данными .
Если проект организован правильно, то заказчики в конечном итоге задумчиво покивают головой, соглашаясь со сказанным, и начнут тщательный пересмотр плана . По очереди, методом исключения, они определят тот функционал, который им нужен к ноябрю, как собаке пятая нога . Неприятно, но что поделать, если мы хотим адекватно организовать работу? Итак, план под-