+7 (499) 638-64-11
Попробовать
Постановка и автоматизация процессов разработки ПО

Учимся подбирать методологию к проекту

05.09.2017 06:41

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

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

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

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

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

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

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

Водопад

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

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

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

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

Схема отлично работает с процессными фреймворками, такими как RUP, EPF, MSF.  Схема подходит организационной структуре, в которой выделены отделы анализа, проектирования, разработки, тестирования и пр. Также отлично работает с моделью управления на директивной основе.  Каждый переход от этапа работы к этапу сопряжен с передачей документов по проекту. Готовая документация нужна для согласования и аудита. Появляется шанс привлекать других исполнителей на разных этапах.

Scrum

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

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

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

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

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

Kanban

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

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

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

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

Еще интересные статьи на эту тему: