Которые являются преимуществами разделения времени разработчика между двумя проектами? [закрытый]

Sometimes you need to just step away from the code you have been writing for 11 hours in order to stay maximally productive. After you have been staring at the minutiae of a system you have been implementing for a long time it can become difficult to see the forest for the trees, and that is when you start to make mistakes that are hard to un-make.

I think it is best to have 2-3 current projects; one main one and 1-2 other projects that aren't on such a strict timeline.

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

что эти два проекта могут принадлежать разным клиентам (или запрашиваться разными людьми из высшего руководства).

Ни одному клиенту не нужно ждать, пока проект другого клиента получит приоритет.

«Мы оставим другой на потом "во многих случаях не является приемлемым ответом, хотя это приводит к задержкам для обоих проектов.

Я полагаю, что это связано с понятием" Воспринимаемая отзывчивость "в программа Даже если что-то занимает больше времени, оно выглядит быстрее, когда кажется, что что-то делает,

В своем запросе можно использовать подвыбор (не проверено и не уверен, что быстрее):

SELECT Grade, COUNT(*) / TotalRows
FROM (SELECT Grade, COUNT(*) As TotalRows
      FROM myTable) Grades
GROUP BY Grade, TotalRows

Или

SELECT Grade, SUM(PartialCount)
FROM (SELECT Grade, 1/COUNT(*) AS PartialCount
      FROM myTable) Grades
GROUP BY Grade

Или

SELECT Grade, GradeCount / SUM(GradeCount)
FROM (SELECT Grade, COUNT(*) As GradeCount
      FROM myTable
      GROUP BY Grade) Grades

Вы также можете использовать хранимую процедуру ( извинения за синтаксис Firebird):

SELECT COUNT(*)
FROM myTable
INTO :TotalCount;

FOR SELECT Grade, COUNT(*)
FROM myTable
GROUP BY Grade
INTO :Grade, :GradeCount
DO
BEGIN
    Percent = :GradeCount / :TotalCount;
    SUSPEND;
END

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

Работа над более чем одним проектом также несколько минимизирует риски. Например, если вы сначала работаете над одним проектом и этот проект занимает больше времени, чем ожидалось, у вас могут возникнуть проблемы со вторым проектом. Заинтересованные стороны также, скорее всего, хотят, чтобы их проект был выполнен сейчас. Удержание одного из-за другого проекта может заставить их пересмотреть вопрос о продолжении проекта.

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

Чаще всего проекты не являются постоянным потоком работы. Иногда разработчики заняты, а иногда нет. Если вы работаете только над одним проектом за раз, разработчик и другие члены команды, вероятно, ничего не будут делать, пока выполняются более «административные» задачи. Управление временем более чем одного проекта позволяет командам выполнять больше задач в более короткие сроки.

Как разработчик, я предпочитаю работать над несколькими проектами, если сроки являются разумными. Пока я Меня не просят сделать оба одновременно без изменения в расписании, я в порядке. Часто, если я застрял в одном проекте, я могу работать над другим. Хотя это зависит от проектов.

Это зависит от задействованных зависимостей. Если у вас есть другая зависимость от проекта, которая может быть выполнена, когда проект не завершен на 100%, то может иметь смысл разделить время разработчика. Например, если ваша задача велика, возможно, имеет смысл поручить основному разработчику разработку проекта, а затем перейти ко второму заданию, в то время как член команды рассматривает проект, разработанный первичным разработчиком.

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

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

Таким образом, с точки зрения развития 1 - лучший вариант, но с точки зрения обслуживания клиентов 2, вероятно, лучше.

Это эффект плекбо - разделение разработчика между двумя проектами описанным вами способом создает у людей/"бизнеса" впечатление, что работа ведется над обоими проектами (с одинаковой скоростью/стоимостью/временем), в то время как на самом деле это, вероятно, гораздо более неэффективно, поскольку переключение контекста и другие соображения требуют затрат (времени и усилий).

С одной стороны, это может дать старт таким вещам, как уточнение требований и подобные задачи (чтобы разработчик мог переключиться на альтернативный проект, когда он заблокирован), а также может привести к раннему вкладу со стороны других бизнес-подразделений/заинтересованных сторон и т.д.

Однако в конечном итоге, если у вас один ресурс, то у вас есть естественное узкое место.

Лучшее, что вы можете сделать для этого одинокого разработчика, - это перехватить людей (чтобы они не отвлекали его) и попытаться взять на себя часть нагрузки по требованиям, поиску разъяснений, обработке отзывов пользователей и т.д.

Существует три реальных преимущества разделения времени разработчиков между проектами, которые нельзя игнорировать:

1. Специализация: выполнение или консультирование по работе, для которой требуются аналогичные специализированные знания в обоих проектах.

2. Согласованность и обмен знаниями: обеспечение согласованности в том, как создаются и работают два отдельных продукта, распространяя знания по всей компании.

3. Лучшее использование команды: на редкий случай, когда один из проектов временно приостановлен в ожидании каких-либо дополнительных данных.

Разделение времени между несколькими проектами выгодно, когда оно не связано со значительными изменениями в контексте.

Наличие разработчика, работающего в одиночку над несколькими проектами разработки программного обеспечения, сводит на нет преимущества специализации (в данном случае их нет), согласованность и обмен знаниями.

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

Переключение контекста - очень интересный зверь: вопреки его названию, подразумевающему осторожное изменение, процесс всегда постепенный. Существуют различные степени наличия контекстной информации в голове: 10% контекста (мелкий), 90% (глубокий). Для полного переключения требуется меньше времени, чем для полного переключения; однако существует прямая корреляция между количеством загруженного контекста (концентрация на задаче) и качеством вывода.

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

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

При этом я постараюсь удержать разработчика над двумя проектами как можно меньше времени, и вернуть их к своему «основному» проекту. Я предпочитаю позволить людям сосредоточиться на одной задаче за раз. Я чувствую, что моя работа как менеджера состоит в том, чтобы балансировать и смещать приоритеты людей и фокус - и разработчики должны просто развиваться как можно больше.

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

Разделив время между двумя проекты, вы можете уменьшить риск задержки одного проекта из-за другого.

Давайте предположим, что оценка для обоих проектов составляет 3 месяца каждый. Делая это поочередно, один за другим, вы сможете доставить первый проект через 3 месяца, второй - через 3 месяца (т.е. через 6 месяцев). Но, как идут дела в разработке программного обеспечения, есть вероятность, что первый проект столкнется с некоторыми проблемами, поэтому вместо этого требуется 12 месяцев. Или, что еще хуже, переходит в чистилище "используется, но никогда не заканчивается". Второй проект запускается поздно или даже никогда !

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

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

Это в основном моя профессиональная жизнь в двух словах: -)

Если вы идете по тому, что написано в великой и священной книге «Peopleware», , вы должны держать своего программиста за один проект за раз.

Основная причина этого заключается в том, что разделенное внимание приведет к снижению производительности.

к сожалению, поскольку многие операционные менеджменты являются хорошими бизнесменами , а не хорошими менеджерами , они могут подумать, что многозадачность или работа над обоими проектами каким-то образом означает больше вещей выполняются (что невозможно, человек может физически существовать только в одном потоке пространственно-временного континуума одновременно).

надеюсь, что это поможет:)

• LM