Разработчик работает над исследовательским проектом, который включает в себя работу с новыми технологиями. Эти концепции также являются новыми для разработчика, и разработчик работает над созданием продукта на основе новых API.
Поскольку технология является новой и недокументированной, разработчик тратит много времени на разбор демонстраций и анализ данных, чтобы понять технологию.
Поскольку многие гибкие методологии включают в себя ежедневные или частые обновления команды, такие как Scrum и ежедневный стендап, как разработчики должны предоставлять обновления как техническим, так и нетехническим заинтересованным сторонам, чтобы это не выглядело так, как будто он или она ничего не добились? Обратите внимание, что собрание, которое мы проводим в настоящее время, не имеет названия.
Когда работа включает в себя значительную степень обучения или приобретения знаний, как я могу посоветовать этим разработчикам предоставлять свои обновления, не заставляя их чувствовать, что они не делают никакого прогресса, поскольку может быть нечего показать? дни/недели?
Следует ли сократить частоту статусных совещаний или следует оставить ее на прежнем уровне, используя другой подход?
Чтобы провести ценное исследование, обычно необходимо определить его цель и цель. Другими словами, разработчик знает, что он хочет сделать, каков его прогресс и с какими проблемами он сталкивается в настоящее время. Вопрос в том, как осмысленно делиться такими знаниями.
Если собрание включает в себя только отчет о состоянии дел, то есть смысл описать его в сжатой, но полезной форме.
Например , я уже проверил пять из двенадцати известных критериев совместимости API. Пока нет данных о возможной несовместимости, но вчера мне стало известно о двух новых критериях.
Если встреча также посвящена командной работе и выявлению риска и общего влияния работы, возникает много новых тем. Блокировщики есть? Нужна помощь? Должна ли она сообщить кому-то о важных открытиях?
Одной из основных причин, по которой мы проводим исследования, является уменьшение неопределенности. В то время как мы уменьшаем его, нам часто нужно изменить направление, в котором мы идем. Таким образом, каждый раз, когда ваше исследование достигает прогресса, возрастает вероятность того, что необходимо повлиять на статус кого-то еще . Предвидеть это и дать обновленную информацию, вероятно, является одной из причин, по которой существуют такие встречи.
Поскольку многие agile-методологии включают ежедневные или частые командные обновления... как разработчики должны предоставлять обновления как техническим, так и нетехническим заинтересованным сторонам, чтобы это не выглядело так, как будто он или она ничего не добились?
Если бы вы следовали Scrum, я бы указал, что ежедневные стендапы предназначены для команды, а не для заинтересованных сторон. Результаты итерации обычно предоставляются заинтересованным сторонам во время обзора спринта в конце каждой итерации, ограниченной по времени.
Даже если вы не следуете Scrum, я утверждаю, что слишком частые просьбы к разработчикам предоставлять обновления, ориентированные на заинтересованные стороны, сильно пахнут «привлечением разработчиков к ответственности» и приведут к тому, что разработчики будут сообщать о CYA, и в конечном итоге снизят прозрачность внутри проекта.
Вспомните басню « Цыпленок и поросенок». Связанный сайт говорит:
В Agile-проектах термин «свинья» используется для обозначения всех разработчиков, дизайнеров и тестировщиков, которые занимаются реальной работой. Термин «цыпленок» применяется ко всем остальным, кто вносит интеллектуальный вклад, но не занимается никакой работой.
Здесь вы можете рассмотреть несколько вариантов, в зависимости от вашей корпоративной культуры и среды.
Подумайте о том, чтобы ограничить частые встречи свиньями (например, командой разработчиков), а не включать заинтересованные стороны в встречи, которые носят процедурный характер.
Обеспечьте видимость для заинтересованных сторон с помощью информационной панели или другого ключевого показателя производительности, не связанного с «личной ответственностью» отдельных разработчиков.
Возложите на руководителя проекта ответственность за регулярное обновление статуса перед заинтересованными сторонами, а не перед членами команды. Это позволяет PM информировать заинтересованные стороны о том, что является (или не является) разумным прогрессом, и может помешать разработчикам сообщать о CYA.
Создавайте отдельные встречи через определенные промежутки времени для вопросов и ответов между заинтересованными сторонами и командой. В Scrum это будет обзор спринта, но главное — предоставить вашим заинтересованным сторонам прямой доступ к проекту, не вмешиваясь во внутренние процессы команды.
Встречайтесь с интервалами, соответствующими размеру вашей партии. Либо разбейте работу на части продолжительностью один день, либо увеличьте интервалы между встречами. Идея здесь состоит в том, чтобы переместить сообщение от «Я на 29,36% сделал с foo» к обновлению статуса «выполнено/не выполнено». Это более удобно для разработчиков, и его также легче отслеживать с точки зрения PM.
Когда работа включает в себя значительную степень обучения или приобретения знаний, как я могу посоветовать этим разработчикам предоставлять свои обновления, не заставляя их чувствовать, что они не делают никакого прогресса, поскольку может быть нечего показать? дни/недели?
Управление проектом часто включает установление ожиданий и четкое информирование о них внутри команды проекта и различных заинтересованных сторон. Независимо от вашей методологии или интервалов отчетности, вам необходимо информировать свою организацию о процессе и соответствующим образом устанавливать их ожидания.
Установите ожидания заинтересованных сторон.
Если ваш процесс включает в себя скачкообразные результаты, убедитесь, что ваши заинтересованные стороны ожидают соответствующей отчетности. Это может быть регулярная отчетность, включающая переменный уровень результатов, выполненных в течение определенного периода времени, или нерегулярная отчетность, когда что-то завершено и заслуживает внимания.
Установите ожидания разработчика.
Убедитесь, что разработчики знают, как они будут измеряться в рамках вашей методологии. Вы получаете то, что измеряете, а люди оптимизируют показатели, которые напрямую влияют на них. Если вы решите вести ежедневные отчеты, четко укажите, какую информацию вы собираетесь отслеживать, как эта информация будет использоваться и как эта информация повлияет как на проект, так и на каждого отдельного разработчика.
Сделайте ожидания явными.
[T]здесь может не быть ничего, чтобы показать в течение нескольких дней/недель[.]
Убедитесь, что это ожидание является явным , и что вы постоянно перевоспитываете и убеждаете всех в этом вопросе. Запрашивать разработчиков о ежедневных обновлениях статуса, когда ожидаемый ответ «Я еще не закончил», делает это очень сложным, отчасти по психологическим причинам, а отчасти потому, что то, как вы измеряете (ежедневные обновления), внутренне противоречит ожиданию вашего проекта всплесков. Результаты. Вы можете до некоторой степени компенсировать этот диссонанс, сохраняя реальные ожидания в центре внимания.
Одно из преимуществ ежедневных отчетов заключается в том, что вы должны разбивать задачу на части, каждую в течение дня. Я имею в виду, что вы должны знать, над чем вы работаете сегодня. Конечно, вам нужно исследовать API, но вы одновременно изучаете весь API и пишете код после того, как изучили каждый метод? Или вы начинаете с малого и добавляете новые функции, и, конечно, много рефакторите, изучая API, чтобы каждый день точно знать, над чем вы работаете? Если вы сообщаете 2 недели «Я все еще исследую», вы ничего не говорите команде, и лучше, если вы вообще не будете участвовать во встрече; однако, если вы прямо сейчас говорите, что я работаю с этой [частью API], или вчера мне пришлось переписать всю [часть API], у вас есть обновление статуса. А если 3 дня подряд ты говоришь "
Поздний ответ, который может иметь значение только в том случае, если вы разделяете проекты на пользовательские истории или аналогичные.
разработчик работает над созданием продукта на основе нового API.
Прежде всего, позвольте мне резюмировать мое понимание ситуации. Есть проект . Я имею в виду, что существует фактическое программное обеспечение, которое необходимо разработать, разработчик должен внедрить в программное обеспечение список функций, функции могут быть уже разделены на истории и т. д. Проблема в том, что реализация этих функций требует от разработчика изучения. новая технология. Как следствие, совершенно невозможно запланировать работу или оценить время завершения проекта. Более того, заинтересованные стороны не видят текущей исследовательской части.
В этой ситуации я бы рекомендовал использовать шипы . Шипы — это особый вид сюжета, представленный в XP. Они предназначены для снижения риска и неопределенности в части проекта, в то же время будучи сами оцениваемыми и запланированными. Они должны быть ограничены по времени. Короче говоря, обычно есть два вида спайков: функциональные спайки и технические спайки.
Функциональные шипы предназначены для решения функциональных задач. Например, мы не знаем, какое взаимодействие с пользователем лучше всего подходит для истории, мы создаем всплеск для прототипирования нескольких возможностей, прежде чем реализовывать реальную историю.
Технические спайки — это тот тип спайка, который вам может понадобиться. Используйте их, когда вам нужно больше технических данных перед реализацией истории, функции или проекта. Этим вкладом может быть изучение новой технологии, выбор между несколькими реализациями, выбор между созданием решения или его покупкой и т. д.
Когда продукт нужно построить на новой технологии, о которой мы вообще не знаем, я бы рекомендовал использовать три уровня историй:
Матиас Жуан
джморт253