ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.10.2023
Просмотров: 349
Скачиваний: 11
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Краткий обзор Agile
49
в том, что менеджеры знают, насколько быстро продвигается коман да и сколько работы осталось сделать для завершения про- екта . И предоставьте эти сведения в прозрачной, легкодоступной и очевидной форме — в виде двух графиков .
Почему же эти данные настолько важны? Разве можно эффективно вести управление проектом без таких данных? Мы пытались . Три десятка лет . И все получилось так, как получилось . . .
Первое, о чем нужно знать
Что в первую очередь нужно знать о проекте? Прежде чем узнать название проекта или требования к нему, прежде чем делать во- обще какие-то движения, нужно получить еще некоторые сведения .
Конечно же, это сроки . Уже после того, как выбраны сроки, их нужно зафиксировать . В обсуждении сроков нет смысла, поскольку их устанавливают в связи с объективными деловыми причинами .
Если сроком стоит сентябрь, это не просто так . Возможно, в сен- тябре намечается какая-то выставка или собрание акционеров, а может, просто-напросто закончатся средства . Какой бы ни была причина, она имеет какую-то важную подоплеку . И причина не из- менится просто оттого, что кому-то из разработчиков объем задач покажется непосильным .
В то же время требования могут изменяться в непрерывном потоке, который нельзя зафиксировать .
И на это тоже есть причина — клиенты зачастую не знают, чего именно они хотят . Они вроде и знают, какую проблему им нужно решить, но перевести такие знания в требования к проекту всегда затруднительно . Поэтому происходит постоянная переоценка и переосмысливание требований . Добавляются новые функции .
1 2 3 4 5 6 7 8 9 ... 20
Глава 1. Введение в Agile
50
Какие-то старые исчезают . Пользовательский интерфейс изменя- ется быстро — за недели, если не за дни .
Так выглядит мир разработки программного обеспечения . В этом мире сроки фиксированы, а требования постоянно меняются .
И каким-то образом в контексте всего этого разработчикам нужно благополучно завершить проект .
Собрание
Каскадная модель пророчила нам способ пойти в обход этой за- дачи . Чтобы объяснить, насколько это было соблазнительно и не- эффективно одновременно, я приведу в пример одно собрание .
Было первое мая . Большой босс созвал подчиненных в кон ференц- зал .
Босс начал: «У нас новый проект . Нужно его закончить к перво- му ноября . Никаких требований у нас пока нет . Нам их огласят в ближайшие пару недель . Сколько времени понадобится на анализ проекта?»
Мы вопросительно стали коситься друг на друга . Все молчали, боясь сказать лишнего . Никто понятия не имел, что на это от- ветить . Кто-то промямлил: «Так у нас же нет требований, от чего отталкиваться?»
«Представьте, что они есть! — завопил босс . — Вы прекрасно знаете, как все работает . Вы ж специалисты! Мне не нужны точные сроки .
Мне просто нужно как-то заполнить график . Имейте в виду, что если это займет более двух месяцев, о проекте можно уверенно забыть» .
Краткий обзор Agile
51
Кто-то вопросительно пробормотал: «Два месяца?» Началь- ник воспринял это как согласие на условия: «Отлично! Как раз то, что я думал . Теперь скажите мне, сколько займет проектиро- вание?»
И снова все застыли в недоумении, комнату наполнила мерт- вая тишина . Считаем . И осознаём, что до первого ноября всего полгода . Вывод напрашивается сам собой . «Два месяца?» — спро- сите вы .
«Совершенно верно! — большой босс лучезарно заулыбался . —
Как я и думал . И на реализацию у нас остается два месяца . Всем спасибо, все свободны!»
Многие читатели наверняка вспомнили, что что-то такое с ними уже было . У кого такого не было, что ж сказать, вы счастливчики!
Этап анализа
Итак, предположим, что мы ушли из конференц-зала и разбрелись по кабинетам . Что делать дальше? Начинается этап анализа — значит, нужно что-то анализировать . Но что именно мы называем
анализом?
Если почитать книги на тему анализа в разработке программного обеспечения, можно обнаружить, что каждый автор дает собствен- ное определение . Нет единого мнения, что такое анализ . Он может представлять собой создание структурной декомпозиции требо- ваний . А может — обнаружение и уточнение требований . Может представлять собой создание основополагающей модели данных или объекта и так далее… Лучшее определение анализа таково: это то, чем занимаются аналитики .
Глава 1. Введение в Agile
52
Конечно, есть очевидные вещи . Нам нужно оценить размер про- екта, спрогнозировать показатели основных технико-экономиче- ских и человеческих ресурсов . Нужно убедиться, что график работ выполним . Это самое малое, чего будет ожидать от нас компания .
Что бы ни называлось анализом, это как раз то, чем мы собирались заниматься ближайшие два месяца .
Это своего рода благоприятный этап проекта . Все спокойно про- сматривают страницы в интернете, проводят небольшие сделки, встречаются с клиентами и пользователями, рисуют красивые графики, попросту говоря, весело проводят время .
Затем первого июля происходит чудо . Анализ завершен .
А почему мы так считаем? Потому что уже первое июля . Если по графику этап анализа должен завершиться первого июля, зна- чит, что первого июля этот этап завершен . Мы ведь не опоздали?
Поэтому устроим небольшую вечеринку с воздушными шарами и пламенными речами, отпразднуем наш переход от этапа анализа к этапу проектирования .
Этап проектирования
А что теперь делать? Конечно же, будем проектировать . Но что представляет собой проектирование?
Об этапе проектирования программного обеспечения нам известно чуть больше . На этом этапе мы разбиваем проект на отдельные модули и проектируем интерфейсы между этими модулями . На этом этапе мы также предполагаем, сколько команд нам понадо- бится и как эти команды будут связаны между собой . В общем, нужно уточнить график работ, чтобы составить правдоподобный осуществимый план по реализации .
Краткий обзор Agile
53
Безусловно, на этом этапе что-то неожиданно меняется . Добав- ляются новые функции . Старые функции исчезают или коррек- тируются . И было бы неплохо оглянуться назад и провести ана- лиз изменений заново, но время — деньги . Поэтому мы всеми возможными способами стараемся внести изменения в проекти- рование .
И тогда случается новое чудо . Первого сентября мы внезапно за- вершаем проектирование . А почему так? Да потому что . Первое сентября . По графику работ мы должны были уже закончить . Не- зачем медлить .
Итак, еще одна вечеринка . Воздушные шары и речи . И мы проры- ваемся к следующему этапу — реализации .
Было бы замечательно провернуть такую схему еще разок . Эх, если бы точно так же можно было бы завершить этап реализации! Но так уже не выйдет . Потому что по завершении реализации требу- ется завершить и весь проект . Анализ и проектирование не при- носят плодов в двоичном виде . У них нет однозначных критериев завершенности .
Нет объективного способа узнать, проведены ли они в реальности .
Поэтому и получилось завершить эти этапы вовремя .
Этап реализации
А вот у реализации как раз есть отчетливые критерии завершен- ности . Тут уже не получится аккуратно схалтурить, выдав мнимый результат за действительный
1 1
Однако разработчики сайта healthcare.gov определенно пытались .
Глава 1. Введение в Agile
54
На этапе реализации полностью отсутствует двусмысленность задач . Мы просто пишем код . И нам приходится писать код вто- ропях, высунув язык, потому что четыре месяца просто выкинули на ветер .
Между тем требования к проекту продолжают меняться . Добав- ляются новые функции . Старые функции исчезают или коррек- тируются . Нам бы вернуться назад, провести новый анализ и вне- сти изменения в проектирование, но . . . осталось лишь две недели .
И ударными темпами мы вбиваем все эти изменения в код .
По мере того как мы смотрим на код и сравниваем его с резуль- татом проектирования, мы осознаём, что, должно быть, были не в себе на этапе проектирования, потому что сам код имеет мало общего с тем, что было изначально изображено на замечательных графиках . Но времени на раздумья нет, потому что часики тикают, а сверхурочной работы становится все больше .
Примерно 15 октября кто-то говорит: «Эй, а какое сегодня число?
Когда сдавать?» И тут мы понимаем, что осталось всего две недели и к первому ноября мы ни за что не закончим . И вдруг впервые наши заказчики узнают, что с проектом возникают какие-то не- увязочки .
Представьте их негодование . «А на этапе анализа нельзя было об этом сказать? Разве не тогда вы должны были оценить раз- мер проекта и внимательно рассчитать график работ? А на этапе проектирования почему не сказали? Разве не тогда нужно было разбить проект на модули, распределить работу по всей команде и рассчитать человеческий ресурс? Почему мы узнаем обо всем за две недели до дедлайна?»
И ведь они правы, разве нет?
Краткий обзор Agile
55
Марафон на выживание
И начинается марафон на выживание . Клиенты злятся . Заинтере- сованные стороны дошли до белого каления . Давление нарастает .
Работаем сверхурочно . Кто-то уходит с проекта . Просто ад!
И уже где-то в марте мы с горем пополам выдаем результат, кото- рый лишь наполовину удовлетворяет требованиям клиентов . Все расстроены . У всех опускаются руки . И мы клянемся самим себе, что в следующий раз такого не произойдет . В следующий раз мы все сделаем по уму . В следующий раз анализ и проектирование будут выполнены на совесть .
Я называю это раздуванием вышедшего из-под контроля процесса .
Мы собираемся в следующий раз еще лучше работать по методу, который не работает .
Преувеличение?
Очевидно, что история утрирована . В ней собрано воедино все отрицательное, что вообще может быть во время работы над про- ектом по разработке программ . Большинство проектов, где приме- нялась каскадная модель, не терпели такого краха . Действительно, по счастливой случайности некоторые проекты удавалось завер- шить даже относительно успешно . С другой стороны, на подобной встрече я бывал не раз, мне доводилось работать не над одним таким проектом, и такое случалось не только со мной . История гиперболизированная, но такое все равно бывает .
Если меня спросить, сколько проектов, разработанных по каскад- ной модели, провалились с таким же треском, как в описанной выше истории, я отвечу, что сравнительно мало . С другой стороны, это больше, чем ничего, что тоже плохо . Кроме того, большая часть
Глава 1. Введение в Agile
56
таких проектов испытывала подобные трудности в большей или меньшей степени .
Каскадная модель не самая ужасная из того, что существует . Не все проекты, выполняемые по ней, разлетались в прах . Но она как была, так и остается плачевным способом ведения проекта .
Способ получше
Проблема в том, что каскадная модель кажется очень понятной .
Сначала мы проводим анализ задачи, потом проектируем решение и уже потом осуществляем реализацию .
Просто . Доступно . Очевидно . И неправильно .
Подход, предлагаемый Agile, в корне отличается от того, что было написано выше, но при этом так же понятен . По мере прочтения, полагаю, вы увидите, что в нем гораздо больше смысла, чем в трех словах, описывающих каскадную модель .
Проект по Agile начинается с анализа, однако анализ сопровождает весь цикл разработки . На рис . 1 .4 изображена схема, объясняющая принцип ведения проекта в целом . Справа — дата сдачи проекта,
1 ноября . Помните, первое, что надо знать, — это срок сдачи . Срок требуется поделить на закономерные интервалы, называемые ите- рациями, или спринтами
1
Длительность одной итерации, как правило, составляет одну или две недели . Я предпочитаю недельный интервал, потому что за две недели можно натворить слишком много . Другие предпочитают
1
Понятие «спринт» используется в Scrum . Мне оно не нравится, потому что намекает на то, что нужно нестись изо всех сил . Проект по разработке — это марафон . А кому нужен спринт во время марафона?
Краткий обзор Agile
57
Дата, которая используется для корректировки плана
Разработка
UI
Связь
Контроль
UI, связь
и контроль
определенного
поведения
Разбиение на подзадачи
Рис. 1.4. Схема проекта интервал в две недели, так как боятся не успеть выполнить задание за неделю .
Нулевая итерация
Во время самой первой итерации, которую иногда называют нуле- вой, создается краткий список функций — историй . Об этом будет рассказано подробнее далее . А сейчас давайте их рассмотрим как функции, которые нужно разрабатывать .
В процессе нулевой итерации также происходит развертывание среды разработки, оценка историй и построение первоначального плана . Такой план — это просто предварительное распределение историй по нескольким первым итерациям . Наконец, во время нулевой итерации разработчики, в том числе и разработчики архи- тектуры, творят чудо — создают первоначальный проект на основе предварительного списка историй .
Процесс написания историй, их оценки, планирования и про- ектирования никогда не прекращается . Поэтому через всю схему ведения проекта проходит горизонтальная линия, обозначенная