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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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