Комментарии 8
pull подход хорош, когда задачи не очень срочные или срок заранее регламентирован и нет такого, что "вчера надо было".
Хороший мануал. Сам пользовался активно Yougile примерно 3 года вместе с небольшой командой. И как раз настраивал все задачи по методике Kanban. Поэтому всегда видели общую картину- горящие, зависшие задачи. Задачи, которые стали внедрять, но потом забыли про них и др.
Канбан метод придуман не в Тойота, а в Майкрософт, в 2007 г. Дэвидом Андерсоном
По практике прихожу к мысли, что управлять процессами должны люди, прошедшие определенное обучение и получившие какой-то документ. И без этого даже близко не подпускать к доскам. У нас один нетоварищ убедил начальство перейти на всё это, сам этим занялся и потихоньку скатился во что-то похожее на ватерфлоу - доску используем только для отчетов взял-поработал-закрыл. А то, что у него к концу года графики в отчетах не очень красивые, это разработчики виноваты.
Из моего опыта упущен важный момент: вы рассматриваете команду как некий юнит, который решает задачи. В практике, где вся команда - универсалы и могут делать любые задачи (писать код, тестировать, писать доку) это работает.
Как только вы выделяете в команде роли ( системный аналитик, FE,BE разработчики, QA) то процесс ломается. Потому что для команды статус "в работе", а внутри это передача от этапа к этапу. И отслеживать это становится невозмодно и все виплимиты идут лесом...
Если есть опыт канбана в командах с несколькими ролями - опишите пожалуйста.
Что такое канбан и как на самом деле по нему работать