Каковы переломные моменты для размера команды по сравнению с процессом наверху? [закрытый]
Извините, но я не думаю, что вы сможете сделать это, не нарушив Условия обслуживания YouTube. Удаление их водяного знака звучит особенно проблематично.
Общее использование службы - разрешения и ограничения
A. Вы соглашаетесь не распространять на каком-либо носителе какую-либо часть Сервиса или Контент без предварительного письменного разрешения YouTube, если только YouTube не предоставит средства для такого распространения с помощью функций, предлагаемых Сервисом (таких как Встраиваемый проигрыватель).
В. Вы соглашаетесь не изменять или модифицировать какую-либо часть Сервиса.
4 ответа
По моему опыту, этот переход происходит в точно момент, в который Вам также нужно управление. Трудно добраться выше 8 разработчиков без некоторого существования функции координирования перекрытия, является ли это руководителем группы, сегрегацией задач или старомодного управления. Действительность, которую я засвидетельствовал, - то, что даже с лучшим, самым талантливым, наиболее купленным - в разработчиках Вам все еще нужна координация, когда Вы добираетесь выше 8 работ одновременно.
И существует прерывистый шаг в процессе, поскольку Вы пересекаете ту границу. Однако это не должно быть катастрофически. Лучший подход состоит в том, чтобы команда приняла столько формального процесса, сколько она может, когда все еще маленький так, чтобы все необходимое поведение и инфраструктура существовали. Я утверждал бы, что это синонимично с хорошей разработкой в любом случае, поэтому даже у одинокого разработчика должна быть она (управление исходным кодом, модульные тесты и стандарты кодирования являются всеми примерами того, что я говорю о). Если Вы проявляете этот подход затем шаг в процессе, когда он происходит, не так толчок как строгая координация.
Каждый разработчик Вы добавляете потребность, которая уже будет введена с процессом на месте. Когда Вы добираетесь до 8 (или независимо от того, что число оказывается тем, чтобы быть для Вас), затем, Вы найдете, что Ваши обсуждения в команде становятся немного слишком свободными и многословными, личности начинают играть роль, и более эффективно разделить действие. В тот момент Ваш босс (или Вы, если Вы - босс) должен будет назначить одного или несколько координаторов, чтобы распределить и управлять работой.
Этот процесс (должен) увеличиваться также, если Вы придерживаетесь своих процессов. Команды могут подразделить, или можно расцвести команды для выполнения функциональных задач при необходимости. Этот подход также работает независимо от методологии, которую Вы выбрали для своего управления проектами, быть им Гибкий или нет.
После того как Вы добираетесь до 4 или 5 команд, т.е. 30-50 человек затем, Вам почти наверняка будут нужны люди, которые рады, что их единственной задачей является координация.
Если Вы являетесь маленькими теперь и рассмотрение или ожидание сдвига сложности, то удостоверьтесь, что Вы закрепили свои фундаментальные процессы сразу и конечно прежде чем Вы начнете добавлять больше штата.
HTH и удача
Вы собираетесь быть трудно получить количественный ответ на это. Это действительно зависит от того, насколько "широкий" проект. Если существует одна простая подсистема, чтобы продолжить работать, еще, чем 1 человек приведет к людям, ступающим на пальцы ног других людей. Если у Вас так или иначе есть проект с 8 отдельными подсистемами, то у Вас может быть 8 разработчиков без проблем. Более вероятно у Вас будет несколько подсистем, которые зависят друг от друга в различных степенях. О, и все это верно независимо от процесса, который Вы используете.
Выбор, какой процесс Вы хотите использовать (спираль, толпа, водопад, CMM, и т.д.), и как тяжеловес версия того процесса Вы хотите реализовать, другая проблема, и это трудно. Это главным образом, потому что люди пытаются взять процессы, которые работают в строительстве, работе фабрики или некоторой другой промышленности, которая является ничем как программное обеспечение и применяет его к разработке программного обеспечения.
По-моему, McConnell пишет лучшие книги по программному процессу, даже при том, что ни одна из его книг не книги процесса по сути.
Если не изменяет память, меня правильно что-либо выше пяти человек - то, где вещи становятся рискованными. Количество путей коммуникации между командой становится действительно большим после этого.
(2 человека = 1 путь, 3 = 3 пути, 4 = 6 путей, 5 = 10 путей и так далее).
Последние три места я была командой IT, прошли значительное изменение процесса. Да, Вы потеряете людей, вероятно, некоторые лучшие также. не то, чтобы они упрямы и пытаются придерживаться старых путей, это просто, что изменение как это вызовет массовую сумму напряжения. Существуют крайние сроки для удара и потребность в качестве, которое будет встречено. Люди запутаются, о каком процессе они, как предполагается, делают, и многие отступят к "старым путям". (я был виновен в этом также, я признаю.)
Ключ к следованию должен взять его медленный и в небольших шагах. Люди должны занять время для понимания, почему процесс изменяется и как он приносит пользу им. Это огромно, если Вы не займете время, чтобы сделать это, то это не успешно выполнится, и ключевые люди закончат тем, что вышли из порождения суматохи.
Одна из вещей абсолютно помнить - то, что в конечном счете некоторый оборот хорош. Это приносит новые идеи и людей с различным (и иногда лучше) наборы навыков. Вы не должны пытаться вызвать изменение на людей быстро, но они не должны быть барьером также. Если они не соглашаются с тем, что продолжается, они должны или попытаться прибыть во второй план с людьми, делающими процесс или отпуск. Одно из реальных сенсационных сообщений, которые я изучил в своем первом задании, - то, что в действительности все заменимы. Кто-то в конечном счете сможет вступить, берут господство.
Много зависит от людей, работающих над проектом, точками интеграции, и т.д. Даже единственный кодер должен иметь инструмент управления кодом и должен взаимодействовать с клиентами или 'боссом'. На основе опыта я видел изменение, после того как существует более затем 2 человека и затем вероятно, любое увеличение 50%. Если команды будут организованы проектными группами, сфокусированными на отделенных частях продукта, то служебное увеличение экспоненциально не увеличится, как размер команды увеличивается (проект по сравнению с матричными организациями).