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

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

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

В рамках одного проекта мы можем комбинировать несколько подходов к разработке, однако сперва рассмотрим наиболее популярные подходы:

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

Иллюстрация всех обсуждаемых циклов разработки ПО (SDLCs)

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

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

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

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

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

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

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

На основании собранных данных составляется SRS документ (System Requirements Specification) (либо PRD (Product Requirements Documentation) ), в котором описывается все то, что должно было быть разработано. После того, как заказчик подписывается под документом, команда разработчиков раздробляет документ на технические задачи и назначает исполнителей.

Выполненные ими задачи переходят в фазу тестирования, где соответствующие специалисты (QA, тестировщики и другие), проводят тестирование выполненной работы. Тестирование проводится с сопоставлением текущего состояния тестируемого объекта с тем, что указано в документации.

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

Читатель может заметить, что по сути, этот подход, своего рода "конвеер" (одна из причин, по которой его назвали "Водопадом"), и как и в случае работы любого конвеера - одна ошибка на одном из этапов может остановить всю работу. Другая грубая деталь данного подхода в том, что заказчику показывается только конечный результат, и только по окончанию разработки проекта. Заказчик же, конечно, может выразить свое мнение и запросить какие-то изменения, но нет гарантий, что компания исполнитель это сделает. Ведь, по сути, контракт уже заключен, документы подписаны и список требуемых работ согласован ☺.

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

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

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

Участники проекта одинаково понимают, что итерацию нужно завершить так, чтобы разработанная часть ПО приносила пользу продукту в целом. Еще одно важное преимущество этого подхода в том, что заказчик принимает решения по каждой итерации, а значит, в худшем случае, он рискует запороть лишь один отрезок времени за раз (в среднем, одна итерация длится это 2-4 недели). Также этот подход дает возможность постепенно "учиться". Благодаря своей гибкости, команда, вместе с заказчиком, могут на ранней стадии выявить изменения в желаниях пользователей, и переписать приоритеты того что должно быть разработано в следующих итерациях.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Единственная инструкция, звучит как "К завершению каждой итерации ПО должно повышать общую ценность продукта, а также соответствовать требованиям рынка".

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

Обьяснение принципов Agile (скопировано с оригинала):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Без комментариев.

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

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

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

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

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

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

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

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

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

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

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

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

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

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