keepsimple
dark
en | ru

#5. Циклы разработки ПО и принципы Agile

Так же, как и методологий, существует множество разных жизненных циклов разработки ПО.

Жизненный цикл подразумевает тот период времени, который попадает между принятием решения о разработке чего-то и фактическим завершением имплементации (выполнением) этой задачи. В контексте IT-компании занимающейся разработкой ПО, жизненный цикл также подразумевает сам подход к разработке ПО.

В отличие от философий и методологий, показывающих нам какие ценности мы исповедуем и какими принципами и практиками мы хотим достичь успеха, в рамках одного проекта мы можем комбинировать несколько подходов к разработке.

Поговорим о четырех подходах, которых более чем хватит для общей картины:

  • Прогнозируемый (Predictive Life Cycle)
  • Итеративный (Iterative Life Cycle)
  • Инкрементальный (Incremental Life Cycle)
  • Аджайл (Agile Life Cycle)

Спойлер:

Прогнозируемый подход

Также называется традиционным/классическим подходом.

Данный подход полностью направлен на планирование и сбор требований до старта проекта. В идеале, подразумевается, что в процессе разработки потенциальные изменения будут сведены к нулю из-за ясности требований заказчика с самого начала.

Наиболее популярным примером прогнозируемого подхода является каскадная модель, также известная как Водопад (Waterfall). Этот подход широко использовался до того, как Agile приобрел свою популярность. Суть прогнозируемого подхода сводится к четырем фазам:

  • Разработка дизайна проекта
  • Разработка ПО
  • Тестирование ПО
  • Сдача проекта

Подход начал активно использоваться в 80х. Со временем он приобрел очень широкую популярность в IT-сфере, т.к. позволял свести к минимуму множество рисков своего времени.

Риски в частности исходили из изменений, которые мог потребовать заказчик, что увеличивало стоимость и длительность разработки, поэтому нулевой фазой являлся тщательный сбор информации по разрабатываемой системе и выявление всех потенциально возможных вопросов, которые могли бы возникнуть в будущем. На основании собранных данных составлялся SRS документ (System Requirements Specification), в котором описывалось все то, что должно было быть разработано. После того, как заказчик подписывался под SRS, команда разработчиков разбивала SRS на технические задачи, определяля ответственных по срокам и разработке. По мере имплементации, завершенные задачи переходили в 3ю фазу – тестирование, где тестировщики проверяли их на предмет соответствия согласованной с заказчиком документации, и если все было в порядке – помечались как завершенные и ждали своего часа.

Так, проект собирался постепенно, а после завершения всех задач проводилось регрессивное тестирование, в рамках которого тестировщики проверяли все ПО на предмет соотвествия документации, и, по окончанию всех процедур – выписывали проект на сдачу заказчику.

Грубость данного подхода всегда заключалась в том, что заказчику показывался только конечный результат, и только по окончанию разработки проекта, заказчик мог выразить свое мнение и запросить список каких-то изменений. Усугублялось все еще и тем, что компания-исполнитель могла просто напросто не соглашаться на изменения – документ то ведь давно согласован и подписан ☺.

Итеративный подход

Итеративный подход, в отличие от Прогнозируемого, не подразумевает наличие всех требований до начала проекта. Заказчик может знать примерно, что хочет, и этого может быть достаточно для старта проекта.

Проект условно делится на неопределенное кол-во итераций (отрезок времени), и в каждой итерации разработчики приводят ПО ближе к пожеланиям заказчика, который, в свою очередь, после каждой итерации оценивает что было сделано, и определяет куда двигаться дальше – сворачивать ли с курса, или продолжать. Акцент делается на том, чтобы после каждой итерации, программа была рабочей, пусть и не в финальном состоянии, таким образом главное правило итеративного подхода – это завершение итерации так, чтобы то, что разрабатывалось в этой итерации приносило пользу продукту в целом (Здесь также важно подчеркнуть, что если заказчик захотел удалить результат последней итерации, так как он был слабее его ожиданий – это тоже польза, так как на подобных ошибках учатся и качественно развиваются как закачик так и все участники проекта).

Например, заказчик заказывает веб-проект сайта знакомств. Он хочет, чтобы на этом сайте пользователи могли находить друг друга и общаться напрямую, а система должна на основании совпадающих интересов советовать пользователей друг другу и все такое.

Предположим, что у нас уже есть этот вебсайт, однако нет автоматизированной системы-советчика. Пользователи сами ищут друг друга в долгих списках фильтрующихся только по полу. В логике итераций, за одну итерацию можно добавить несколько полей в профиль пользователя, где он мог бы выбрать один из двадцати интересов разбросанных по 5 категориям. После этого, можно провести анализ данных, чтобы понять, насколько эта функция была интересна для пользователей, и следующей итерацией добавить несколько полей, а также часть функционала автоматического сопоставления интересов. И так далее, пока в какой-то момент система «научится» определять наиболее вероятных кандидатов/кандидаток для пользователя который еще только-только завершает процесс регистрации.

Очевидно, что длительность итераций вариативна и определяется самими участниками проекта.

Ключевая сложность подобного подхода в том, что очень сложно с самого начала оценить стоимость и длительность разработки проекта, так как мы допускаем изменения в требованиях.

Инкрементальный подход

Этот подход, также как и итеративный, подразумевает разработку ПО частями, но в отличие от итеративного, здесь ПО разрабатывается завершенными частями, то есть, если какая-то часть системы была завершена – подразумевается, что она завершена на 100% и готова к использованию. Часто, для каждого инкремента, еще до начала разработки собирается своя документация с целью минимизации рисков связанных с изменением требований, за что инкрементальный подход иногда называют мульти-водопадом (multi-waterfall).

В данном подходе ПО разбивают на несколько независимых, функциональных модулей, и разрабатывают соответственно.

Например, если наш клиент – букмейкерская контора, которая захотела собственный веб-сайт с разными играми, в логике инкрементального подхода будет отдельно разработать модуль для «лайв»-игр, отдельный модуль для поддержки ставок на киберспорт, отдельный модуль для покера (покер-румы, турниры) и так далее. Конечно, я утрирую, но в целом этого хватит для понимания идеи.

Каждый такой модуль в логике инкрементального подхода называется инкрементом (как неожиданно!).

Инкрементальный подход не отличается гибкостью, так как подразумевает выписывание максимально точных требований к каждому инкременту, однако, с другой стороны он дает возможность определить стоимость и сроки разработки по каждому инкременту.

Agile подход (также известный как гибкая разработка)

Agile появился и популяризировался пропорционально скорости развития IT-сферы в целом, и технологий разработки ПО в частности. В начале 2000х умным людям стало понятно, что мир становится все более динамичным, и если для проекта длительностью месяца полтора-два еще кое-как можно собрать требования, составить документацию и только после этого начать разработку, то для проектов длительностью несколько месяцев а то и лет необходим иной подход, который позволит вывести на рынок не устаревший «список требований, согласованный пол года назад», а продукт, соответствующий конъюнктуре того дня, когда он попадет на рынок. Более того. Так как пользователи изо дня в день становятся все более «жадными» на новые функции, а современное поколение уже имеет целый список постоянно дополняющихся ожиданий от программ, быть «современным» на этом динамичном рынке можно только став динамичным самому. Вот здесь и появляется Agile.

Agile, в контексте подходов, которые мы описываем, является гибридом Итеративного и Инкрементального подходов. В рамках поставленных заказчиком целей, команда-исполнитель может решить прибегнуть к частично-итеративному подходу, либо частично-инкрементальному, руководствуясь исключительно тем, чтобы к завершению итерации, ПО повышало свою ценность для заказчика.

Agile, как мы уже говорили в предыдущей статье, имеет свод ценностей, закрепленных 4 пунктами Agile манифеста, которые являются основой философии Agile.

Здесь же мы разберем принципы Agile.

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

Этим пунктом подчеркивается важность регулярной и ранней поставки, что в свою очередь подразумевает, что мы должны забыть об итерациях (отрезках времени) которые длятся слишком долго, и стараться предоставлять заказчику обновленные версии ПО так рано, как можем. Второй важный пункт – поставка ценного ПО, служит нам руководством, в случаях, когда необходимо принять решение о том, что попадет в очередь разработки на следующую итерацию. Нам всегда следует руководствоваться тем, получим ли мы на выходе ценность, необходимую заказчику, или нет.

Например, если мы хотим успеть завершить какой-то модуль, но нам очевидно, что мы не успеем сделать это за одну итерацию, мы можем разделить этот модуль на несколько частей, распределить их между несколькими итерациями, так, чтобы они занимали процентов 15 от общего затрачиваемого времени на разработку всех задач итерации, и помимо этого модуля добавлять ценность для заказчика другими, более целостными частями продукта разработанными в этих итерациях.

2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

Этот пункт сложно дается многим программистам, потому-что для них иногда больно удалить кусок кода, который больше не актуален и не нужен заказчику, однако на который они потратили множество бессонных ночей. Менеджеру необходимо учесть это еще до начала проекта, ведь это именно один из тех вопросов, по которому необходимо добиться полного согласия в команде в самом начале ее формирования. Необходимо, чтобы в менталитете всех участников проекта была четкая картина того, чего мы собираемся добиться. Наша главная задача – это не писать тысячи строк кода, и не генерировать месячные отчеты. Мы должны приложить максимум усилий, чтобы заказчик успешно закрепился на рынке, и для этого мы должны делать все от себя зависящее. Если для этого необходимо переписать часть системы – мы это сделаем. Если рынок изменился, и нужно начинать новый проект, убив прежний – мы это сделаем. Мы должны понимать, что не смотря на ту грусть и разочарование, которое возникает в команде в такие сложные моменты, именно возможность собраться и решать новые поставленные задачи с тем же энтузиазмом и является ключевой причиной, по которой мы можем считать себя специалистами. Безусловно, именно в такие моменты особенно важна роль менеджера проекта, который, по сути, станет одним из первых, кто узнает новости об изменении курса, либо отказе от каких-то идей.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

На данный момент, большинство Agile-компаний предпочитает двухнедельные итерации. На практике я не видел итераций дольше месяца.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

Увы, этот пункт часто недооценивают, ссылаясь на иерархию и корпоративные регламенты дозирования информации. Полагаю, внимательный читатель может заметить логичность этого пункта, ведь если мы хотим всеми нашими шагами максимально приблизить заказчика к успеху – понимание его бизнеса нам только поможет. Все верно. Именно понимание того, как функционирует бизнес нашего клиента и есть один из ключей успеха проекта. Если, еще до старта проекта разработчики будут вкратце ознакомлены с бизнесом под который пишется проект, возможно у них уже тогда возникнут идеи, чего хорошего можно добавить, либо что более вероятно, они укажут на какие-то технические риски, которые ускользнули от внимания представителей бизнеса. Agile говорит нам о прозрачности между всеми участниками команды, и этот пункт лишь еще раз подчеркивает важность этой прозрачности.

5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

Мотивированные профессионалы появляются там, где понятны преследуемые цели и перспективы для каждого из участников. Было бы не лишним рассказать участникам как о значимости самого проекта, так и о важности того вклада, который делает каждый из них. Для профессионала, часто, задача – это просто задача, однако, если мы хотим добавить мотивации, мы должны найти возможность сделать это задачу нашей миссией. Так, чтобы желание работать и совершенствовать проект не угасало ни у кого. Условия, в данном контексте подразумевают комфорт и прозрачность между участниками команды, чтобы каждый знал кто чем занимается. Поддержка же – непосредственная задача проект менеджера, который должен держать «руку на пульсе» и внимательно следить за настроениями в команде, чтобы работа шла гармонично и без перерывов.

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

В современном мире все более и более популярными становится коммуникация в чатах, однако, ввиду того, что человек, по сути, является существом коммуникационным, ни один чат в ближайшие много-много лет не заменит живого общения. Практиковать живое общение везде, где это не идет в ущерб работе – отличная привычка.

7. Работающий продукт — основной показатель прогресса.

Мы можем активно работать долгие месяцы, и все это время нам может казаться, что все просто замечательно, однако ключевым показателем нашего прогресса будет работающий продукт. Именно поэтому большинство современных стартапов стремится выпустить продукт на рынок настолько быстро, насколько это возможно, и уже после этого – совершенствовать его.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

Похоже на контекстную рекламу, нет? ☺) Комментарии излишни, перейдем к следующему пункту.

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Данный пункт важен настолько, насколько нам важно качество проекта в долгосрочной перспективе. Стремление к техническому совершенству и качеству проектирования подразумевает «чистку» программного кода от устаревшего мусора и использование передовых технологий не взирая на их сложность или отсутствие детальной документации по ним. Технических специалистов, которые крайне педантично относятся к этому пункту мало, но они есть. Более детально разбирать этот пункт не буду, так как это материал достойный отдельной статьи.

10. Простота — искусство минимизации лишней работы — крайне необходима.

Опять же – если мы в начале проекта четко очерчиваем ценности, которыми собираемся руководствоваться, и умеем следовать им, простота достигается сама собой.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

Самоорганизующаяся команда в Agile – это команда, которая работала вместе, в том же составе, достаточно долго, чтобы научиться работать крайне слаженно и синхронно. В таких командах очень мало возникающих вопросов о том как выполнять работу, и о том, что учитывать, т.к. в идеале, у всех участников этой команды единое понимание ценностей (философии) проекта. Подобные команды создаются за годы работы, чаще в крупных компаниях, где составы команд меняются редко.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Или конкретнее – проект менеджер должен систематически анализировать возможные способы улучшения эффективности команды, находить возможные варианты коррекции стиля работы команды, публично обсуждать проблемы и согласовывать решения по дальнейшей работе.

Таким образом, принципы Agile дают нам фундамент, на котором мы можем собирать нужные нам практики и инструменты, вне зависимости от того, какая часть компонентов будет написана инкрементально, а какая – итеративно.

Пара слов о документации в Agile:

(Нашел в заметках, не исключено что что-то попало через copy-paste, но польза не уменьшается.)

  • В AGILE не нужно придерживаться строгой документации;
  • Документирование может быть как для внутреннего использования командой-разработчиком, так и тех. документом описывающим сам продукт, со всеми его свойствами и особенностями;
  • Слишком подробная документация повышает риск неоднозначности, недопонимания и расхождений во взглядах между членами команды;
  • Исчерпывающая документация для управления AGILE-проектом практически невозможна;
  • Написание документации следует поручить одному лицу, чтобы избежать проблемы раздробленного видения.
  • Компания, разрабатывающая только документацию, необходимую для проекта, создает среду, в которой команде доверено делать именно то, что надо (по документу), когда происходят изменения, что, как результат, хорошо для отчетности но губительно для проекта;

Итог

Теперь мы знаем какие популярные циклы разработки ПО существуют, почему они возникли и какие задачи решали. Мы в общих чертах понимаем плюсы и минусы этих подходов и видим, что Agile – в соответствии со своим названием – наиболее гибкий подход нацеленный на результат а не бюрократию.

В следующей статье мы поговорим о наиболее популярном Agile—фреймворке, о Скраме (SCRUM).