Показаны сообщения с ярлыком agile. Показать все сообщения
Показаны сообщения с ярлыком agile. Показать все сообщения

понедельник, 1 марта 2010 г.

Как использовать scrum board плагин для mantis

Недавно, я представил Вашему вниманию своё детище - scrum board интегрированный в mantis и вкратце рассказал о том, что нужно сделать, чтобы "детище" работало.

В этой заметке я хочу рассказать о том, как организовать работу в баг трекере, чтобы максимально плодотворно использовать "детище".

Итак, по порядку...

Допустим в Вашей компании есть несколько постоянных проектов и эти проекты дорабатываются с использованием методологии scrum или проекты постоянно новые и каждый тоже по scrum'у работает. Тогда делаем так...

Вы в своём mantis'е создаёте проект, например, с названием "Проекты в производстве" - этот проект будет хранить в себе глобальные задачи или же можно сказать будет хранилищем скрамов.


Создаём отчёт (теперь этот отчёт является скрам сессией) в проекте под названием "Проекты в производстве" и добавляете в качестве тегов названия историй этого скрама.


Итак, у нас есть скрам сессия, если можно я её буду назвыать так и привязанные к ней истории. Уже неплохо... :)

Теперь, все баги, задачи, тикеты, отчёты, вопросы в вашем баг трекере которые имеют тег=названию истории (если Вы ещё не забыли истории мы указываем в качестве тегов к головному отчёту) будут отображаться в scrum board'е этой скрам сессии как задачи по истории тег которой Вы привязали.



В отчётах-задачах не забывайте проставлять планируемое время на выполнение задачи в рамках скрам сессии. Это время будет отображаться в srum board'е. Также для удобства связывайте все отчёты-задачи по скраму с головным отчётом, чтобы открыв головной отчёт можно было увидеть как истории этой скрам сессии посмотрев на теги, так и все задачи по этой скрам сессии.


Теперь у нас есть головной отчёт - скрам сессия, истории - теги и задачки - баги раскиданные по багтрекеру и все эти сущности связаны тегами и связями, простите за тафтологию.

Пойдёмте, посмотрим на scrum board... Кликаем по ссылке scrum board в главном меню mantis'а, среди проектов выбираем "Проекты в производстве" и дальше выбираем нужную нам скрам сессию. Переходим к scrum board'у...

  • Столбец History включает в себя все теги истории которые привязаны к головному отчёту.
  • Столбец To Do включает в себя все отчёты-задачи со статусом новый (new).
  • Столбец Doing включает в себя все отчёты-задачи со статусами нужен отклик, рассмотрен, подтверждён, назначен (feedback, acknowledged, confirmed, assigned).
  • Столбец Testing включает в себя все отчёты-задачи со статусом решён или обработан (resolved), у кого как в mantis'е заведено.
  • Столбец Closed соответственно включает в себя все отчёты-задачи со статусом закрыто (closed).

Для столбцов To Do, Doing, Testing, Closed считается суммарное время, т.е., например, сколько запланировано времени в скрам-сессии на новые задачи. А внизу отдельной табличкой вынесено суммарное время на историю по всем типам задач.

Вот вроде бы и всё....

З,Ы, Если что-то забыл или кому-то непонятно моё повествование, пишите на почту или в комментарии к заметке, постараюсь всё объяснить!

пятница, 12 февраля 2010 г.

Митинг как необходимая часть рабочего процесса...

Википедия гласит:
Митинг (англ. meeting — собрание) — массовое собрание для обсуждения злободневных вопросов текущей жизни, в поддержку определённых требований, так и для выражения солидарности или протеста.

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

Такие митинги называются по-разному. В Scrum - это Daily Scrum Meeting, в XP - это stand-up meeting. Иногда его называют просто Status Meeting. В Luxoft его принято называть Daily Scrum или просто скрам. Так зачем нужен скрам?

Основная цель скрама — синхронизация работы команды. Каждый член команды должен знать чем занимаются другие люди. Что дает такое знание? Прежде всего минимизацию напрасной траты времени, связанной с недостаточной осведомленностью членов команды.
Длительность этого митинга строго ограничена — она не должна превышать 15 минут. Скрам не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за его пределы.

А как Вам такой взгляд на митинги?!
К сведению:
Федеральный закон от 19 июня 2004 г. № 54-ФЗ «О собраниях, митингах, демонстрациях, шествиях и пикетированиях» формулирует митинг как «массовое присутствие граждан в определённом месте для публичного выражения общественного мнения по поводу актуальных проблем преимущественно общественно-политического характера».

четверг, 28 января 2010 г.

Денежная мотивация в проектах разработки ПО

Автор: Асхат Уразбаев

Допустим, у вас есть много денег и вы хотите вложить их повышение производительности ваших сотрудников. Есть один простой способ. Платите сотруднику пропорционально производительности. Большой выхлоп - много денег. Малый выхлоп - мало денег. В соответствии с теорией Павлова у сотрудника выработается условный рефлекс и он будет брызгать слюной к каждой выплате. Работает ли это? Конечно! С токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского. А вот с программистами не работает. И проблемы тут такие.

Проблема измеримости выхлопа
Нету линейки для программиста. Аршином общим не измерить. У них особенная стать. Ведь что такое производительность программиста? Кол-во строчек кода за единицу времени? Бред! Копипейст или просто выбор инструментов и подходов может породить практически любое кол-во. Кол-во багов? Не ошибается тот, кто ничего не делает. Ничего не пишем — нету и багов. Кол-во исправленных багов? Так ведь никакого героизма в исправлении багов нет. Смысл в том, чтобы не писать багов. Не хватало еще поощрять за их исправление! Задачка на полчаса — написать утилиту, которая путем внесения багов в код и исправлением их после репорта от тестера максимизирует ваш бонус. В общем, есть только один инструмент — произвол менеджера. Менеджер — это такой мудрый чувак, который знает, кто и как работает. А как он знает? А в этом и есть тайное знание менеджера и за это он получает деньги. А как он меряет своих ребят? У него есть ощущения. Например, если вы менеджеру кажется, что вы тормоз, то вам выставят BE (below expectations). Или, например, сделают вам маленький КТУ (коэффициент трудового участия). А ведь иметь маленький кту стыдно… Или еще как-нибудь вам дадут понять, что вы тормоз. Это называется «предоставить фидбек».

Проблема короткодействия денежной мотивации
Представьте, что у вас с вашим менеджером совет да любовь. Вам дали много денег (тем или иным способом) и вы садитесь за свой стол. Теперь вы, видимо, будете писать больше кода в единицу времени? Ну как же, вас же мотивировали! Раньше вам мало платили и вы нажимали на клавиши с ленцой, теперь такого вы не допустите. Стучать будете как стенографистка. Или может, теперь вы будете меньше багов делать? Да с чего вдруг? В общем, эффект будет сомнительным. Мотивация деньгами действует полчаса. Как только вы похвастались жене в аське — все! Вам уже мало.

Проблема конкурентности
А вот если, например, вас лишили премии. Что характерно, вашего товарища Васю при этом поощрили. Вы, конечно, расстроитесь. Но в то же время как-то соберетесь, мобилизуетесь и будете стараться . Да? Скорее всего - нет. Вы обидитесь на вашего менеджера (вы-то думали он друк!) и вашим любимым сайтом отныне будет hh.ru. Но пусть даже это не так. Ваши чувства к мудрому руководителю не угасли! Вы почувствовали справедливость его слов, и вашей целью отныне является то, чего хотел добиться Коля Остен-Бакен от Инги Зайонц - взаимности. Все лишние мысли - вон! Только работа. Остаемся по ночам. Пишем только качественный код (как, кстати, это делать по ночам?). И вот подходит к вам удачливый соперник Вася и просит помочь. Нет, вы не откажете. Вы не такой. Вы ему поможете — как только у вас появится время. То есть никогда. Вашего менеджера можно поздравить. Его крутая система мотивации уничтожила взаимопомощь и взаимовыручку в команде. А менеджер будет трагически говорить на ежеквартальных отчетах начальству: «Пора уже вам тщательнее подходить к подбору персонала! А то набираете сплошных безответственных уродов! Невозможно работать!» Так почему это работает с токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского? Все просто. Их труд можно легко измерить и от них не требуется командная работа. А денег должно просто хватать. Их уровень должен быть комфортным. Все остальная мотивация — неденежная.

Бонусы бесполезны?
Бонусы бесполезны? Я этого не утверждал. Я только хотел сказать, что с бонусами надо быть очень осторожным. А все дело в том, что деньги — это очень важно. А потому бонусы — очень мощный инструмент воздействия на сотрудников. Беда в том, что он не очень-то точный. А значит в большинстве бесполезный. Это как антибиотик широкого действия. Вы скорее всего зацепите инфекцию, но и убьете все полезные бактерии. Существуют правильные и полезные системы мотивации — и бонусы к ним не относятся. Недаром зарплату, бонусы и соцпакет называют компенсационным пакетом. Компания просто компенсирует вам тот прискорбный факт, что вам приходится ходить на работу вместо того, чтобы заниматься другими интересными штуками. В том числе и работать на более щедрую компанию :-). Вы просто не сможете настроить систему бонусирования достаточно точно. Ну, к примеру, вы выстроили классную схему. По ходу дела вы учли все ошибки и она стала идеальной. Вы решили, что бонусы должны быть высокими, если программисты работают в соответствии со своим планом. Если они отстают - бьем их рублем. Ведь это так прекрасно работает с консультантами! На самом деле у консультантов все супер просто потому, что у них есть нормативы. Известно, сколько времени на самом деле занимает задача. А у нас программисты сами оценивают свою работу. Вскоре выясняется, что люди перезакладываются — дают заведомо завышенные оценки. Вы уточнили формулу. Если человек успевает раньше плана - это тоже понижает бонус. Разумеется, надо учесть, что опередить в два раза — явное разгильдяйство, а сэкономить 10% квалифицируется как трудовой подвиг. Вы не сдерживаетесь и, как человек с высшим техническим образованием, подбираете полиномиальную функцию. Она правильно аппроксимирует бонусное вознаграждение в зависимости от плановых и реальных параметров. Там есть еще и весовые коэффициенты для разных типов задач (багфиксинг!=разработка нового), учет приоритетов проекта и прочие вещи, которые вы посчитаете важными. Ваша формула идеальна. Вы, как творец, испытываете гордость создателя. Вы рассчитываете, что программисты, понукаемые жаждой наживы, будут ответственно относится к оценкам трудозатрат и стараться успевать делать работу в срок, станут учитывать приоритеты работ и правильно вести свои трудозатраты в корпоративной системе учета. На самом деле тут может быть два варианта. Если бонусы в среднем относительно небольшие (ну, скажем, меньше 20% от зарплаты), то большинство людей будут относится к их получению (или потере) как к лотерее. Повезло — не повезло. Дело в том, что вашу систему мотивации просто никто не поймет. Она слишком сложная. На самом деле вам повезло. В этом случае ваша система по крайней мере не нанесет ВРЕДА. Хуже, если бонусы действительно важны для людей. Народ займется оптимизацией выплат. Ваши местные великие комбинаторы довольно быстро придумают 400 сравнительно честных способов отъема денег у руководства. Все мысли будут крутиться вокруг денег. Обсуждения правильных стратегий учета трудозатрат будут самыми вдохновенными и креативными. Они займут львиную часть времени разработчиков. Это негативно скажется на производительности программистов. Бонус — это message. Вы как бы говорите сотруднику — «чувак, ты работаешь за бабло». Люди прекрасно чувствуют такие сообщения, даже если они неявны. Излишне, я надеюсь, говорить, что бонусы ни в коем случае не должны быть отрицательными. Никаких штрафов — это демотиватор. Кстати, если чувак рассчитывает на бонус и не получает его - на практике это равносильно штрафу. Да он уже запланировал купить на бонус новый ноутбук! А тут вы со своими «на самом деле бонусы являются необязательной частью, бла-бла-бла». И заверения в стиле «мамочка тебя все равно любит» тут не исправят ситуацию.

Так что же делать с бонусами?
По моему мнению, есть только один более или менее полезный способ использовать систему бонусирования в нашем с вами бизнесе. Кто нам мешает — тот нам поможет. Можно использовать бонус как способ транслировать правильный message сотрудникам. Мне в голову приходит только один пример. Можно использовать бонусы для того, чтобы сообщить людям, как руководству важно достижение бизнес результатов. Например, отстегивать часть маржи сотрудникам. Сможете ли вы этим повысить их производительность? Навряд-ли. Но они точно станут немного более бизнес-ориентированными. Это просто еще один способ правильно расставить приоритеты. Будет прекрасный повод поговорить с разработчиками о том, что за продукт мы пишем и как мы собираемся захватывать рынок. По моему мнению, размер бонуса не должен превратить сам бонус в предмет культа.

Источник

среда, 22 апреля 2009 г.

Денежная мотивация в проектах разработки ПО

Асхат Уразбаев, (askhat@scrumtrek.ru)

ДЕНЕЖНАЯ МОТИВАЦИЯ В ПРОЕКТАХ
РАЗРАБОТКИ ПО

Допустим, у вас есть много денег и вы хотите вложить их повышение производительности ваших сотрудников. Есть один простой способ. Платите сотруднику пропорционально производительности. Большой выхлоп - много денег. Малый выхлоп - мало денег. В соответствии с теорией Павлова у сотрудника выработается условный рефлекс и он будет брызгать слюной к каждой выплате. Работает ли это? КОНЕЧНО! С токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского. А вот с программистами НЕ РАБОТАЕТ. И проблемы тут такие.

ПРОБЛЕМА ИЗМЕРИМОСТИ ВЫХЛОПА

Нету линейки для программиста. Аршином общим не измерить. У них особенная стать. Ведь что такое производительность программиста? Кол-во строчек кода за единицу времени? Бред! Копипейст или просто выбор инструментов и подходов может породить практически любое кол-во. Кол-во багов? Не ошибается тот, кто ничего не делает. Ничего не пишем — нету и багов. Кол-во исправленных багов? Так ведь никакого героизма в исправлении багов нет. Смысл в том, чтобы НЕ ПИСАТЬ багов. Не хватало еще поощрять за их исправление! Задачка на полчаса — написать утилиту, которая путем внесения багов в код и исправлением их после репорта от тестера максимизирует ваш бонус. В общем, есть только один инструмент — произвол менеджера. Менеджер — это такой мудрый чувак, который знает, кто и как работает. А как он знает? А в этом и есть тайное знание менеджера и за это он получает деньги. А как он меряет своих ребят? У него есть ОЩУЩЕНИЯ. Например, если вы менеджеру кажется, что вы тормоз, то вам выставят BE (below expectations). Или, например, сделают вам маленький КТУ (коэффициент трудового участия). А ведь иметь маленький кту стыдно… Или еще как-нибудь вам дадут понять, что вы тормоз. Это называется «предоставить фидбек».

ПРОБЛЕМА КОРОТКОДЕЙСТВИЯ ДЕНЕЖНОЙ МОТИВАЦИИ

Представьте, что у вас с вашим менеджером совет да любовь. Вам дали много денег (тем или иным способом) и вы садитесь за свой стол. Теперь вы, видимо, будете писать больше кода в единицу времени? Ну как же, вас же мотивировали! Раньше вам мало платили и вы нажимали на клавиши с ленцой, теперь такого вы не допустите. Стучать будете как стенографистка. Или может, теперь вы будете меньше багов делать? Да с чего вдруг? В общем, эффект будет сомнительным. Мотивация деньгами действует полчаса. Как только вы похвастались жене в аське — ВСЕ! Вам уже МАЛО.

ПРОБЛЕМА КОНКУРЕНТНОСТИ

А вот если, например, вас лишили премии. Что характерно, вашего товарища Васю при этом поощрили. Вы, конечно, расстроитесь. Но в то же время как-то соберетесь, мобилизуетесь и будете СТАРАТЬСЯ. Да? Скорее всего - нет. Вы обидитесь на вашего менеджера (вы-то думали он ДРУК!) и вашим любимым сайтом отныне будет hh.ru. Но пусть даже это не так. Ваши чувства к мудрому руководителю не угасли! Вы почувствовали справедливость его слов, и вашей целью отныне является то, чего хотел добиться Коля Остен-Бакен от Инги Зайонц - взаимности. Все лишние мысли - вон! Только работа. Остаемся по ночам. Пишем только качественный код (как, кстати, это делать по ночам?). И вот подходит к вам удачливый соперник Вася и просит помочь. Нет, вы не откажете. Вы не такой. Вы ему поможете — как только у вас появится время. То есть никогда. Вашего менеджера можно поздравить. Его крутая система мотивации уничтожила взаимопомощь и взаимовыручку в команде. А менеджер будет трагически говорить на ежеквартальных отчетах начальству: «Пора уже вам тщательнее подходить к подбору персонала! А то набираете сплошных безответственных уродов! Невозможно работать!» Так почему это работает с токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского? Все просто. Их труд можно легко измерить и от них не требуется командная работа. А денег должно просто ХВАТАТЬ. Их уровень должен быть комфортным. Все остальная мотивация — неденежная.

БОНУСЫ БЕЗПОЛЕЗНЫ?

Бонусы бесполезны? Я этого не утверждал. Я только хотел сказать, что с бонусами надо быть очень осторожным. А все дело в том, что деньги — это ОЧЕНЬ важно. А потому бонусы — очень мощный инструмент воздействия на сотрудников. Беда в том, что он не очень-то точный. А значит в большинстве бесполезный. Это как антибиотик широкого действия. Вы скорее всего зацепите инфекцию, но и убьете все полезные бактерии. Существуют правильные и полезные системы мотивации — и бонусы к ним не относятся. Недаром зарплату, бонусы и соцпакет называют компенсационным пакетом. Компания просто компенсирует вам тот прискорбный факт, что вам приходится ходить на работу вместо того, чтобы заниматься другими интересными штуками. В том числе и работать на более щедрую компанию :-). Вы просто не сможете настроить систему бонусирования достаточно точно. Ну, к примеру, вы выстроили классную схему. По ходу дела вы учли все ошибки и она стала идеальной. Вы решили, что бонусы должны быть высокими, если программисты работают в соответствии со своим планом. Если они отстают - бьем их рублем. Ведь это так прекрасно работает с консультантами! На самом деле у консультантов все супер просто потому, что у них есть нормативы. Известно, сколько времени на самом деле занимает задача. А у нас программисты сами оценивают свою работу. Вскоре выясняется, что люди перезакладываются — дают заведомо завышенные оценки. Вы уточнили формулу. Если человек успевает раньше плана - это тоже понижает бонус. Разумеется, надо учесть, что опередить в два раза — явное разгильдяйство, а сэкономить 10% квалифицируется как трудовой подвиг. Вы не сдерживаетесь и, как человек с высшим техническим образованием, подбираете полиномиальную функцию. Она правильно аппроксимирует бонусное вознаграждение в зависимости от плановых и реальных параметров. Там есть еще и весовые коэффициенты для разных типов задач (багфиксинг!=разработка нового), учет приоритетов проекта и прочие вещи, которые вы посчитаете важными. Ваша формула идеальна. Вы, как творец, испытываете гордость создателя. Вы рассчитываете, что программисты, понукаемые жаждой наживы, будут ответственно относится к оценкам трудозатрат и стараться успевать делать работу в срок, станут учитывать приоритеты работ и правильно вести свои трудозатраты в корпоративной системе учета. На самом деле тут может быть два варианта. Если бонусы в среднем относительно небольшие (ну, скажем, меньше 20% от зарплаты), то большинство людей будут относится к их получению (или потере) как к лотерее. Повезло — не повезло. Дело в том, что вашу систему мотивации просто никто не поймет. Она слишком сложная. На самом деле вам повезло. В этом случае ваша система по крайней мере не нанесет ВРЕДА. Хуже, если бонусы действительно важны для людей. Народ займется оптимизацией выплат. Ваши местные великие комбинаторы довольно быстро придумают 400 сравнительно честных способов отъема денег у руководства. Все мысли будут крутиться вокруг денег. Обсуждения правильных стратегий учета трудозатрат будут самыми вдохновенными и креативными. Они займут львиную часть времени разработчиков. Это НЕГАТИВНО скажется на производительности программистов. Бонус — это message. Вы как бы говорите сотруднику — «чувак, ты работаешь за бабло». Люди прекрасно чувствуют такие сообщения, даже если они неявны. Излишне, я надеюсь, говорить, что бонусы ни в коем случае не должны быть отрицательными. Никаких штрафов — это демотиватор. Кстати, если чувак рассчитывает на бонус и не получает его - на практике это равносильно штрафу. Да он уже запланировал купить на бонус новый ноутбук! А тут вы со своими «на самом деле бонусы являются необязательной частью, бла-бла-бла». И заверения в стиле «мамочка тебя все равно любит» тут не исправят ситуацию.

ТАК ЧТО ЖЕ ДЕЛАТЬ С БОНУСАМИ?

По моему мнению, есть только один более или менее полезный способ использовать систему бонусирования в нашем с вами бизнесе. Кто нам мешает — тот нам поможет. Можно использовать бонус как способ транслировать ПРАВИЛЬНЫЙ message сотрудникам. Мне в голову приходит только один пример. Можно использовать бонусы для того, чтобы сообщить людям, как руководству важно достижение бизнес результатов. Например, отстегивать часть маржи сотрудникам. Сможете ли вы этим повысить их производительность? Навряд-ли. Но они точно станут немного более бизнес-ориентированными. Это просто еще один способ правильно расставить приоритеты. Будет прекрасный повод поговорить с разработчиками о том, что за продукт мы пишем и как мы собираемся захватывать рынок. По моему мнению, размер бонуса не должен превратить сам бонус в предмет культа.

http://agilerussia.ru