Чем инкрементная модель отличается от итеративной

Модели и методологии разработки стартапа

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

Что такое модель разработки продукта и для чего она нужна

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

• Планирование. Определяем, что делаем и какие проблемы решаем. Ставим цели, выясняем, какие ресурсы нам нужны для реализации проекта. Изучаем рынок и конкурентов, прорабатываем альтернативные варианты разработки продукта.
• Анализ системы. Определяем и документируем требования конечного пользователя системы. Какие ожидания есть у нашего потребителя и как мы можем их осуществить? Можем ли мы это сделать вообще?
• Дизайн. Определяем элементы системы, ее компоненты, уровень безопасности, архитектуру, интерфейсы, типы данных. Рисуем дизайн, обсуждаем, проектируем.
• Разработка и внедрение. К началу этой стадии дизайн уже завершен, наступает очередь разработки. Пишем код, настраиваем систему под определенные требования и функции. К концу фазы система готова к установке и запуску.
• Тестирование. Проверяем, получили мы в итоге то, что хотели, или же результаты работы оказались другими. Тестируем продукт автоматизированными тестами, командой, предлагаем поработать с системой потенциальным пользователям. Определяем дефекты и недостатки в работе системы и устраняем их.
• Поддержка системы. Подготовка и выпуск обновлений, оценка производительности системы, замена/деактивация устаревших компонентов.

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

Вот список классических моделей:

• Code and Fix (написание кода, проверка и устранение ошибок),
• Waterfall (проект последовательно проходит все стадии),
• V-Model (проведение тестирования одновременно с разработкой),
• Инкрементная модель (проект делится на составные компоненты, команда по очереди готовит каждый из них, затем происходит финальная сборка),
• Спиральная модель (предусматривает тщательную проработку рисков),
• Итеративная модель (сначала делается базовая модель продукта, затем следуют итерации по ее усовершенствованию),
• RAD-Model (скоростная разработка продукта).

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

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

Наконец, методологии разработки — это применение той или иной модели на практике. Так, Agile-модель имеет целый ряд довольно популярных методологий — от мягкого Kanban, когда команда работает с доской с задачами, до жестких Scrum и XP.

Теперь рассмотрим особенности каждой из упомянутых моделей.

Code-and-Fix

Это одна из самых старых моделей разработки: она очень проста и подойдет стартапам, где команда невелика, нет особых конфликтов, вы знаете, что хотите сделать и имеете представление, как это сделать.

Как работает Code-and-Fix: у нас есть понимание, что мы хотим сделать. Начинаем программировать, затем смотрим, что получилось. Выявляем баги, правим их и снова смотрим — и так, пока наш продукт не начнет работать.

Плюсы методологии: не нужно тратить время на планы, документацию, митинги.

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

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

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

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

Когда используется водопадная модель

Эта модель используется при разработке программ для строительства, медицины, работы с государственными контрактами. Если говорить о непрограммных продуктах, то каскадная модель применяется для строительства крупных объектов.

Емко этот метод описал Чак Кобб, автор книг по проектному менеджменту:

Если бы вы строили мост через реку, было бы смешно сказать: «Мы построим первый пролет, посмотрим, как это выходит, а затем решим, как закончить оставшиеся пролеты!”

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

Каскадную модель применяли: компания Cisco для разработки систем безопасности, IBM, Microsoft IT и даже Toyota.

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

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

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

Инкрементная модель

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

Мы получаем несколько циклов разработки — своеобразный “мультиводопад”. Каждый цикл делится на модули, каждый модуль — на фазы: определение требований, проектирование, написание кода, внедрение, тестирование.

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

Спиральная модель

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

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

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

Спиральная модель довольно затратна в применении, поэтому не подходит для небольших проектов. А вот для средних и больших ее можно применять, особенно, если вы боитесь прогореть.

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

Кейс GanttPRO. Приложение для управления проектами и задачами GanttPRO разрабатывалось по принципам спиральной модели, а также фреймворка Agile — Scrum, о котором расскажу чуть ниже. Разработчики выбрали довольно короткие двухнедельные периоды релизов для того, чтобы иметь возможность часто получать отзывы. Также был создан детальный план того, что должно было быть реализовано на первой итерации и как проработать различные риски. Например, перед первой итерацией каждый разработчик высказался по поводу того, что из запланированного может не быть реализовано и почему. Кроме того, команда уделила особое внимание снижению рисков, вызванных необходимостью быстрой адаптации к нуждам пользователей и рынка.

Итеративная модель

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

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

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

Кейс “Самокат”. Метафорически итеративную модель можно проиллюстрировать на примере разработки транспортного средства. Результатом первой итерации может стать самокат. Это пример транспорта, хоть и максимально простого. Результатом второй итерации может стать самокат с электродвигателем, третьей — электровелосипед, четвертой — мотоцикл. Таким образом, с каждой итерацией повышаются функциональные возможности продукта, созданного еще во время первой итерации. Сравним разработку этого же транспортного средства по водопадной модели: траспорт мы получим в самом конце, после того, как будут завершены все стадии проекта.

RAD-Model, или Rapid Application Development Model

Разновидность инкрементной модели. Появилась в конце 80-х годов и стала одной из попыток создания гибкого процесса разработки.

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

Плюсы такой модели разработки — скорость. Минусы — финансирование.

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

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

Agile имеет множество вариаций и фреймворков. Среди самых известных: Scrum, Kanban, экстремальное программирование (XP), Lean.

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

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

На практике это выглядит следующим образом. Каждая задача по проекту описывается в отдельной карточке и добавляется на доску — виртуальную или настоящую. Карточка и доска — неотъемлемые элементы Kanban. Все задачи, которые необходимо сделать, собраны в специальной колонке, условно, она может называться “сделать”/ “to do”. Исполнитель выбирает задачу и перемещает в колонку “в процессе” / “in progress”. Когда задача сделана, она попадает в соответствующую колонку “готово” / “done”. На практике колонок может быть гораздо больше, чем три. К примеру, колонки на доске могут выглядеть так: “обсуждается” (backlog), “согласовано” (ready), “кодируется” (coding), “тестируется” (testing), “подтверждается” (approval) и “сделано” (done).

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

Кейс “Тойота”. Методология Kanban родилась на производстве в компании Toyota. Мастера участков перечисляли выполняемые работы на бумаге и вывешивали их на видном месте — так и родилась доска канбан, один из элементов методологии. В основе производства Toyota — годовой план производства и сбыта авто, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке, основывающиеся на прогнозировании покупательского спроса. Методология базируется на принципе “точно в срок”, что, помимо четкого следования таймингу по каждой задаче, позволяет раскрывать дефекты производства вовремя. Например, ежедневные контроль запасов продукции и деталей выявляет неисправности или простои.

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

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

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

Рассмотрим пример применения Scrum.

1. На этапе формирования продукта вы с командой решаете, кто из вас будет исполнять роль product owner — человека, который отвечает за связь команды с потребителем и инвесторами (если ваши инвесторы будут интересоваться ходом разработки продукта).

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

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

4. В течение первого спринта вы отслеживаете качественные и количественные характеристики своей работы. Неотъемлемая часть скрама — ежедневные короткие (5–10) минут митинги, в течение которых каждый из участников команды рассказывает, что он планирует сделать за день, делится возникающими сложностями или, наоборот, успехами.

5. Ход выполнения задач отслеживается по скрам-доске, на которой все задачи двигаются от условной позиции “сделать” до “выполнено”.

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

7. Цикл спринтов повторяется до того момента, пока продукт не будет полностью завершен.

Экстремальное программирование (XP)

eXtreme Programming, экстремальное программирование, XP — гибкая методология разработки, которая появилась в конце 90-х годов прошлого столетия. Авторы взяли лучшие, на их взгляд, практики гибкой разработки и усилили их до максимума — отсюда и слово “экстремальный” в названии.

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

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

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

Третья особенность — коллективное владение кодом: каждый программист в команде имеет доступ к коду продукта и может вносить в него изменения. В том случае, если изменения привели к некорректной работе системы, исправить все должен тот программист, который внес эти изменения.

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

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

Ещё раз про семь основных методологий разработки

Разработка программного продукта знает много достойных методологий — иначе говоря, устоявшихся best practices. Выбор зависит от специфики проекта, системы бюджетирования, субъективных предпочтений и даже темперамента руководителя. В статье описаны методологии, с которыми мы регулярно сталкиваемся в Эдисоне.

1. «Waterfall Model» (каскадная модель или «водопад»)

Одна из самых старых, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В модели Waterfall легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены. Но это палка о двух концах. Каскадная модель будет давать отличный результат только в проектах с четко и заранее определенными требованиями и способами их реализации. Нет возможности сделать шаг назад, тестирование начинается только после того, как разработка завершена или почти завершена. Продукты, разработанные по данной модели без обоснованного ее выбора, могут иметь недочеты (список требований нельзя скорректировать в любой момент), о которых становится известно лишь в конце из-за строгой последовательности действий. Стоимость внесения изменений высока, так как для ее инициализации приходится ждать завершения всего проекта. Тем не менее, фиксированная стоимость часто перевешивает минусы подхода. Исправление осознанных в процессе создания недостатков возможно, и, по нашему опыту, требует от одного до трех дополнительных соглашений к контракту с небольшим ТЗ.

С помощью каскадной модели мы создали множество проектов «с нуля», включая разработку только ТЗ. Проекты, о которых написано на Хабре: средний — рентгеновский микротомограф, мелкий — автообновление службы Windows на AWS.

Когда использовать каскадную методологию?

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

2. «V-Model»

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

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

Когда использовать V-модель?

• Если требуется тщательное тестирование продукта, то V-модель оправдает заложенную в себя идею: validation and verification.
• Для малых и средних проектов, где требования четко определены и фиксированы.
• В условиях доступности инженеров необходимой квалификации, особенно тестировщиков.

3. «Incremental Model» (инкрементная модель)

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

Инкрементные модели используются там, где отдельные запросы на изменение ясны, могут быть легко формализованы и реализованы. В наших проектах мы применяли ее для создания читалки DefView, а следом и сети электронных библиотек Vivaldi.

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

Когда использовать инкрементную модель?

• Когда основные требования к системе четко определены и понятны. В то же время некоторые детали могут дорабатываться с течением времени.
• Требуется ранний вывод продукта на рынок.
• Есть несколько рисковых фич или целей.

4. «RAD Model» (rapid application development model или быстрая разработка приложений)

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

Модель быстрой разработки приложений включает следующие фазы:

• Бизнес-моделирование: определение списка информационных потоков между различными подразделениями.
• Моделирование данных: информация, собранная на предыдущем этапе, используется для определения объектов и иных сущностей, необходимых для циркуляции информации.
• Моделирование процесса: информационные потоки связывают объекты для достижения целей разработки.
• Сборка приложения: используются средства автоматической сборки для преобразования моделей системы автоматического проектирования в код.
• Тестирование: тестируются новые компоненты и интерфейсы.

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

5. «Agile Model» (гибкая методология разработки)

В «гибкой» методологии разработки после каждой итерации заказчик может наблюдать результат и понимать, удовлетворяет он его или нет. Это одно из преимуществ гибкой модели. К ее недостаткам относят то, что из-за отсутствия конкретных формулировок результатов сложно оценить трудозатраты и стоимость, требуемые на разработку. Экстремальное программирование (XP) является одним из наиболее известных применений гибкой модели на практике.

В основе такого типа — непродолжительные ежедневные встречи — «Scrum» и регулярно повторяющиеся собрания (раз в неделю, раз в две недели или раз в месяц), которые называются «Sprint». На ежедневных совещаниях участники команды обсуждают:

• отчёт о проделанной работе с момента последнего Scrum’a;
• список задач, которые сотрудник должен выполнить до следующего собрания;
• затруднения, возникшие в ходе работы.

Когда использовать Agile?

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

6. «Iterative Model» (итеративная или итерационная модель)

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

На диаграмме показана итерационная «разработка» Мона Лизы. Как видно, в первой итерации есть лишь набросок Джоконды, во второй — появляются цвета, а третья итерация добавляет деталей, насыщенности и завершает процесс. В инкрементной же модели функционал продукта наращивается по кусочкам, продукт составляется из частей. В отличие от итерационной модели, каждый кусочек представляет собой целостный элемент.

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

Когда оптимально использовать итеративную модель?

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

7. «Spiral Model» (спиральная модель)

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

Спиральная модель предполагает 4 этапа для каждого витка:

1. планирование;
2. анализ рисков;
3. конструирование;
4. оценка результата и при удовлетворительном качестве переход к новому витку.

Подытожим

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

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

Модели жизненного цикла, принципы и методологии разработки программного обеспечения (ПО)

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

Жизненный цикл программного обеспечения: этапы

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

Обычно к этапам жизненного цикла относят:

1. Анализ требований
2. Проектирование
3. Программирование
4. Тестирование и отладку
5. Эксплуатацию, сопровождение и поддержку

Но это не полный перечень.

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

Среди моделей жизненного цикла программного обеспечения наиболее известны следующие:

1. Каскадная модель (она же “водопадная” — waterfall)
2. Итерационные модели
3. Инкрементная модель
4. Спиральная модель

Давайте посмотрим на них подробнее и разберемся, что в них общего, а что отличается.

Модели жизненного цикла ПО

По большому счету все модели можно разделить на две больших группы: последовательные и итерационные модели.

Waterfall (каскадная модель)

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

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

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

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

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

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

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

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

Итерационная, спиральная и инкрементная модели

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

Поясним разбиение на этапы на бытовом примере. Допустим, нам нужен стол в гостиную.

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

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

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

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

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

Итерационная модель например применялась при разработке СДО проекта Джерело. Детальнее о разработке чата Джерело можно почитать тут.

Спиральная и инкрементная модели являются видами итерационной модели жизненного цикла.

Что же такое спиральная модель?

Все этапы жизненного цикла при спиральной модели идут витками, на каждом из которых происходят проектирование, кодирование, дизайн, тестирование и т. д. Такой процесс отображает суть названия: поднимаясь, проходится один виток (цикл) спирали для достижения конечного результата. Причем не обязательно, что один и тот же набор процессов будет повторятся от витка к витку. Но результаты каждого из витков ведут к главной цели.

Теперь поговорим об инкрементной модели.

Принцип, который лежит в основе инкрементной модели, подразумевает расширение возможностей, достраивание модулей и функций приложения. Буквальный перевод слова инкремент: «увеличение на один». Это «увеличение на один» применяется в том числе для обозначения версий продукта.

Если в каскадной модели по сути есть два состояния продукта: «ничего» и «готовый продукт», то с появлением итерационных моделей стало применяться версионирование продукта. Каждая итерация обозначается цифрой: 1,2,3 и соответственно продукт после каждой итерации имеет версию с соответствующим номером: v.1, v.2, v.3. Числами после слова версия обозначают масштабные изменения в ядро продукта.

А когда одна из версий эксплуатируется, следующая, учитывая недочеты предыдущей, только планируется или уже разрабатывается, а улучшения заказчику и пользователю хочется доставить прямо сейчас, тогда появляются минорные версии. Туда попадают изменения, которые не влияют на ядро разработки и представлены как под-версии 1.1,1.2,1.3 или релизы 1.1.1, 1.1.2 и т.п.

В совокупности такие поэтапные релизы приводят к полноценной версии 2.0.

Agile и Lean: принципы разработки ПО

Agile — набор принципов гибкой разработки (всего их 12) и идей. Основные идеи Agile:

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

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

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

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

Во внутреннем планировании и в продуктовой разработке без этого принципа и элементов Agile не обойтись.

Теперь давайте поговорим о Lean.

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

Когда доходит до разработки продукта, или делается какое-то улучшение, производственное или инженерное, мы сначала делаем его MVP (minimum viable product). Термин MVP сейчас широко распространён и применяется повсеместно, но он родился именно из Lean подхода. MVP это такая версия продукта, которая выполняет свою главную функцию и при этом её не отторгают клиенты и признают её полезность. Конечно, её можно улучшать и улучшать, но в целом продукт на стадии MVP должен быть полезным, понятным клиенту и таким, чтобы можно было принять решение о его дальнейших улучшениях или признать эксперимент неудачным и тестировать новую гипотезу, потратив при этом как можно меньше ресурсов.

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

В упрощении сила и главная “ловушка” Lean: стремление всё упростить иногда приводит к ситуациям, в которых продукт упрощают настолько, что теряются действительно важные функции и продукт по сути оказывается ненужным, поскольку не несёт ценности пользователю.

В заключение о Lean хочется сказать такое: часто когда говорят о Lean то говорят что “Lean это о том чтобы вместо сервиса сделать лендинг с формой контактов”. Нет, это не Lean. Такое тестирование не противоречит Lean, но Lean-методология предлагает гораздо больше приемов чем этот, и стоит внимательного изучения.

Основные методы разработки ПО: гибкие методологии

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

Scrum методология основывается на понятии спринта (sprint), в течении которого выполняется работа над продуктом. Перед началом каждого спринта проводится планирование (Sprint Planning), на котором производится оценка содержимого списка задач по развитию продукта (Product Backlog) и формирование бэклога на спринт (Sprint Backlog), в рамках которых и действует команда. Для спринта всегда существуют ограничения по времени, обычно от недели до месяца. Жизнь продукта таким образом разбита на равные по продолжительности спринты.

По Kanban методологии проект делится на этапы, которые визуализируются в виде канбан-доски. Этапы, это например: планирование, разработка, тестирование, релиз и т.п. Задачи в виде “карточек” перемещаются с этапа на этап. Новые задачи можно добавлять в любое время. Задача закрывается не по истечению конкретного времени, а по смене статуса на “завершено”. Канбан это методология из концепции “бережливого производства”.

RUP (Rational Unified Process) — разработка продукта при данном методе состоит из четырех фаз (начальная стадия, уточнение, построение, внедрение), каждая из которых включает в себя одну или несколько итераций. RUP огромная методология, которую трудно уложить в абзац текста, но методы, рекомендуемые RUP основаны на статистике коммерчески успешных проектов.

DSDM (Dynamic Systems Development Model) — методология, которая демонстрирует набор принципов, предопределенных типов ролей и техник.

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

RAD (Rapid Application Development) — методология быстрой разработки приложений, которая предполагает применение инструментальных средств визуального моделирования (прототипирования) и разработки. RAD предусматривает небольшие команды разработки,сроки до 4 месяцев и активное привлечение заказчика с ранних этапов. Данная методология опирается на требования, но также существует возможность их изменений в период разработки системы. Такой подход позволяет сократить расходы и свести время разработки к минимуму.

XP (Extreme Programming) — методология, которая ориентируется на постоянное изменение требований к продукту и предлагает 12 подходов для достижения эффективных результатов в подобных условиях. Среди них:

• Быстрый план и его постоянное изменение
• Простой дизайн архитектуры;
• Частое тестирование;
• Участие одновременно двух разработчиков в одной задаче или даже за одним рабочим местом;
• Постоянная интеграция и частые небольшие релизы.

Evergreen в топ 25 ИТ-компаний Украины

Вместо вывода

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

Хотите поговорить о том, как лучше всего построить управление вашим проектом? Пишите!

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

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

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

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

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

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

Наиболее популярным примером прогнозируемого подхода является каскадная модель, также известная как Водопад (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 (скопировано с оригинала):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Copyright © 2019 — 2024 Wolf Alexanyan. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation.