Выбор методологии

Методология определяет многое: состав команды, способ взаимодействия с клиентом, порядок работы и многое другое.

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

Выбор методологии зависит и от состава команды, имеющейся в распоряжении студии. Если же клиент настаивает на каком-то конкретном процессе, то придётся искать людей под него.

Чем сильнее в профессиональном плане команда, имеющаяся в распоряжении, тем более гибкие методологии можно использовать. Для высокопрофессиональных сотрудников можно использовать XP - экстремальное программирование. Вчерашние студенты в режиме XP завалят самый простой проект. Для бывших студентов чем более формализован процесс, тем работа будет успешнее. С такими сотрудниками придётся применять Водопад.

Слабая команда и один сильный разработчик

Первое. Всё максимально формализовать и упростить. (Что это значит в плане использования, например, Bitrix Framework? Использование стандартных компонентов, использование стандартной административной части, сделать всё, чтобы люди как можно меньше написали кода. Править компоненты, шаблоны, вёрстку править, настройки менять, не более.)

Второе. Построить процесс разработки максимально близкий к Водопаду. Неопытный сотрудник не может правильно оценить сложность задачи и подобрать адекватные методы её решения. Для него опытный разработчик должен всё расписать в виде подробного плана проекта с диаграммой Ганта.

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

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

Средняя по силе команда

В этом случае возможна меньшая формализация итерационного процесса. Можно не делать аудит кода, можно делать меньше веток контроля версий, детально не указывать параметры настроек компонентов, модулей, можно сделать более короткими итерации (примерно месяц - полтора). Для таких команд подходит RUP, Agile, Kanban.

Сильная команда

Сильная команда постоянного состава - редкий случай. Подходят все виды процессов, выбирать которые нужно в зависимости от проекта. Сложные и большие проекты могут потребовать Водопад и для сильной команды, но в большинстве случаев сильные команды работают по технологиям XP, с элементами Agile, Scrum или Continuous Integration. Итерации могут становиться короче, примерно 2-3 недели.

  Как оценивать необходимое время и сложность задач

Точность оценки зависит от качества проектирования и от квалификации разработчиков. Как правилно, для оценки используется технология Planning Pocker.

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

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

При проведении оценки задач Planning Pocker'ом менеджер должен быть уверен, что задача ясна команде. Иначе её невозможно правильно оценить. Будут названы либо завышенные сроки, из боязни не успеть, либо заниженные, из-за недооценки сложности. В обоих случаях сроки окажутся под риском срыва, а качество исполнения - невысоким.

Можно применять модификацию Planning Pocker, когда разработчики оценивают задачу по критерию: Просто\Средне\Сложно. Если у менеджера уже есть сложившаяся оценка сколько времени уйдёт на задачу каждого типа.