Метрики и оценка команд
Nataliya Trenina
--
Nataliya Trenina
Co-Owner & Agile coach @ SCRUMguides
Conference Producer @ Agile Eastern Europe
Founder & Facilitator @ InnovationFriends
Social profiles:
nattrenina For urgent matters: +38 050 412 61 35
Alexey Krivitsky
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
Alexey Krivitsky
Mikalai Alimenkou
Alexey Krivitsky
Illya
Украинские компании могут создавать любые метрики, нарушать базовые принципе Agile Manifesto, лепить все что угодно из того, что у них есть – это их право, только не надо тогда называть это Agile.
У нас вообще в Украине, по моему мнению, происходит подмена понятий. Меняются вывески и компании становится «гибкими». Только одна проблема – когда заходишь в их офис то почему то улавливаешь стойкий запах PMI и Command-Control стиля. А еще у них куча приятных вещей и практик, которые объединяются под ласковым названием ScrumBut. То, что в подавляющем большинстве украинские компании не могут работать с Agile – это проблемы компаний и их менеджеров, а не Agile.
Вчера в Киеве на IT Weekend и я слышал от одного «гибкого» менеджера про то как он работает со своими «подчиненными» и что предпочитает не обедать со своей командой, чтобы держать линию «менеджер-подчиненные». Хотелось спросить что он делает здесь на IT Weekend. Врожденная скромность помешала мне сделать это.
Фокус-фактор - отличная метрика, но точно не индивидуальное велосити. Об опасности использования этой метрики упоминает Майк Кон в Agile Estimation and Planning. Действительно, а зачем мне тогда помогать моего товарищу с его задачей если это зачтется ему, а не мне?
Илья
Social profiles: Ошибка! Не
указано имя файла. Ошибка! Не указано имя файла. Ошибка! Не
указано имя файла. Ошибка! Не указано имя
файла.nattrenina
For urgent matters: +38 050 412 61 35
--
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7482 (20120915) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
Nataliya Trenina
суббота, 15 сентября 2012 г. пользователь Mikalai Alimenkou писал:
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
Nataliya Trenina
воскресенье, 16 сентября 2012 г. пользователь Illya писал:
Украинские компании могут создавать любые метрики, нарушать базовые принципе Agile Manifesto, лепить все что угодно из того, что у них есть – это их право, только не надо тогда называть это Agile.
У нас вообще в Украине, по моему мнению, происходит подмена понятий. Меняются вывески и компании становится «гибкими». Только одна проблема – когда заходишь в их офис то почему то улавливаешь стойкий запах PMI и Command-Control стиля. А еще у них куча приятных вещей и практик, которые объединяются под ласковым названием ScrumBut. То, что в подавляющем большинстве украинские компании не могут работать с Agile – это проблемы компаний и их менеджеров, а не Agile.
Вчера в Киеве на IT Weekend и я слышал от одного «гибкого» менеджера про то как он работает со своими «подчиненными» и что предпочитает не обедать со своей командой, чтобы держать линию «менеджер-подчиненные». Хотелось спросить что он делает здесь на IT Weekend. Врожденная скромность помешала мне сделать это.
Фокус-фактор - отличная метрика, но точно не индивидуальное велосити. Об опасности использования этой метрики упоминает Майк Кон в Agile Estimation and Planning. Действительно, а зачем мне тогда помогать моего товарищу с его задачей если это зачтется ему, а не мне?
Илья
From: agile-...@googlegroups.com [mailto:agile-...@googlegroups.com] On Behalf Of Mikalai Alimenkou
Sent: Saturday, September 15, 2012 10:52 PM
To: agile-...@googlegroups.com
Subject: [agile-ukraine] Re: нЕФТЙЛЙ Й ПГЕОЛБ ЛПНБОД
Наташа, у тебя, мне кажется, такого опыта не будет именно потому, что ты и есть в альтернативной реальности. В той, которая не работает в украинских компаниях и аутсорс командах. Я их прекрасно понимаю. Им надо лепить из того что есть, а не отбирать только лучших и самых талантливых как хотелось бы для настоящей Agile команды (к сожалению). Поэтому метрики эффективности очень для них полезны, иначе на нашем рынке им не выжить.
А метрики эффективности в Agile командах считать можно, вот только делать это нужно, исходя из контекста. Тут замечательно работает и фокус-фактор, и 360 рекомендаций, и персональное велосити. Просто вопрос любой метрики в ее использовании. Если от нее будет зависеть напрямую ЗП человека, то это все испортит. Если нет, то все будет хорошо.
Без купюр, мне кажется, что настоящий ScrumMaster легко определит такие метрики из контекста, даже без помощи команды. Главное не ошибиться с их применением...
А философские рассуждения по поводу "оценивать нужно только команду целиком", "метрики в Agile бесполезны, главное рабочий продукт", "нет отдельных людей, есть команда" больше сгодятся для теоретических разговоров под пиво... :)
On Saturday, September 15, 2012 9:49:49 PM UTC+3, Nat wrote:Приветы тут,
Народ, а подскажите, кто какие метрики/асессменты использует? Слышала, крупные компании разрабатывают собственные 'аджайльные' системы оценки эффективности работы..
Как оцениваете - индивидуально или командно? Как это полезно? И главный вопрос: как связана оценка и рекомендации по развитию? Насколько я понимаю, тот же 'метод 360' рекомендаций 'а что делать?' не дает.
У меня такого опыта нет (надеюсь, и не будет))), но было бы полезно знать альтернативные реальности.
Заранее спасибо!
Ната
--
Nataliya Trenina
Co-Owner & Agile coach @ SCRUMguides
Conference Producer @ Agile Eastern Europe
Founder & Facilitator @ InnovationFriends
Social profiles: Ошибка! Не указано имя файла. Ошибка! Не указано имя файла. Ошибка! Не указано имя файла. Ошибка! Не указано имя файла.nattrenina
For urgent matters: +38 050 412 61 35
__________ Information from ESET NOD32 Antivirus, version of virus signature database 7482 (20120915) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
Illya
ьФП ВЩМ ОЕ ДПЛМБДЮЙЛ, Л УЮБУФША )). рТПУФП РЕТЕУЕЛУС У ЬФЙН НЕОЕДЦЕТПН ОБ ЛПОЖЕ.
From: agile-...@googlegroups.com
[mailto:agile-...@googlegroups.com] On Behalf Of Nataliya Trenina
Sent: Sunday, September 16, 2012 9:55 AM
To: agile-...@googlegroups.com
Subject: Re: [agile-ukraine] Re: Оежфкмк к рзепмв мровпд
йМШС, УРБУЙВП ЪБ РЙУШНП. рПЮФЙ ТБУЛТЩМ РТЙЮЙОЩ, РП ЛПФПТЩН С ФБЛ ЪБЙОФЕТЕУПЧБМБУШ НЕФТЙЛБНЙ :)
оП ПДОЙИ ЬНПГЙК ОЕ ДПУФБФПЮОП, ИПЮХ ЪОБФШ ВПМШЫЕ ДЕФБМЕК, ЮФП ВЩ ЧМЙСФШ ОБ УЙФХБГЙА.
уЛБЦЙ, Б ЛБЛ ЪЧБМЙ ЗЙВЛПЗП НЕОЕДЦЕТБ? :) ч НЕОС ЧУФТПЕОБ ЖХОЛГЙС УЙФХБФЙЧОПЗП ПФЛМАЮЕОЙС ЧТПЦДЕОПК УЛТПНОПУФЙ, ЛПЗДБ ТЕЮШ ЙДЕФ П ГЕООПУФСИ Й 'ЙННЙДЦЕ' ЗЙВЛПК ТБЪТБВПФЛЙ. иПЮХ РПУНПФТЕФШ ЧЙДЕП ЕЗП ДПЛМБДБ, ЕУМЙ ЕУФШ.
оБФБ
ЧПУЛТЕУЕОШЕ, 16 УЕОФСВТС 2012 З. РПМШЪПЧБФЕМШ Illya РЙУБМ:
хЛТБЙОУЛЙЕ ЛПНРБОЙЙ НПЗХФ УПЪДБЧБФШ МАВЩЕ НЕФТЙЛЙ, ОБТХЫБФШ ВБЪПЧЩЕ РТЙОГЙРЕ Agile Manifesto, МЕРЙФШ ЧУЕ ЮФП ХЗПДОП ЙЪ ФПЗП, ЮФП Х ОЙИ ЕУФШ – ЬФП ЙИ РТБЧП, ФПМШЛП ОЕ ОБДП ФПЗДБ ОБЪЩЧБФШ ЬФП Agile.
х ОБУ ЧППВЭЕ Ч хЛТБЙОЕ, РП НПЕНХ НОЕОЙА, РТПЙУИПДЙФ РПДНЕОБ РПОСФЙК. нЕОСАФУС ЧЩЧЕУЛЙ Й ЛПНРБОЙЙ УФБОПЧЙФУС «ЗЙВЛЙНЙ». фПМШЛП ПДОБ РТПВМЕНБ – ЛПЗДБ ЪБИПДЙЫШ Ч ЙИ ПЖЙУ ФП РПЮЕНХ ФП ХМБЧМЙЧБЕЫШ УФПКЛЙК ЪБРБИ PMI Й Command-Control УФЙМС. б ЕЭЕ Х ОЙИ ЛХЮБ РТЙСФОЩИ ЧЕЭЕК Й РТБЛФЙЛ, ЛПФПТЩЕ ПВЯЕДЙОСАФУС РПД МБУЛПЧЩН ОБЪЧБОЙЕН ScrumBut. фП, ЮФП Ч РПДБЧМСАЭЕН ВПМШЫЙОУФЧЕ ХЛТБЙОУЛЙЕ ЛПНРБОЙЙ ОЕ НПЗХФ ТБВПФБФШ У Agile – ЬФП РТПВМЕНЩ ЛПНРБОЙК Й ЙИ НЕОЕДЦЕТПЧ, Б ОЕ Agile.
чЮЕТБ Ч лЙЕЧЕ ОБ IT Weekend Й С УМЩЫБМ ПФ ПДОПЗП «ЗЙВЛПЗП» НЕОЕДЦЕТБ РТП ФП ЛБЛ ПО ТБВПФБЕФ УП УЧПЙНЙ «РПДЮЙОЕООЩНЙ» Й ЮФП РТЕДРПЮЙФБЕФ ОЕ ПВЕДБФШ УП УЧПЕК ЛПНБОДПК, ЮФПВЩ ДЕТЦБФШ МЙОЙА «НЕОЕДЦЕТ-РПДЮЙОЕООЩЕ». иПФЕМПУШ УРТПУЙФШ ЮФП ПО ДЕМБЕФ ЪДЕУШ ОБ IT Weekend. чТПЦДЕООБС УЛТПНОПУФШ РПНЕЫБМБ НОЕ УДЕМБФШ ЬФП.
жПЛХУ-ЖБЛФПТ - ПФМЙЮОБС НЕФТЙЛБ, ОП ФПЮОП ОЕ ЙОДЙЧЙДХБМШОПЕ ЧЕМПУЙФЙ. пВ ПРБУОПУФЙ ЙУРПМШЪПЧБОЙС ЬФПК НЕФТЙЛЙ ХРПНЙОБЕФ нБКЛ лПО Ч Agile Estimation and Planning. дЕКУФЧЙФЕМШОП, Б ЪБЮЕН НОЕ ФПЗДБ РПНПЗБФШ НПЕЗП ФПЧБТЙЭХ У ЕЗП ЪБДБЮЕК ЕУМЙ ЬФП ЪБЮФЕФУС ЕНХ, Б ОЕ НОЕ?
йМШС
Nataliya Trenina
--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com
Borys Lebeda
Borys L.
Nataliya Trenina
Будет время - можем где-то по кофе пересечься, как альтернатива длинным письмам.
Ната
Mikalai Alimenkou
Mikalai Alimenkou
В приведеннмом тобой примере я бы действовал в зависимости от контекста. Если вся команда технически развита, то я бы начал больше делегировать и отпускать ее в открытое плавание. Если нет, то пришлось бы им "потерпеть", но я бы максимум усилий приложил, чтобы смягчить отношения. Без этой информации мне бы было гораздо тяжелее. По метрикам я когда-то давно делал на Agile Gathering доклад, могу как-нибудь при личной встрече обновить информацию. :) Сюда писать долго...
sergiy movchan
По метрикам я когда-то давно делал на Agile Gathering доклад, могу как-нибудь при личной встрече обновить информацию. :) Сюда писать долго...
...dali bude...
Alexander Rivkind
Best Regards, Alik.
lIlya Pavlichenko
Илья.
Borys Lebeda
Можно ли узнать у Вас какие решения они принимают на ретроспективах?
2012/9/16 lIlya Pavlichenko <fanc...@gmail.com>:
> Я тоже знаю проекты и отдельные компании, работающие в полноценном скраме.
> Надеюсь, что их количество будет постоянно увеличиваться.
>
> Илья.
>
>
> 16 сентября 2012 г., 16:16 пользователь Alexander Rivkind
> <alik...@gmail.com> написал:
>
>> Как все пафосно-то...
>> Тебя чем-то обидели "украинские компании"?
>> Я знаю минимум одну компанию в украине, в который есть полноценный скрам.
>> Таким образом, твое общее утверждение - ложно.
>>
>>
>> 2012/9/16 Illya <fanc...@gmail.com>
>>>
>>> Украинские компании могут создавать любые метрики, нарушать базовые
>>> принципе Agile Manifesto, лепить все что угодно из того, что у них есть -
>>> это их право, только не надо тогда называть это Agile.
>>>
>>> У нас вообще в Украине, по моему мнению, происходит подмена понятий.
>>> Меняются вывески и компании становится <<гибкими>>. Только одна проблема -
>>> когда заходишь в их офис то почему то улавливаешь стойкий запах PMI и
>>> Command-Control стиля. А еще у них куча приятных вещей и практик, которые
>>> объединяются под ласковым названием ScrumBut. То, что в подавляющем
>>> большинстве украинские компании не могут работать с Agile - это проблемы
--
Borys L.
lIlya Pavlichenko
Напиши мне в личку что тебя конкретно интересует, я отвечу с удовольствием.
Илья.
Borys Lebeda
команды, ни проекта.
Могу его переформулировать в таком виде: нужен пример решения
принятого на ретроспективе и осуществлённого в последствии, в команде
работающей на полноценном скраме.
Что бы мы не сильно уходили от темы, пусть это будет решение,
касательно метрик эффективности.
Вопрос о том, как это было сделано можно перенести и в личку, если он
не будет интересен остальным.
2012/9/16 lIlya Pavlichenko <fanc...@gmail.com>:
Nataliya Trenina
Если все-таки вернуться к теме ветки - интересно, какие показатели кроме командной велосити и фокус-фактора используются в скрам-командах? Мне даже не важно, на самом деле, насколько скрам "настоящий". Что бы мы не ушли, случайно, в определение "настоящести" :))
Ната
--
nattrenina 
Sergii Malyi
Велосити и фокус-фактор - это метрики, ориентированные на ИБД (для непосвященных расшифровую - имитацию бурной деятельности). Если нас интересует, какой РЕЗУЛЬТАТ приносит наша работа, то и мерять нужно результат.
Sincerely,
Sergii Malyi
Nataliya Trenina
Еще раз вопрос, сужаю уже как могу:
Интресны кейсы с работающими в компаниях ассессментами, которые используются уже какое-то время (уже внедрены) и приносят пользу (есть примеры организационных решений, принятых на основе показателей, которые помогли улучшить показатели в следующей итерации). О таких кейсах интересно следующее:
- что именно меряется?
- есть ли связь асессмента с рекомендациями по улучшению показателя?
Насчет метрик результата и процесса. Я бы не была столь категорична с ИБД. Вот НАСА, например, после ряда эпических проектных фейлов, разработали систему метрик социального контекста проекта. Да-да, представляете? Ужас какой, такой туман мерить. И уже лет 6 используют, и у себя, и у подрядчиков, и вполне конкретно уменьшили число фейлов и повысили качество РЕЗУЛЬТАТА. Забавно знать как коррелирует успех проекта со средним числом "спасибо!" и "круто!", которые слышит инженер за рабочий день.
Поэтому, меня интересуют любые метрики - и процесса (типа скорость прохождения фичи от постановки в беклог до деплоя) и результата (типа количество багов в релизе, время починки бага на саппорте).
Раз уж всех так интересуют метрики, хотелось бы подумать над тем, какие из них действительно полезны и как сделать асессмент живым инструментом, более близким к обратной связи, чем к оценке для "мотивации".
Н.
Ilya Pavlichenko
Не знаю, может быть Метрика Счастья уже обсуждалась прежде, но я на ее набрел относительно недавно.
Все довольно просто.
Мы постоянно отслеживаем индекс счастья на проекте (в компании), который может колебаться от 1 до 5.
Это можно делать , к примеру, на каждой ретроспективе.
Интересный луп, найденный Книбергом:
1. Счастливые-замотивированные сотрудники делают лучше свою работу и в результате кастомеры становятся более счастливыми.
2. Большее количество счастливых кастомеров приносит больший доход.
3. Больший доход означает, что люди могут позволить себе потратить больше время на то, что им интересно, изучение нового.
4. Последнее в результате дает нам еще более компетентных и замотивированных сотрудников.
…И так далее снова по кругу.
Индексы постоянно отслеживаются и если у кого то он падает до 1, 2 то это тревожный сигнал и мы на ретроспективе убираем Impediment.
Книберг использует эту метрику как ведущую в своей компании Crisp.
Джефф Сазерленд применил ее в компании ScrumInc и утверждает, что благодаря этому прирост велосити 500% и Net Revenue 200%
Сазерленд немного модифицировал идею и отслеживает 2 индекса Счастья – для проекта и для компании.
Прикольный момент – индекс можно визуализировать и отображать на графике, будет видно как Счастье прибывает и убывает со временем.
Ссылки:
http://blog.crisp.se/2010/05/08/henrikkniberg/1273272420000
http://scrum.jeffsutherland.com/2010/11/happiness-metric-wave-of-future.html
http://scrum.jeffsutherland.com/2010/12/scrum-inc-sprint-2-retrospective.html
Best Regards,
Illya Pavlichenko, CSM, CSPO, PSM, PMI-ACP
Agile Principal Believer
Skype: pavlichenko.ilya
Email: fanc...@gmail.com
Tel.: +(38) 0961585813
2012/9/16 Nataliya Trenina <nat.t...@gmail.com>
Social profiles: nattrenina
Vlad Savitsky
Borys Lebeda
Это уже что-то.
Здесь однако есть одна ловушка. Действительно хорошая и качественная работа выполняется мотивированным сотрудником, но вот обратное неверно: за последний год мне попалось как минимум три человека, которые счастливы, когда работают плохо и безответственно. ИЧСХ если им начать говорить про ответственность у них этот показатель падает. Это вносит помехи в средний показатель.
Как следствие, метрик счастья у нас не используют: все равно нужен индивидуальный подход
А объективные метрики выносились на обсуждение?