В Agile сообществах давно обсуждается вопрос оценки уровня “Agile зрелости” команд. Чаще всего вопрос остро встает после того, как команда практикует какую-то Agile методологию шесть и более месяцев. Обычно это звучит как “мы уже научились делать основные практики, например Scrum, и все-таки чего-то не хватает”.
Оценка производительности, эффективности и другие “метрические” оценки не имеют смысла, так как каждая команда уникальна в своем роде, и такие метрики будут сильно отличаться от команды к команде. Оценка “заказчик доволен” тоже не всегда адекватна, так как удовлетворенность одного или нескольких человек еще не гарантирует, что ваша команда действительно хорошая и наоборот. 🙂
Очевидно, что имеет смысл анализировать команды по их уровню внедрения лучших практик, на которых сошлись все “апологеты Agile движения”. Так одно время возлагали большие надежды на Nokia Test, придуманный Базом Водом (Bas Vode) и доработанный Джеффом Сазерлендом (Jeff Sutherland). С другой стороны, не все практики можно внедрить в команде за одинаковое время.
Обычно, на момент, когда команда задается вопросами, нас интересует «действительно ли мы там, где хотели быть?», «в каких областях нам еще нужно развиваться?» и «как обстоят наши дела по сравнению с конкурентами или хотя бы с другими командами?». И в этом случае есть смысл говорить о сравнительном тесте, который покажет, насколько мы ближе к лучшим практикам, и какова наша позиция по отношению к другим командам.
И недавно я нашел такой тест, который называется Comparative Agility. Тест был представлен на конференции Agile Development Practices 2008 Майком Коном (Mike Cohn) (Со-основатель Скрам Альянса, Сертифицированный Скрам Тренер) и Кени Рубин (Kenny Rubin) (экс управляющий директор Скрам Альянса, Сертифицированный Скрам Тренер).
Суть подхода достаточно проста и логична. Вопросы сгруппированы по семи областям, которые представляют классификацию изменений, которые команда и компания должны были пройти на пути внедрения Agile. Области следующие:
Командная работа Работа с требованиями Планирование Инженерные (технические) практики Качество Культура Обмен опытом
В каждой области выделены ключевые характеристики, а для каждой характеристики подобраны вопросы. Для ответов на вопросы используется шкала Ликерта, где ответы градируются как:
- Правда
- Скорее, правда, чем ложь
- Ни то, ни другое
- Скорее ложь, чем, правда
- Ложь
В результате, ответив, примерно, на 120 вопросов мы получаем адекватную и вполне достоверную оценку. Как уже говорилось выше, весь интерес в том, чтобы сравнить свою ситуацию с другими компаниями в отрасли. Поэтому на сайте вам покажут результаты в виде отклонения от средней ситуации по отрасли. Это и есть то сравнение с лучшими практиками и возможность проанализировать, куда ваша команда может еще улучшаться.
Интересно взглянуть на результаты представленные Майком Коном на конференции. Команды, практикующие Agile меньше 6 месяцев, явно страдают от недостатка технических практик и низкого качества, хотя у них присутствует высокий командный дух и идет активный обмен знаниями. Спустя два года, команды нарабатывают необходимые инженерные и организационные практики, хотя теряют понимание Agile культуры и уже меньше заботятся об обмене и накоплении новых знаний.
Рекомендую вам по возможности самим пройти тест и проанализировать полученные данные. Уверен, вам будет о чем поговорить с коллегами по команде 😉
http://www.comparativeagility.com/survey/:
The page you were looking for doesn’t exist.
You may have mistyped the address or the page may have moved.
Спасибо, Сергей
ты, как всегда, на чеку 🙂
http://www.comparativeagility.com/survey/:
The page you were looking for doesn’t exist.
You may have mistyped the address or the page may have moved.
Спасибо, Сергей
ты, как всегда, на чеку 🙂
Этот тест предполагает, что one-size-fits-all.
А зачем сравнивать, насколько мы “agile сертифицированы”? Чтобы доказать свою принадлежность к избранным? 🙂
Имхо, подход необходимо адаптировать к контексту. В некоторых условиях один набор практик хорош, в некоторых – другой. Например, для проекта на несколько сотен человеко-лет процесс, используемый на проекте на пару человеко-месяцев, вряд ли будет идеальным.
Так что, use your common sense 🙂
Дмитрий,
Как вы могли прочитать в статье, речь не идет ни о какой сертификации. Наоборот, суть метода – сравнение команд между собой. За основу беруться области, которые общепризнанно свидетельствуют о гибкости подхода на вашем проекте (в вашей организации). Более того, если какой-то из конкретных вопросов не применим к вашему проекту, вы можете выбрать вариант ответа “не применимо” – это не должно сильно изменить общую картину.
Именно этим меня и подкупил этот опросник.
Я разделаю ваше беспокойство о том, что разные “сертификации”, зачастую не дают правдивую картину или еще хуже, их суть извращается и сертификация становится самоцелью. Этот вопрос уже даже поднимался в обсуждении статьи про сертификацию Скрам Мастеров
Более того, похожее обсуждение было на форуме AgileUkraine (например здесь) еще в конце прошлого года.
И, однозначно, нужно пользоваться здравым смыслом, когда вы хотите применить методы “оценки” для своей команды 😉
Этот тест предполагает, что one-size-fits-all.
А зачем сравнивать, насколько мы “agile сертифицированы”? Чтобы доказать свою принадлежность к избранным? 🙂
Имхо, подход необходимо адаптировать к контексту. В некоторых условиях один набор практик хорош, в некоторых – другой. Например, для проекта на несколько сотен человеко-лет процесс, используемый на проекте на пару человеко-месяцев, вряд ли будет идеальным.
Так что, use your common sense 🙂
Дмитрий,
Как вы могли прочитать в статье, речь не идет ни о какой сертификации. Наоборот, суть метода – сравнение команд между собой. За основу беруться области, которые общепризнанно свидетельствуют о гибкости подхода на вашем проекте (в вашей организации). Более того, если какой-то из конкретных вопросов не применим к вашему проекту, вы можете выбрать вариант ответа “не применимо” – это не должно сильно изменить общую картину.
Именно этим меня и подкупил этот опросник.
Я разделаю ваше беспокойство о том, что разные “сертификации”, зачастую не дают правдивую картину или еще хуже, их суть извращается и сертификация становится самоцелью. Этот вопрос уже даже поднимался в обсуждении статьи про сертификацию Скрам Мастеров
Более того, похожее обсуждение было на форуме AgileUkraine (например здесь) еще в конце прошлого года.
И, однозначно, нужно пользоваться здравым смыслом, когда вы хотите применить методы “оценки” для своей команды 😉
Имхо, такое сравнение команды с фиксированным эталоном имеет смысл только на стадиях Shu или Ha (ShuHaRi, впервые видел у Коберна http://alistair.cockburn.us/Shu+Ha+Ri.
На стадии Ri эталон – идеальная приспособленность к конкретным условиям :-). На этом этапе важно, насколько ты хорошо ты адаптируешься. Это может включать какие-то общепринятые практики, а может и нет. Команда делает то, что лучше всего работает в данных условиях.
Хотя, большинство команд работают именно на первых двух уровнях. Да, для них этот тест будет полезен.
Дмитрий, некоторые думают, что если команда достигла “уровня” и замечательно делает свое дело, то им и не зачем себя сравнивать 😉
С другой стороны, если команда не пытается дальше выйти на новый уровень, то она прекращает развиваться и очень скоро скатывается вниз (хорошо, если не глубоко).
Я сам большой фанат концепции Shu-Ha-Ri и особенно меня порадовал русский перевод на Википедии. Цитирую:
Когда тело, наконец, освободилось от всех правил - уровень Ри достигнут и начинается фаза Сю в новом измерении.😀Если серьезно, то пройдя тест я увидел график, где мне показали отклонения от средней линии среди всех прошедших. Т.е. на мой взгляд, это как раз и может показать, что моя команда достигла уровня Ha и мы движемся выше, или наоборот, мы еще застряли на базовом уровне и даже не дотягивем до остальных.
Если же моя команда настолько выдающаяся, то наши значения просто будет зашкаливать 😀
Имхо, такое сравнение команды с фиксированным эталоном имеет смысл только на стадиях Shu или Ha (ShuHaRi, впервые видел у Коберна http://alistair.cockburn.us/Shu+Ha+Ri.
На стадии Ri эталон – идеальная приспособленность к конкретным условиям :-). На этом этапе важно, насколько ты хорошо ты адаптируешься. Это может включать какие-то общепринятые практики, а может и нет. Команда делает то, что лучше всего работает в данных условиях.
Хотя, большинство команд работают именно на первых двух уровнях. Да, для них этот тест будет полезен.
Дмитрий, некоторые думают, что если команда достигла “уровня” и замечательно делает свое дело, то им и не зачем себя сравнивать 😉
С другой стороны, если команда не пытается дальше выйти на новый уровень, то она прекращает развиваться и очень скоро скатывается вниз (хорошо, если не глубоко).
Я сам большой фанат концепции Shu-Ha-Ri и особенно меня порадовал русский перевод на Википедии. Цитирую:
Когда тело, наконец, освободилось от всех правил - уровень Ри достигнут и начинается фаза Сю в новом измерении.😀Если серьезно, то пройдя тест я увидел график, где мне показали отклонения от средней линии среди всех прошедших. Т.е. на мой взгляд, это как раз и может показать, что моя команда достигла уровня Ha и мы движемся выше, или наоборот, мы еще застряли на базовом уровне и даже не дотягивем до остальных.
Если же моя команда настолько выдающаяся, то наши значения просто будет зашкаливать 😀