Про скорость разработки
Допустим, у вас есть команда, которая разрабатывает специфическое бизнес-приложение. Будем называть фичей то, о чём можно рассказать пользователям или про что не стыдно сделать отдельный слайд в презентации. Я придерживаюсь грубой оценки, что одну фичу один разработчик делает за неделю. Учитывая отпуск, творческий кризис и непредвиденные проблемы за год человек может сделать около 30 фич.
Однако, программист-одиночка - это слишком большие риски, обычно так серьёзные продукты не делают. У команды из двух человек появляются накладные расходы на обсуждение философских вопросов, распределение нагрузки и синхронизацию изменений, поэтому они могут сделать примерно 50 фич в год.
Если от команды требуется большая производительность, то приходится потихоньку добавлять людей, разделять между ними задачи. Разумеется, делать это весьма не просто и не быстро, при этом себестоимость одной фичи неизбежно будет расти.
Допустим теперь, что у вас есть команда из 30 программистов. Больше 10 новых фич в релиз включить нельзя, иначе есть риск, что его вообще нельзя будет стабилизировать. Я рискну оценить, что столько людей не могут синхронизировать все свои изменения, собрать билд, отдать его на тестирование и исправить все ошибки чаще 5 раз в год. Итого получаем те же 50 фич в год.
Отнеситесь, пожалуйста, с юмором к использованным в статье константам, но, надеюсь, мне удалось передать моё мнение по поводу эффективности больших команд.
Ещё по теме: Интервью Гаммы про разработку Eclipse и шестинедельные майлстоуны, Мифический человеко-месяц Брукса.
Однако, программист-одиночка - это слишком большие риски, обычно так серьёзные продукты не делают. У команды из двух человек появляются накладные расходы на обсуждение философских вопросов, распределение нагрузки и синхронизацию изменений, поэтому они могут сделать примерно 50 фич в год.
Если от команды требуется большая производительность, то приходится потихоньку добавлять людей, разделять между ними задачи. Разумеется, делать это весьма не просто и не быстро, при этом себестоимость одной фичи неизбежно будет расти.
Допустим теперь, что у вас есть команда из 30 программистов. Больше 10 новых фич в релиз включить нельзя, иначе есть риск, что его вообще нельзя будет стабилизировать. Я рискну оценить, что столько людей не могут синхронизировать все свои изменения, собрать билд, отдать его на тестирование и исправить все ошибки чаще 5 раз в год. Итого получаем те же 50 фич в год.
Отнеситесь, пожалуйста, с юмором к использованным в статье константам, но, надеюсь, мне удалось передать моё мнение по поводу эффективности больших команд.
Ещё по теме: Интервью Гаммы про разработку Eclipse и шестинедельные майлстоуны, Мифический человеко-месяц Брукса.