Zenegment

Недавно разговорились с братом ТыжМенеджером про всякое. Он как раз был на тренинге для тренеров и рассказывал об услышанном. Мне было интересно, потому что я ни разу на тренинге для тренеров не был.
В частности Саша рассказал про модель того, как люди учатся:


В реальности для получения долгосрочных результатов нам нужно, чтобы сотрудники меняли отношение к тому, что они делают. Однако на тренинге все, что можно с сделать с человеком – это дать ему знания и немножечко навыков, а на изменение отношения к работе это влияет очень косвенно и сильно посредственно. В итоге основная задача тренера – давая знания (которые по моим наблюдениям и так уже у большинства есть) и чуть-чуть (на сколько позволяет тренинг) поотрабатывать навыки, поменять отношение человека. Это напомнило мне один недавний эпизод из моей жизни…

( Collapse )

Присланное очень мудрым человеком, пожелавшим остаться неизвестным. Предыстория рассказа про грейдинг.



Действующие лица:

• Алексей – эффективный менеджер, получающий зарплату за спрашивание даты у одного человека и тупую ее трансляцию другому.
• Женя – программист, обычно дающий оценку с нулевой вероятностью. В прошлом работал с нормальным менеджером, который знал, как составляются календарные графики на основе таких оценок.
• Василий - программист, который умеет давать очень точные оценки. Он обладает аномальным вниманием к деталям и феноменальной способностью предвидеть возможные неприятности.
• Карина - активная, местами даже гиперактивная женщина средних лет, HR-директор. Недавно в ее карьере случилось важнейшее событие. И последнее время ее состояние близко к состоянию программиста, который получил разрешение на переписку с нуля двадцатилетнего легаси приложения. К сожалению, она до сих пор путает мотивацию со стимуляцией.
• Николай - ведущим программист на одном из проектов компании. По натуре своей достаточно застенчив.

( Collapse )

В одной малоизвестной компании работал программист, который умел давать очень точные оценки. Он обладал аномальным вниманием к деталям и феноменальной способностью предвидеть возможные неприятности.

( Collapse )

Вот такая вот сказка, как обычно, не имеющая никакой связи с реальностью.

В переговорке, оккупированной под проведение планирования, стояла тяжелая атмосфера. Решение не давалось. Помимо ведущего архитектора Ивана Константиновича и его "правой руки", подающего большие надежды программиста  Василия, на мозговом штурме присутствовали:
Марк Захарович, директор департамента;

...

Продолжение в блоге автора (Green FiLin)
(просто, что бы все собрать под одним тегом)

В переговорке стояло напряжение. После очередного изменения содержания проекта компания-подрядчик выкатила Юрию счет, казавшийся ему просто не реальным. Хуже того, это было уже десятое изменение по ходу проекта, и десятый раз ему выкатывали изменение в бюджете и сроках! По мнению Юрия такое поведение выходило за рамки приличий, потому он и созвал эту встречу.

–Господа, у нас в очередной раз сдвигаются сроки окончания проекта, и я уже не говорю о том, что стоимость уже не сравнима с вашей начальной оценкой. Не кажется ли вам, что вы могли бы быть вести себя более гибко по отношению к изменениям в проекте? – начал Юрий

–Гибко – это, что бы мы и наши бюджеты растягивались в след за вашими пожеланиями? – спросил генеральный директор подрядчика?

–Так сильно, будто мы резиновые, - тихо саркастично пробормотал менеджер проекта.

–То есть вели себя как хорошие гандоны, - заметил седобородый архитектор.

Очень нужен сильный и мудрый специалист мне в отдел.

Нужно стать самым главным техническим спецом по системе, построенной на базе BMC Remedy. Человек ранга архитектора.

Высокие нагрузки, распределенность и прочие заморочки гарантируем.

Это не просто автоматизация внутреннего сервис-деска, все на много круче!


( Collapse )

Хорошему человеку и много денег не жалко...

Шикарный рассказ Сергея Мартыненко о целях, тестировании и требованиях.

Потратил час своего времени и очень доволен. Настоятельно рекомендую посмотреть всем разработчикам, тестировщикам, менеджерам, архитекторам, а не только аналитикам.

Сергей рассказывает о не сложных вещах, приносящих большую пользу. Cобственными глазами видел, как Сергей использует в своей работе то, о чем он здесь говорит.


Сергей Мартыненко. Написание тестов, как вид тестирования требований from Grigoriy Pechenkin on Vimeo.

Я все еще верю в чудеса.

Решил посмотреть процессный шаблон для Scrum-a от CodePlex.com. Они называют себя Open Source Community, так, может быть, они сделали что-либо достойное? Ладно MS бросило свои лучшие силы на нечто отличное от подготовки процессного шаблона MSF for Agile, может быть опенсорсные ребята сделали лучше?..

Первое, что напрягло - это 7 ролей... При этом среди них нет роли Product Owner. Зато есть Архитектор и Аналитик. Ну ладно. Ну допустим. Ну когда система какая-то мега-сложная и у команды нет понимания предметной области вообще, то можно предположить, что потребуются два отдельных персонажа для проработки архитектуры и объяснения что же все-таки заказчик хочет.

Второе. Роли, которая отвечает за расстановку приоритетов обнаружить не удалось. Все мы знаем, что этим должен заниматься Product Owner, но вдруг ребята из CodePlex назвали его как-то по-другому? Поковырялся и увидел, что за это отвечают целых две роли. Аналитик defines the business opportunity и Project Manager (!!!) is focused on ensuring that the team delivers business value. А еще Project Manager отвечает за то, чтобы команда была a “happy” and productive ecosystem. Сразу же вспомнилась картинка их ЖЖ Саши Орлова (eagleson ), которую упру сюда, сказав спасибо Андрею Чеканову:
Ладно, сдержу эмоции по поводу присутствия таких ролей как Tester и Release Manager. Зря забыли добавить QA Manager, Configuration Manager, Test Manager, Coffee Manager, Pizza Manager... Это же не просто Scrum, это - Light Weight Scrum.

Пошел смотреть Work Items. Первые два ввели в ступор: BackLog Item и User Story... Еще раз... User Story и BackLog Item... И это разные сущности... И вот зе факин диференс? User Story имеет 17 различных полей BackLog Item - 18 и при этом одно от другого отличается минимум пятью полями.
Среди ворк итемов не нашел Task, зато есть Defect. Правильно.

Но зато в отличие от MSF for Agile у них в репортах есть Burn-down chart!!!! Прогресс? Хрен! Длина итерации где-то жестко забита в 1 месяц. И легкого пути изменить ее на 2 недели я не нашел.

В единственном месте, где можно отойти от канонического определения скрама (длина итерации) все закожено насмерть. В местах, где отходить от канонического определения, мягко говоря, не рекомендуется - нет ни одного попадания.

Побродил, покликал. В общем, одно расстройство.

У меня возникло ощущение, что все это время я учил ребят какому-то неправильному скраму.

Коллеги, кто-нибудь использует MSF для скрама? Поделитесь пожалуйста как?

P.S. Теперь не жалею, что  потратил сегодня полтора командо-часа за которые мы инициализировали пробковую доску. Теперь она вся в бумажках.