Що робити з командою розвитку, яка голодує? [зачинено]

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

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

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

Хоча мені подобається відповідь про вдосконалення тестів, документації тощо, і це добре, ви також можете подивитися:

• Допомагаючи критичному компоненту шляху, чи швидше це піде з програмуванням команди / приятеля?
• Перебудова критичного компонента в кілька підкомпонентів, над якими може працювати кожен.
• Манекен критичного компонента з чимось, можливо, грубим, що робить в основному ту ж роботу, але, можливо, недостатньо швидко для виробництва.
• Створіть API для критичного компонента, виправте це більш-менш у камені та допоможіть отримати базовий функціонал для цього компонента (з урахуванням змін у впровадженні, але не API).
• Подивіться, чи можете ви скористатися ранніми, відомими проблемними версіями критичного компонента, щоб працювати над іншою частиною системи, де функціональність "достатньо хороша на даний момент".

Також добре почати етап "засвоєних уроків" зараз, записавши, що такі критичні компоненти потрібно запустити раніше в процесі розробки, можливо, перед тим, як зібрати решту команди.

Вам потрібен резервний план для пізньої доставки

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

Побудуйте тренажер

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

Чи має він визначений інтерфейс? Реалізуйте це.

Чи є в ньому детальна документація? Наслідуйте це якнайкраще.

Це просто чиясь ідея? Подивіться, чи зможете ви отримати прототип.

Потім, коли вони знову проскакують графік….

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

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

Якщо критичний компонент має відомий інтерфейс, і якщо немає надії його виконати за короткий час, чому б не побудувати тестовий подвійний (наприклад, макет )?

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

Окрім очевидного "робити все те, чого ти поки не обіймав", звучить так, що тобі та вашій команді не вистачає спокою робити щось, що не має відношення до пізнього проекту. Що зрозуміло, але не корисно.

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

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

Там, де я працюю, якщо є блокатор, кожен насос робить насос, щоб зробити все можливе, щоб прискорити розвиток.

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

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

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