Мені потрібна ця дитина через місяць - пришліть мені дев’ять жінок!

За яких обставин - якщо такі є - додавання програмістів до команди насправді прискорює розробку вже пізнього проекту?

Точні обставини, очевидно, дуже характерні для вашого проекту (наприклад, команда розробки, стиль управління, зрілість процесу, складність теми тощо). Для того, щоб розглянути це трохи краще, щоб ми могли говорити про це будь-що, крім значних спрощень, я хочу переглянути ваше запитання:

За яких обставин, якщо такі є, може додати членів команди до проекту розробки програмного забезпечення, який затримується пізніше, призведе до зменшення фактичної дати доставки з рівнем якості, рівним такому, якби існуючій команді було дозволено працювати до завершення?

Є низка речей, які, на мою думку, потрібні , але недостатньо для того, щоб це відбулося (не в певному порядку):

• Запропоновані особи, які потрібно додати до проекту, повинні мати:
  • Принаймні розумне розуміння проблемної області проекту
  • Знайте мову проекту та конкретні технології, які вони використовуватимуть для завдань, які їм будуть надані
  • Їх знання має / не / бути набагато меншим або значно більшим, ніж найслабший чи найсильніший існуючий член відповідно. Слабкі члени виснажуватимуть наявний персонал з третинними проблемами, в той час як нова людина, яка занадто сильна, порушить команду, як все, що вони зробили і роблять, не так.
  • Мати хороші навички спілкування
  • Бути високомотивованим (наприклад, вміти працювати самостійно, не висуваючись)
• Існуючі члени команди повинні мати:
  • Відмінні комунікативні навички
  • Відмінні навички управління часом
• У керівництві / управлінні проектом повинно бути:
  • Хороша здатність до пріоритетності та розподілу ресурсів
  • Високий рівень поваги з боку існуючих членів команди
  • Відмінні комунікативні навички
• Проект повинен мати:
  • Хороша, завершена та задокументована специфікація дизайну програмного забезпечення
  • Хороша документація речей, вже реалізованих
  • Модульна конструкція, яка дозволяє вирізати чіткі шматки відповідальності
  • Достатньо автоматизованих процесів для забезпечення якості для необхідного рівня дефектів. Вони можуть включати такі елементи, як: тести блоку, регресійні тести, автоматизовані розгортання збірки тощо)
  • Система відстеження помилок / функцій, яка наразі працює і використовується командою (наприклад, trac, SourceForge, FogBugz тощо).

Одне з перших, що слід обговорити, - чи можна пропустити дату відправлення , чи можна скоротити функції, і якщо деякі комбінації цих двох дозволять вам задовольнити звільнення з наявним персоналом. Багато разів його пара має особливості, які справді приборкують ресурси команди, які не дадуть вартості, рівній інвестиції. Тому дайте серйозний огляд пріоритетам свого проекту, перш ніж будь-що інше.

Якщо результат вищевказаного пункту недостатній, перейдіть до списку вище. Якщо ви зловили графік прострочення рано, додавання правильних членів команди в потрібний час може врятувати випуск. На жаль, чим ближче ви до очікуваної дати доставки, тим більше може піти не так, як додавати людей. Одного разу ви перетнете "точку неповернення", де жодна зміна (крім доставки поточної галузі розвитку) не зможе зберегти ваш реліз.

Я міг би продовжувати і продовжувати, але я думаю, що я потрапив у основні моменти. Поза проектом та з точки зору вашої кар’єри, майбутнього успіху компанії тощо. Одне з речей, які ви обов'язково повинні зробити, - це з’ясувати, чому ви запізнилися, якщо щось можна було зробити попереджати раніше, і які заходи вам потрібні вжити, щоб запобігти цьому в майбутньому. Запізнілий проект зазвичай виникає тому, що ви були або:

• Запізнилися перед тим, як почати (більше матеріалів, ніж час) та / або
• прослизнув 1 год, 1 день на час.

Сподіваюся, що це допомагає!

Це допомагає лише якщо у вас є проект, керований ресурсами.

Наприклад, врахуйте це:

Потрібно намалювати великий плакат, скажімо 4 на 6 метрів. Плакат настільки великий, напевно, ви можете поставити перед ним двох-трьох людей і паралельно їх малювати. Однак розмістити 20 людей перед цим не вийде. Крім того, вам знадобляться кваліфіковані люди, якщо ви не хочете бадьорий плакат.

Однак якщо ваш проект полягає в наповненні конвертів готовими друкованими літерами (як ви МОЖЛИВО перемогли! ), То чим більше людей ви додасте, тим швидше це пройде. Існує деяка накладні витрати на скорочення роботи, тому ви не зможете отримати вигоди до того моменту, коли у вас є одна людина. конверт, але ви можете отримати переваги набагато більше, ніж просто 2 або 3 людини.

Тож якщо ваш проект легко розділити на невеликі шматки, і якщо члени команди зможуть швидко набрати швидкість (наприклад ... миттєво), то додавання більшої кількості людей зробить це швидше, до певного моменту.

На жаль, у нашому світі не так багато проектів, тому підказки докгнімової книги про Міфічну людину-місяць - справді хороша порада.

Можливо, якщо застосовуються такі умови:

1. Нові програмісти вже розуміють проект і не потребують часу на збільшення часу.
2. Нові програмісти вже знають середовище розробки.
3. Для додавання розробників до команди не потрібен адміністративний час.
4. Майже не потрібно спілкування між членами команди.

Я дам вам знати, коли я вперше побачу все це одразу.

Згідно з міфічним "Чоловіком-місяцем", головна причина, що додає людей до пізнього проекту, - це згодом зв'язок O (n ^ 2).

Я зазнав одного основного винятку з цього: якщо в проекті є лише одна людина, він майже завжди приречений. Додавання другого прискорює його майже кожного разу. Це тому, що спілкування в цьому випадку не є надмірним - це корисна можливість уточнити свої думки і зробити менше дурних помилок.

Крім того, як ви, очевидно, знали, коли ви розміщували своє запитання, поради з Міфічного чоловіка-місяця стосуються лише пізніх проектів. Якщо ваш проект не запізнюється, цілком можливо, що додавання людей не пізніше зробить це. Припустимо, що ви робите це правильно, звичайно.

Якщо існуючі програмісти абсолютно некомпетентні, то додавання компетентних програмістів може допомогти.

Я можу собі уявити ситуацію, коли у вас була дуже модульна система, а існуючий програміст навіть не запускався на дуже ізольованому модулі. У цьому випадку може допомогти присвоєння саме тієї частини проекту новому програмісту.

В основному посилання на Міфічний Людина Місяця правильні, за винятком надуманих випадків, таких як той, який я склав. Містер Брукс провів ґрунтовні дослідження, щоб продемонструвати, що після певного моменту витрати на мережу та комунікацію на додавання нових програмістів до проекту переведуть будь-які переваги, які ви отримаєте від їх продуктивності.

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

Тільки коли у вас на цьому пізньому етапі є якісь самостійні (майже 0% взаємодія з іншими частинами проекту), які ще ніхто не вирішував, і ви можете залучити до команди когось, хто є фахівцем у цій галузі. Додавання члена команди має мінімізувати зриви для решти команди.

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

Очевидно, кожен проект відрізняється, але більшість робочих місць з розробки можуть бути впевнені, що певна кількість співпраці між розробниками. У моєму досвіді це те, що свіжі ресурси насправді можуть ненавмисно сповільнити людей, на яких вони покладаються, щоб привести їх до швидкості, а в деяких випадках це можуть бути ваші ключові люди (до речі, це зазвичай "ключові" люди, які брали б час на виховання новонародженого). Коли вони знаходяться до швидкості, немає ніяких гарантій того, що їх робота буде вписуватися в встановлені «правила» або «культуру праці» з іншою частиною команди. Отже, знову ж таки, це може принести більше шкоди, ніж користі. Тож осторонь, це обставини, коли це може бути корисно:

1) Новий ресурс має чітке завдання, яке вимагає мінімальної взаємодії з іншими розробниками та набору навичок, що вже було продемонстровано. (тобто перенесення існуючого коду на нову платформу, зовнішнє рефакторинг мертвого модуля, який наразі заблокований у існуючій кодовій базі).

2) Проект керується таким чином, що для інших старших членів команди може бути поділено час, щоб допомогти прискорити новонародженого та наставляти їх на шляху до того, щоб їх робота була сумісною з тим, що вже зроблено.

3) Інші члени команди дуже терплячі.

Я вважаю, що додавання людей до кінця роботи може прискорити роботу, якщо:

1. Роботу можна проводити паралельно.

2. Сума, заощаджена додатковими ресурсами, перевищує кількість втраченого часу, коли люди, досвідчені з проектом, пояснюють речі тим, хто недосвідчений.

EDIT: Я забув згадати, подібні речі трапляються не надто часто. Зазвичай це досить прямі речі вперед, як-от екрани адміністратора, які виконують просту CRUD до таблиці. У цей час ці типи інструментів у будь-якому разі можна здебільшого автогенерувати.

Будьте обережні, менеджери, які користуються банком на подібній роботі, хоча передають їх. Це звучить чудово, але насправді зазвичай цього недостатньо, щоб обрізати будь-який значний пробіг проекту.

• Автономні модулі, які ще потрібно запустити
• Не маючи інструментів розробки, які вони можуть інтегрувати (як автоматизований менеджер збірки)

В першу чергу я думаю про речі, які не дозволяють їм залишатися осторонь людей, що розвиваються в даний час. Я погоджуюся з Міфічним чоловіком-місяцем, але також думаю, що у всьому є винятки.

Я думаю, що додавання людей до команди може пришвидшити проект більше, ніж додати їх до самого проекту.

Я часто стикаюся з проблемою наявності занадто багато спільних проектів. Будь-який із цих проектів міг би бути завершений швидше, якби я міг зосередитися на цьому проекті один. Додавши членів команди, я міг перейти від інших проектів.

Звичайно, це передбачає, що ви найняли здібних, мотивованих розробників, які здатні успадковувати великі проекти та самостійно вчитися. :-)

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

Простіше кажучи. Це зводиться до порівняння часу, що залишився, та продуктивності, яку ви отримаєте від когось, виключаючи кількість часу, який потребує додаткових ресурсів, щоб прискорити швидкість та бути продуктивним та відняти час, вкладений у їхнє навчання наявними ресурсами. Основні фактори (за значенням):

1. Наскільки хороший ресурс у тому, щоб забрати його. Найкращі розробники можуть майже миттєво зайти на новий веб-сайт та швидко виправити помилки з невеликою допомогою. Цей навик рідкісний, але його можна засвоїти.
2. Розрізненість завдань. Вони повинні вміти працювати над об’єктами та функціями, не стикаючись з існуючими розробниками та уповільнюючи їх.
3. Складність наявного проекту та документації. Якщо це найкраща практика ванільної програми ASP.Net і звичайні добре задокументовані бізнес-сценарії, то хороший розробник може просто застрягти прямо зараз. Цей фактор більше, ніж будь-який, визначатиме, скільки часу доведеться інвестувати наявні ресурси у викладання та, отже, початковий негативний вплив нових ресурсів.
4. Кількість часу, що залишився. Це часто також неправильно оцінюється. Найчастіше логікою буде те, що у нас залишилося лише x тижнів, і це знадобиться x + 1 тиждень, щоб хтось набрав швидкість. Насправді, проект, ЯК ІСНУЄТЬСЯ, і насправді у нас залишається два тижні дев, щоб швидше та пізніше отримати більше ресурсів.

Якщо команда вже використовується для парного програмування, додавання іншого розробника, який вже є кваліфікованим у паруванні, може не уповільнити проект, особливо якщо розробка ведеться у стилі TDD.

Новий розробник поступово стане більш продуктивним, оскільки вони більше розуміють базу коду, і будь-які непорозуміння будуть сприйняті дуже рано або їхньою парою, або тестовим набором, який запускається перед кожною реєстрацією (і в ідеалі має бути перевірка як мінімум кожні десять хвилин).

Однак наслідки додаткових накладних комунікацій потрібно враховувати. Важливо не надто сильно розбавляти наявні знання про проект.

Додавання розробників має сенс, коли продуктивність, внесена додатковими розробниками, перевищує продуктивність, втрачену під час навчання та управління тими розробниками.