Что делать с командой разработчиков, которая голодает? [закрыто]

10

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

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

candied_orange
источник
10
У вас нулевой технический долг, чтобы расплатиться? Есть ли какие-то функциональные возможности, запланированные на будущее, на которые вы могли бы обратить внимание? Новые технологии или парадигмы, которые вы хотели бы опробовать в рамках существующей функциональности?
Jonrsharpe
27
@StudentT, который невероятно близорук, учитывая вероятную трудность в наращивании команды после того, как блокировщик будет решен.
Jonrsharpe
8
@StudentT, а лидера следует уволить за то, что он не планирует будущее, не предвидит, что такие вещи могут произойти.
С
13
Голодные разработчики? Одним словом: пицца.
Мейсон Уилер
3
Если у OP нулевой технический долг, чтобы заплатить, и нет юнитов / функциональных тестов или сценариев развертывания для написания / улучшения, он определенно жалуется из Deaven (Dev Heaven), и мне вдруг очень грустно: <
xDaizu

Ответы:

29

Улучшайте модульные тесты, функциональные тесты, документацию, инструменты и т. Д. Существует множество вещей, которые можно сделать в простое, ожидая, когда критический путь наверстает упущенное.

Maybe_Factor
источник
2
Эта. Средний разработчик (включая меня) постоянно скулит о нехватке времени для уточнения вещей. Придержи их к этому.
Traubenfuchs
4
Мне нравится это общее «делай то, чего ты еще не достиг». Я бы добавил обзоры кода и рефакторинг к этому. Сделайте это действительно аккуратным программным обеспечением, которое работает как хорошо смазанная машина и приятно наблюдать. Это удовлетворяет разработчиков.
Питер - Восстановить Монику
вещи, которые раньше не были достаточно важны, вероятно, все еще не стоит делать сейчас. это просто «сделать работу»
Ewan
16

Хотя мне нравится ответ об улучшении тестов, документации и т. Д., И это хороший вопрос, на который вы также можете посмотреть:

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

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

Стив Барнс
источник
2
Мне нравится альтернатива «всегда есть что улучшить». Если они достаточно хороши, лучше сосредоточиться на текущей проблеме и найти правильный обходной путь.
Вальфрат
15

Вам нужен план резервного копирования для вашего позднего результата

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

Построить симулятор

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

У него есть определенный интерфейс? Реализуйте это.

Есть ли у него подробная документация? Подражайте ему как можно лучше.

Это просто чья-то идея? Посмотрим, сможете ли вы получить прототип.

Затем, когда они проскальзывают, график снова ....

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

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

Джон Ву
источник
Симулятор не обязательно должен быть полным или фантастическим, достаточно того, чтобы вы могли прогрессировать.
Турбьерн Равн Андерсен
1
Я думаю, что это очень здравый и не сразу очевидный совет. Особенно перспектива вне кодирования, а именно тесты. Макет двойного значения.
Питер - Восстановить Монику
4

Если критический компонент имеет известный интерфейс и если нет надежды сделать это за короткое время, почему бы не создать двойной тест (например, макет )?

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

Christophe
источник
2

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

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

Мартин Маат
источник
0

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

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

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

Помимо этого, есть ли какая-то другая некритическая работа, на которую они могут продвинуться? Кроме того, есть ли какие-либо работы, которые они выполнили, которые могли бы быть доработаны (рефакторинг, удаление технических долгов, документация, добавление тестов и т. Д.).

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

Робби Ди
источник