Этот ответ написан с точки зрения кого-то, кто внедрил такую систему управления эффективностью в Agile команде; Как и вы, все в команде осознавали сложность / бесполезность годичных целей SMART, применяемых к Agile-группе, где при полном функционировании внедрение Agile можно считать изначально / уже SMART.
Нет, правда! Если нужно, назовите следующую рационализацию (если логика недоделана ...), но объяснение ее рецензентам вне непосредственной организации заложило основу для реальных «целей», которые мы ставим в системе управления эффективностью.
- S для конкретных : при планировании каждого спринта команда соглашается с определенным набором задач для выполнения и обязуется их выполнять. Задачи (и истории пользователей) отвечают на вопросы о том, что я хочу достичь, цели / выгоды от достижения цели, кто участвует, где это происходит, и ограничения.
- M для измеримых : список этих задач, а также движение заявок по всему спринту, от разработки до анализа кода до QA до релиза (или независимо от того, какой у вас поток), отвечает на вопросы о том, сколько работы и когда она будет выполнена ,
- A для достижимости : функционирующие Agile-группы, как правило, не совершают каких-либо обязательств на стадии планирования, если это явно не достижимо - здесь есть все, чтобы знать, как этого достичь
- R для релевантных : такие вопросы, как это стоит, это правильное время, соответствует ли оно нашим другим усилиям - истории и задачи не втягиваются в спринт, и не решаются, если ответ на все эти вопросы положительный ( обычно ... YMMV)
- T для времени : спринт обязательно связан со временем, будь то 2 недели, 3 недели, больше или меньше.
Если вы понимаете / убеждаете себя, что ваша ежеквартальная работа (и, следовательно, ваша годичная работа) сама по себе является одной из больших целей SMART, и что вы знаете, что достигаете своих целей, потому что команда работает хорошо, скорость положительна, релизы происходят затем вы переходите к сути вопроса, который, в конечном счете, заключается в том, как преобразовать процесс SMART в набор целей SMART для блага кого-то другого.
В прошлом я смог успешно это сделать, написав что-то, что для меня выглядит расплывчато и, ну, не очень УМНО, но на самом деле совершенно приемлемо для других.
Несколько примеров, которые прошли для меня в другом месте:
«Я хочу выпускать новую версию WidgetMaker каждые три месяца в следующем году, следуя нашему внутреннему процессу разработки программного обеспечения, чтобы соответствовать общему графику разработки продукта (бла-бла)».
«Я хочу увеличить скорость разработки команды на n% от выпуска A к выпуску B, сосредоточившись на постепенных изменениях в процессе подготовки отставания, чтобы повысить нашу эффективность и уменьшить задержки при доставке продукта».
Вы знаете, и я знаю, что это не руководящие принципы вашей реальной группы разработчиков, но они не являются полностью не связанными, и, по моему опыту, это те вещи, которые кажутся действительно УМНЫМИ и полезными для людей, не входящих в вашу непосредственную организацию (без быть откровенной ложью или полностью хромой).