Comments 38
Расскажите поподробнее, чем именно занимается команда?
Команда разрабатывает слоистый вэб-трэйд-сервис
Мои 5 копеек. Достаточно интересный проект trello.com/
Меня заинтересовало — как вы измеряли ускорение?
Можете подробнее об этом?
Можете подробнее об этом?
От scrum у нас осталась практика оценки бэклога — каждая фича оценивается в относительных сторипоинтах (у нас это идеальные дни). PO устанавливает дату очередного релиза. Строим burndown график: по оси X откладываем время, а по оси Y поинты. Получаем идеальную скорость разработки, которая позволит зарелизится вовремя. Покончив с какой-либо фичей, мы отмечаем на графике сколько поинтов осталось к текущей дате и видим отклонение от идеального плана. Обычно системы управления проектами позволяют автоматически строить такие графики. Мы используем Pivotal — и он справляется с этой задачей великолепно )
> PO устанавливает дату очередного релиза. Строим burndown график: по оси X откладываем время, а по оси Y поинты.
Таким образом разработка идёт только тех фич, что пойдут в следующий релиз и, со Scrum'а, фича обязана помещаться в, теперь уже, виртуальный спринт, который длится до даты релиза. Я всё верно понял?
Таким образом разработка идёт только тех фич, что пойдут в следующий релиз и, со Scrum'а, фича обязана помещаться в, теперь уже, виртуальный спринт, который длится до даты релиза. Я всё верно понял?
В каком-то приближении — да. Только спринт этот длится примерно пол года, а за это время набор фич корректируются.
Т.е. релизы в прокашн у вас раз в пол года? Вам несказанно повезло с терпеливым PO, который может дожидаться всех новых фич в продакшн так долго :)
На самом деле, релизы можно делать сразу после завершения фичи, так как у нас нет спринтовых рамок и фича в беклоге несет законченную бизнес ценность.
Тогда не совсем понял про длинну спринта в пол года. Что в вашем процессе означает спринт?
Я так понимаю, что дедлайн для релиза PO устанавливает до начала работы над фичами? И поэтому вам приходиться ограничивать количество фич в релизе (как, собственно, и всем), чтобы не возникало «перегруженных» этапов рабочего процесса (напр., чтобы тестирование не ставало узким местом или теряло в качестве).
Я так понимаю, что дедлайн для релиза PO устанавливает до начала работы над фичами? И поэтому вам приходиться ограничивать количество фич в релизе (как, собственно, и всем), чтобы не возникало «перегруженных» этапов рабочего процесса (напр., чтобы тестирование не ставало узким местом или теряло в качестве).
Понятие спринт было введено товарищем исключительно для объяснения процесса замера скорости исполнения. Мы не используем этого понятия в работе. PO выставляет срок, к которому он хотел бы иметь определенный набор функционала. Мы оцениваем фичи и выдвигаем вердикт — да, нет. Если «нет», то происходит корректировка желаний PO =)
Отличная идея с ограничениями.
Мне очень радостно видеть, что у кого-то получилось построить рабочий процесс в том виде, в котором видел его я на своей предыдущей работе!
У меня есть парочка вопросов, ответы на которые могли бы немного прояснить общую картину:
1. Каков количественный и качественный состав разроботчиков? Имеется в виду, действительно ли у вас любой свободный разроботчик берет первую по приоритету задачу из колонок Pull, Анализ, Проектирование? На практике (по-крайней мере, из моего опыта) люди со временем приобретают некие области компетенции, где они заслуженно считаются более опытными. Иногда в силу экслюзивности этой компетенции они становятся «заложниками» этих областей. :)
2. Есть ли у вас фиксированные роли в комманде? Например, ответсвенный за release deployment. Или этим может заниматься любой свободный разработчик?
3. Каково количественное соотношение разработчиков и тестировщиков?
4. Ваши проекты имеют веб-ориентацию или характер разработки ближе к ПО?
Буду благодарен за ответы.
У меня есть парочка вопросов, ответы на которые могли бы немного прояснить общую картину:
1. Каков количественный и качественный состав разроботчиков? Имеется в виду, действительно ли у вас любой свободный разроботчик берет первую по приоритету задачу из колонок Pull, Анализ, Проектирование? На практике (по-крайней мере, из моего опыта) люди со временем приобретают некие области компетенции, где они заслуженно считаются более опытными. Иногда в силу экслюзивности этой компетенции они становятся «заложниками» этих областей. :)
2. Есть ли у вас фиксированные роли в комманде? Например, ответсвенный за release deployment. Или этим может заниматься любой свободный разработчик?
3. Каково количественное соотношение разработчиков и тестировщиков?
4. Ваши проекты имеют веб-ориентацию или характер разработки ближе к ПО?
Буду благодарен за ответы.
1. 2. Естественно, есть области в которых некоторые сильнее. Но мы стараемся максимально наладить обмен знаниями: каждый с радостью берет задачу, в которой он недостаточно сведущий, проводятся постоянные презентации архитектур, инструментов и т.п. Таким образом у нас размываются рамки ролей.
3. 3:1
4. Пока исключительно web
3. 3:1
4. Пока исключительно web
Добавление в раздел Полезности: SCRUM И KANBAN: ВЫЖИМАЕМ МАКСИМУМ
А какие вы ограничения поставили? Например, в пуле не больше 5 фич на человека, ждут ревью не больше 2 фич на разработчикуа, ждут тестирования не больше 2 фич на тестера и т.п.
И куда попадают найденные ошибки? В отдельный пул? Есть ли по ним ограничения?
И куда попадают найденные ошибки? В отдельный пул? Есть ли по ним ограничения?
Для компании 3 девелопера + 1 тестировщик:
Pull: 3; Анализ: 1; Проектирование+Разработка+Review: 2; Тестирование: 1
Ошибки у нас правятся на лету, я описал это дело в подразделе «возвраты». Мы стараемся на период тестирования сильно не нагружать одного из девелоперов (обычно ответсвенного по фиче), чтобы тот был всегда готов быстро исправить найденные дефекты.
Вообще, некоторые выделяют на доске «красную дорожку», в которую попадают самые горячие внеплановые фичи. У нас такой необходимости нет.
Pull: 3; Анализ: 1; Проектирование+Разработка+Review: 2; Тестирование: 1
Ошибки у нас правятся на лету, я описал это дело в подразделе «возвраты». Мы стараемся на период тестирования сильно не нагружать одного из девелоперов (обычно ответсвенного по фиче), чтобы тот был всегда готов быстро исправить найденные дефекты.
Вообще, некоторые выделяют на доске «красную дорожку», в которую попадают самые горячие внеплановые фичи. У нас такой необходимости нет.
Спасибо за ответ!
У нас очень похожий процесс в TargetProcess.com.
Правда, UX фаза еще есть совершенно отдельная со своей командой.
А так и kick-start митинги общие для каждой юзер стори, и презентация архитектурных решений, и TDD/BDD, ну и так далее.
Вот более подробно www.targetprocess.com/blog/2011/04/our-development-process-1-5-years-later.html
Правда, UX фаза еще есть совершенно отдельная со своей командой.
А так и kick-start митинги общие для каждой юзер стори, и презентация архитектурных решений, и TDD/BDD, ну и так далее.
Вот более подробно www.targetprocess.com/blog/2011/04/our-development-process-1-5-years-later.html
Посоветуйте, пожалуйста, какие книги вы считаете лучшими по тематике скрама, канбана и прочих методологий гибкого управления проектами, а то везде практически одни статьи, а полного введения в эту тему нет я не нашел.
Спасибо.
Спасибо.
Классная статья!
Использую классический Redmine + Backlogs plugin (www.redminebacklogs.net)
Ушел от Scrum в сторону больше Kanban из-за того, что команда пока распределенная и не всегда всех удается собрать именно в нужный день и нужное время для планирования.
Соответственно внедрили TeamCity и автоматические деплои на beta и на production.
Шагов делаем немножко меньше, без диаграмм. Просто планируем и обсуждаем user story и выписываем задачи к ней, которые оцениваем в идеальных часах. (это осталось у нас от Scrum).
Но у меня и команда сильно меньше и релизы гораздо чаще :)
Стараюсь раз в 2-3 недели делать релиз. Хотя Web можем выкатывать в любое время. А вот с мобильными устройствами такое не прокатит.
Спасибо за статью, довольно интересно. До этого момента мало встречал информации по канбану в IT.
Использую классический Redmine + Backlogs plugin (www.redminebacklogs.net)
Ушел от Scrum в сторону больше Kanban из-за того, что команда пока распределенная и не всегда всех удается собрать именно в нужный день и нужное время для планирования.
Соответственно внедрили TeamCity и автоматические деплои на beta и на production.
Шагов делаем немножко меньше, без диаграмм. Просто планируем и обсуждаем user story и выписываем задачи к ней, которые оцениваем в идеальных часах. (это осталось у нас от Scrum).
Но у меня и команда сильно меньше и релизы гораздо чаще :)
Стараюсь раз в 2-3 недели делать релиз. Хотя Web можем выкатывать в любое время. А вот с мобильными устройствами такое не прокатит.
Спасибо за статью, довольно интересно. До этого момента мало встречал информации по канбану в IT.
Разумный подход, хороший результат.
Единственная неприятная мелочь. К канбану это не имеет отношения. Вы описали производственный поток I-типа и использовали простую модель управления. Канбан здесь не нужен и вы его не применяли. Канбан нужен для управления потоками V-типа (или T-типа).
Если будете искать дополнительные материалы, ищите статьи Коуэна или ищите по аббревиатуре «VATI».
А так все классно.
> burndown графики указывали ускорение в 2.1 раза
Хороший результат. Мои поздравления.
Единственная неприятная мелочь. К канбану это не имеет отношения. Вы описали производственный поток I-типа и использовали простую модель управления. Канбан здесь не нужен и вы его не применяли. Канбан нужен для управления потоками V-типа (или T-типа).
Если будете искать дополнительные материалы, ищите статьи Коуэна или ищите по аббревиатуре «VATI».
А так все классно.
> burndown графики указывали ускорение в 2.1 раза
Хороший результат. Мои поздравления.
«Благодаря фазе анализа функционал точно соответствовал пожеланиям заказчика и мы не тратили время на переделывание.» прям сказка какая-то
Sign up to leave a comment.
Успешный Kanban в небольшой команде