Методологии совместного программирования?

Question

[iamhappy]

Подскажите, есть ли какие-то методологии разделения задач внутри проекта между небольшой группой программистов?

Я менеджер в маленькой студии разработки под айос. Иногда, когда у меня ведется разработка нескольких проектов одновременно, я не понимаю, что будет эффективнее — давать каждому программисту по одному проекту или настаивать на групповой работе.


Как мне кажется, групповая работа должна быть эффективнее, так как нельзя будет выпадать из работы надолго, тебя всегда будет контролировать твой партнер, однако я понимаю, что я некомпетентен чтобы однозначно решить.


Какие есть современные взгляды на решение этой задачи? Как правильно разделять проект? И надо его разделять?


Посоветуйте пожалуйста.

Answer 1

[Biga]

Поделюсь взглядом со стороны программиста.

Вот мы делаем проект командой из 3-5 человек. Проект длинный, больше года. В итоге каждый отвечает только за свою часть, в чужой ничего не понимает. Некоторые вещи реализуются независимо два, а то и три(!) раза, потом с матами приходится рефакторить всё к единому виду.
Программисты не смотрят код друг-друга, потому что времени на это нет. Начальство ждёт продвижения по плану работ, на встрече тебя спрашивают: успеешь сделать вот это за N дней? Ты прикидываешь на пальцах, умножаешь время на pi, как положено, и говоришь «да успею». В итоге даже успеваешь, но посмотреть чужой код времени не остаётся почти.
Из плюсов совместной разработки: если один человек уходит в отпуск, другой сможет хотя бы собрать билд. Плюсов можно найти больше, если среди программистов найдётся человек, которому не пофиг. Тогда даже может появиться какая-никакая документация. Если всем пофиг, то без разницы, сколько человек будет работать над проектом — документация не появится. Извинте, наболело.

Насчёт подгонять. Не знаю как где, но по моему опыту кодер кодит с постоянной скоростью, независимо ни от чего. Если один человек задерживает каким-то образом остальных, то это просто повод отдохнуть или начать кодить другую задачу. Думаете, будут подгонять?

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

Answer 2

[Dialog]

Попробуйте посмотреть на скрам и спринты. А также на один проект ставить не 1 программиста, а 2-3. Тогда они сами друг друга будут подгонять.

Answer 3

[Вячеслав Плиско]

Срочно сбросьте с себя это ярмо. Пускай разработчики сами разбирают задачи, ориентируясь на свой опыт. Количество работников на проекте может быть динамичное. У нас даже джуниоры сами себе таски набирают.
Если на проекте один разработчик, то на время добрасывайте второго, пускай парнопрограммируют, чтобы проект полностью не был завязан на одном разработчике.

Я подобную систему советовал сестре для её тестеров. Правда, у них получилось, что часть важных задач всё же распределяет она. Здесь всё сильно зависит от команды и нужно подстраиваться, делая ретроспективы и обсуждая что последнее время делалось хорошо, что плохо, решать проблемы.

Answer 4

[gleb_kudr]

Групповая работа эффективнее только в очень маленьких группах. 2-3 человека. Больше начинаются сильные потери на взаимодействии. Главное явно выделить среди них ответственного, за которым будет последнее слово по техническим решениям.
Мобильные проекты обычно небольшие — они могут позволить себе роскошь разрабатывать сверхмалой командой, нужно этим пользоваться.
Одиночек на проекты лучше не ставить — вы до небес увеличиваете риски связанные с уходом/болезнью и т.д. + пара действительно друг друга мотивирует.