Один из проектов, который я сейчас веду - это небольшой (вернее маленький) проект по разработке ПО для одной крупной российской компании. Проект короткий – всего пара месяцев. Делаем не с нуля, а переделываем то, что уже было сделано нашей компанией для зарубежных компаний. Т.е. кастомизируем уже существующий софт под нужды заказчика, параллельно занимаемся локализацией. Не суть. Смысл в том, что есть чёткое понимание того, что должно быть в итоге, но чёткого ТЗ, в котором собраны все требования, как такового нет – оно формируется в процессе разработки. Такой вот своеобразный fast tracking =)
Так вот, на проекте работают два разработчика, архитектор, тестировщик и я, менеджер проекта и локализатор в одном лице =)
Решил попробовать на этом проекте методику SCRUM-митингов. Т.е. ежедневных собраний, продолжительностью не более 15 минут, на которых каждый участник команды отвечает на три вопроса: что было сделано вчера, что будет сделано сегодня и какие имеются проблемы. Я не ожидал, что эти собрания окажутся настолько эффективными. Раньше, в других проектах, когда одних разработчиков было 5-7 человек, плюс тестировщики, аналитики, архитектор и дизайнер – такие собрания были невозможны, т.к. на это уходило бы масса времени. А при маленькой команде – это то, что надо. Все проблемы вскрываются сразу же, нет такого, что разработчик сидит, пыхтит над проблемой, которая возникла у него во вторник и о которой все узнают только в пятницу на еженедельном статус митинге. К тому же о всех флуктуациях требований к реализуемой функциональности все участники проекта узнают как только они появляются.
Единственное отступление от заповедей SCRUM’а, которое я сделал – это позволил обсуждать проблемы на наших ежедневных митингах. В SCRUM-митингах проблемы только озвучиваются, а разбираются уже за рамками встречи, что бы не отнимать времени у всех участников. В случае маленького проекта и кол-ва участников меньше 5 человек можно себе позволить небольшие обсуждения.
Очень рекомендую прослушать подкаст (podcast) Рона Хологана, PMP (Ron Holohan, PMP) с сайта http://pm411.org/ под названием “Managing effective meetings (part 2 of 2)”, в котором он подробно рассказывает о такого рода собраниях. Очень рекомендую!
Так вот, на проекте работают два разработчика, архитектор, тестировщик и я, менеджер проекта и локализатор в одном лице =)
Решил попробовать на этом проекте методику SCRUM-митингов. Т.е. ежедневных собраний, продолжительностью не более 15 минут, на которых каждый участник команды отвечает на три вопроса: что было сделано вчера, что будет сделано сегодня и какие имеются проблемы. Я не ожидал, что эти собрания окажутся настолько эффективными. Раньше, в других проектах, когда одних разработчиков было 5-7 человек, плюс тестировщики, аналитики, архитектор и дизайнер – такие собрания были невозможны, т.к. на это уходило бы масса времени. А при маленькой команде – это то, что надо. Все проблемы вскрываются сразу же, нет такого, что разработчик сидит, пыхтит над проблемой, которая возникла у него во вторник и о которой все узнают только в пятницу на еженедельном статус митинге. К тому же о всех флуктуациях требований к реализуемой функциональности все участники проекта узнают как только они появляются.
Единственное отступление от заповедей SCRUM’а, которое я сделал – это позволил обсуждать проблемы на наших ежедневных митингах. В SCRUM-митингах проблемы только озвучиваются, а разбираются уже за рамками встречи, что бы не отнимать времени у всех участников. В случае маленького проекта и кол-ва участников меньше 5 человек можно себе позволить небольшие обсуждения.
Очень рекомендую прослушать подкаст (podcast) Рона Хологана, PMP (Ron Holohan, PMP) с сайта http://pm411.org/ под названием “Managing effective meetings (part 2 of 2)”, в котором он подробно рассказывает о такого рода собраниях. Очень рекомендую!
Комментариев нет:
Отправить комментарий