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

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

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

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

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

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