Есть ли способ измерения стоимости гибкой разработки без учета количества времени, которое у вас ушло на выполнение задачи?
Представьте себе сцену, бизнес думает об использовании методологии Scrum для гибкой разработки. Они внедрили Scrum для Team Systems, и все очень довольны этим. Однако компания хочет капитализировать свои затраты на разработку и попросила изменить шаблон рабочего задания Scrum с учетом времени, затраченного на выполнение задачи. Идея в том, что им нужно знать, сколько времени разработчик потратил на продуктивную работу IE, сколько времени они потратили на добавление новых функций.
Проблема, с которой сталкиваются некоторые люди в бизнесе (в том числе и я), заключается в том, что вы записываете, сколько времени вы потратили на что-то вроде поражения объекта Scrum. Все, что я хочу знать с точки зрения ведущего разработчика, - это то, что у нас так много времени, чтобы проделать такую большую работу. Мы записываем, сколько времени осталось на выполнение задачи, и видим, как далеко мы далеки от достижения наших целей.
Может я упускаю суть? Кому ты рассказываешь. Однако, если кто-то знает, как мы можем работать без учета точного количества времени, которое мы потратили на то, чтобы что-то сделать, и все же угодить людям, которые вкладывают деньги, тогда ваш ответ был бы очень признателен.
5 ответов
Как менеджер по развитию, я заинтересован в том, чтобы убедиться, что разработка идет гладко (через Scrum) и что время учитывается для каждого проекта, поэтому мы знаем, куда мы тратим наши деньги (Time Tracking).
Поэтому во время спринта членам команды предлагается обновить количество времени, остающегося на нерешенных задачах, для вычисления графика выгрузки. Это не должно занять больше пары минут. Так как мы используем Scrum, команда решает задачи, и мне все равно, кто чем занимается, пока у нас есть график выгрузки.
Я также прошу их отслеживать свое время на проект, и это не очень подробно. Я не хочу отслеживать каждую минуту их времени. Эта информация используется, чтобы понять, сколько времени занимает выпуск версии или сколько денег уходит на разработку продукта.
Поскольку мы используем Scrum, отслеживание времени очень просто, так как все члены команды работают над одним проектом в течение длительного периода времени.
Первый вопрос - вы консалтинговый магазин или внутренний IT-магазин. Если первое, то фактические могут быть необходимы, чтобы позволить им правильно выставлять счета клиентам. Если последнее, и вы все наемные, то причины не так ясны. Я всегда подозреваю, что любой менеджер хочет знать, "сколько времени программист потратил на продуктивную работу". Это метрика, и одна из ключевых вещей, которую я говорю командам с любой формой гибкой разработки, заключается в том, что метрики должны собираться для ясных целей, с которыми команда согласна.
Я хотел бы спросить, что такое "вопрос, стоящий за вопросом" - или что действительно ищет руководство. Почему они обеспокоены производительностью разработчиков? Трудно ли объяснить своим менеджерам, что происходит? Существуют ли метрики команды, которые можно было бы обобщить?
Короче говоря, ваш менеджер может считаться клиентом команды, поэтому выясните, чего хочет ваш клиент, и определите наилучший способ - в команде - обеспечить это.
Скрам не жесткая, все зависит от адаптивности и того, что соответствует вашим потребностям.
Почему бы вам не оценивать истории в часах, а не в баллах. Мы тоже столкнулись с такой же ситуацией и начали оценивать через несколько часов. Каждый день, по сравнению с этими приблизительными часами, журнал разработчиков показывает, сколько времени они работали над историей. Ежедневно можно увидеть, сколько времени понадобится истории, и, в конце концов, увидеть оценку и фактическое время, затраченное на это. Мы использовали XPlanner, чтобы отслеживать это, и разработчику требуется минута, чтобы ежедневно регистрировать время. На основании этой информации вы всегда можете измерить скорость, которая поможет в следующей итерации.
Помимо историй, связанных с проектом, мы регистрируем время, потраченное на другие виды деятельности, например, на встречи, отключение среды, поддержку производства и т. Д. За определенный период времени эта информация дала нам много информации, и нам удалось значительно сократить это потерянное время.
Scrum и другие гибкие методы разработки работают лучше всего, когда между людьми, участвующими с обеих сторон, существует доверие. Руководство должно верить, что разработчики много работают и работают хорошо. Разработчики должны верить, что руководство уважает их вклад и просит их выполнять соответствующую работу в соответствии с потребностями бизнеса. Без этого доверия ваш процесс будет неэффективным. Ни одна среда не является идеальной, но в какой-то момент проблемы доверия могут стать настолько серьезными, что это станет неработоспособным.
Сказав это, есть множество вещей, которые я, как разработчик, должен делать "просто потому, что". Мне, например, приходится делать именно такие вещи, потому что так работает вся организация, включая разработчиков. Я могу жить с этим. Я бы сказал, отслеживать свое время, но планировать спринты. Записывайте свое "непродуктивное" время осмысленно - как технологические исследования, офисные задачи и т. Д. - какими бы они ни были - чтобы деловые люди понимали, что вы всегда продуктивны, даже когда не разрабатываете код.
РЕДАКТИРОВАТЬ Да - и если отслеживание времени является особенно обременительным, например, заполнение подробных ежедневных журналов, убедитесь, что вы отслеживаете количество времени, которое вы тратите, отслеживая свое время очень четко, чтобы они знали, сколько стоит это мероприятие.
Мы используем Agile/SCRUM уже около 2 лет, и мы никогда не записывали фактические данные.
Кажется, что время от времени предпринимаются попытки заставить всех записать эту информацию. Обычно это происходит из-за плохого спринта, где вина лежит прямо на плохой оценке. Но слишком легко забыть пометить их - хотя я уверен, что при достаточно "мягком подталкивании" это станет привычкой.
Идея, которую я вижу снова и снова - и с которой я согласен - заключается в том, что ваша скорость должна отвечать на любой вопрос, который вам (или владельцам продукта) нужно задать относительно прогресса в решении задач.