22  /  96

Коллективная работа над проектом

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

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

  • Как организовать разработку в коллективе?
  • Кто отвечает за костяк процесса?
  • Какие риски следует минимизировать на начальном этапе производства?
  • Как контролировать риски в процессе разработки.

В коллективной работе есть много нюансов.


Человеческий фактор

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

Открытые коммуникации. Как можно проще должен быть реализован механизм коммуникации и в разработке и в проектировании. И с клиентом и между сотрудниками. Если при реализации проекта не созданы открытые эффективные коммуникации, то риски значительно возрастут.


Проблема рефакторинга

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

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

Второй. Если не прислушиваться к этой потребности, то код скоро может стать не оптимальным.

Нужен баланс между обоими путями. Нельзя запрещать полностью, но и нельзя поощрять излишнюю работу и "прокачку" программиста за счёт студии. Клиенту нужно суметь объяснить необходимость рефакторинга, если такая необходимость реально возникла. (Проще поддерживать и развивать проект - основные аргументы.) Если клиент входит в положение, то это серьёзно повышает мотивацию разработчика и качество системы.

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

Совет потенциальному клиенту: Есть команды, которые тонут в собственных багах. Они делают 5-6 коротких итераций по разработке, потом баги порождают новые баги. Рекомендация: задавайте короткие 2-3-хнедельные итерации и смотрите, тянет студия или нет. Если начнутся циклы по исправлению ошибок, то от такой студии надо уходить.


Технические особенности командной работы будут рассмотрены ниже.


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

Как мы разрабатываем Sphinx - доклад на конференции FailOver Conference Украина.

Стабильность проекта в условиях непрерывной интеграции - доклад на FailOver Conference.




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

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