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

Просмотров: 9113
Дата последнего изменения: 23.09.2021

Сложность урока:

1 уровень - интуитивно все понятно из интерфейса, но почитать стоит.

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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