Минусы и риски работы от потребностей

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

Минусы работы от потребностей следующие:

• С заказчиком согласуется расплывчатое ТЗ. ("В целом всё понятно, а там додумаем!")
• Отсутствие проектирования. ("Разработчики у вас умные, сами сообразят что и как делать.")
• Разработчик делает лишь бы работало и побыстрее.
• Тестировщик проверяет разработку бессистемно.
• Аврально вносятся выявленные изменения.
• Не ведётся документация ни на проект, ни на код.

Это приводит к следующим рискам:

• Систему все сложнее развивать. Причём сложность увеличивается по экспоненте.
• Большие трудности входа в проект новых разработчиков: им сложно разобраться, что приводит к попыткам всё переписать с нуля.
• Монолитности создаваемой системы, которая боится изменений. Любое изменение порождает множество ошибок.
• Никто не помнит, как все работает (даже Заказчик)
• Крайне сложна задача тестирования. Никто не знает, как все проверить.

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

  Типы процессов создания проектов

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

• Водопад или Каскадная модель, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.
• Итеративный процесс. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта.
  Как разбивать проект на итерации? Самое первое что нужно сделать - это разбить на стандартный функционал CMS и нестандартный, который надо дописывать. Первый этап - это всегда реализация стандартного функционала. На этом этапе и студии и клиенту легко определиться продолжать ли дальнейшую работу вместе. Расставание на этом этапе - самое безболезненное для обеих сторон.
  
  Последующие этапы - реализация нестандартного функционала по мере возрастания сложности.

• Agile. Вид итеративной разработки, основанный на динамическом формировании требований и обеспечения их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
• Экстремальное программирование XP. Вид итеративного процесса, основанный на непрерывности разработки с коротким циклом обратной связи.
• Kanban. Модель для веб-студий, работающих с большим количеством заказов. Позволяет сократить время прохода задачи до состояния «готовности».
• Continuous Integration. Выполнение частых автоматизированных сборок проекта с целью минимизации рисков.

Видео

Выбор и внедрение процесса: от водопада до Kanban/XP/RUP