25  /  96

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

Просмотров: 3663 (Статистика ведётся с 06.02.2017)
Дата последнего изменения: 27.02.2014

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

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

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

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

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

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

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

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

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

    Последующие этапы - реализация нестандартного функционала по мере возрастания сложности.

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

Примечание: Эта глава не ставит своей целью дать детальное пояснение той или иной технологии разработки. Её задача - дать общее представление о технологиях и за счёт этого показать направление поиска оптимальных для вас методик. О деталях технологий поинтересуйтесь у Yandex'а.


Список ссылок по теме:

DevOps в интернет-проектах - доклад на конференции FailOver Conference Украина.




4
Курсы разработаны в компании «1С-Битрикс»

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