Форум Сообщества Аналитиков
Обсуждения => Обсуждение статей => Тема начата: uml2.ru от 21 Июля 2009, 16:42:10
-
Появилась интересная статья, которая объясняет основную концепцию Канбан Разработки (Kanban Development) на русском языке. По описанию данный подход мне даже больше нравится, чем Scrum, Xp и др. Agile: тут есть место для полноценных Аналитиков и Тестировщиков, а также место для оптимизации производства и применения TOC , и т.д. Читайте полную версию статьи Канбан в IT (Kanban Development) и комментируйте. Также можно почитать более полное описание Канбан в статье Kanban vs Scrum , но уже на англ. языке. Оригинал: Канбан в IT (Kanban Development)
-
.
-
А на Agile Russia выложена видеозапись встречи "Scrum против Kanban" (http://agilerussia.ru/index.php?option=com_content&view=article&id=151:-scrum-kanban&catid=3&Itemid=27)
-
А вот и Гриша вернулся живой из отпуска :)
Да, про твою новость я прочитал чуть позже после публикации ...
-
Попробую на следующей итерации одного из продуктов использовать "IT-канбан" для оперативного контроля внутренней команды, совмещая с "классическим" планированием.
----
В описанном в статье виде, в "IT-канбан" есть те же проблемы, что и в SCRUM: невозможно оценить продолжительность, трудозатраты, цену выдачи, непонятно, в каком состоянии находится проект, сколько (времени, денег, трудозатрат) осталось до выдачи. В таком виде "продать" выдачу инвестору сложно.
Выдавать результаты каждой отдельной задачи? Тоже не очень эффективно, тем более что результаты далеко не всех задач обладают самостоятельной ценностью. И тут возникает вторая проблема: задачи связаны между собой, они могут объединяться и дробиться, причём одни части могут пойти в один столбец доски, другие - в другой.
Тут же становится видна третья проблема: некоторые задачи удобнее выполнять в "пакетном" режиме. Например - согласование и приёмочное тестирование.
Чтобы оставаться на нужном уровне абстракции и количества задач, наверное, в "IT-канбане" имеют смысл только большие и длинные задачи, которых десятки, а не тысячи. Иначе они не поместятся на одной доске. И тут же натыкаемся на четвёртую проблему - внутреннее противоречие: цель "IT-канбана" - в том, чтобы незавершённых задач было как можно меньше, а приходится делать их длинными. И это противоречие граничит с границами применимости "IT-канбана", да и просто agile: небольшие проекты и короткие, не подразумевающие НИР задачи.
Опять же, доверие исполнителям, "всё равно при обычном менеджменте существует только иллюзия контроля". Это при плохом менеджменте. Исполнители бывают разными, и их цели - в т.ч. благие сами по себе цели повышения квалификации и самореализации - могут идти в разрез с проектом. Внутренняя мотивация? Интересных задач на всех не хватает, а получать удовольствие от хорошо сделанной рутины умеют не все. Средней демотивированности рядовой программист на зарплате? "Работа стоит, а срок идёт". Средней ответственности внешний исполнитель? "Ничего, до сдачи работы ещё целая ночь". Возможно, дробить задачи до размера 4-8 часов рабочего времени, и спрашивать о них каждый день - это микроконтроль, но это иногда необходимо. И тут же получается, что даже в небольшом проекте задач - многие сотни, и доска "IT-канбана" для них неудобна.
Кстати, в столбцах доски задач "IT-канбана" нет ячеек с именами людей, не ведётся статистика выполнения задач, не накапливаются исторические данные для будущей оценки и планирования, не видно, что нагрузка ложится на исполнителей неравномерно.
Как и scrum, "IT-канбан" не учитывает выгоды от специализации. Разные люди решают проблемы с разной эффективностью. То, что кто-то по своей воле берётся за задачу, не говорит о том, что он являются самым эффективным её исполнителем. Кстати, к вопросу о том, что повышении квалификации и самореализация могут быть вредными.
----
В общем, IMHO такой "IT-канбан", как и scrum в более-менее чистом виде, похож на очень быстрый и живой бег по сильно пересечённой местности без карты и компаса. Цель известна (но не видна), бежать приятно (пока силы есть), а результат... зависит от везения, количества сил, умения бегать и сложности местности.
-
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще? Нужно еще учесть что большие проекты без планирования далеко не уйдут и получается что руководитель проекта все равно должен быть и аналитики и тестировщики и тп. Даже деление на мелкие команды, мне кажется на спасет. Может быть эти все "новые" методологии подходят лишь для небольших команд и проектов (10-20 человек) а в больших лучше все же использовать вотерфол, пусть и итерационный?
-
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще? Нужно еще учесть что большие проекты без планирования далеко не уйдут и получается что руководитель проекта все равно должен быть и аналитики и тестировщики и тп. Даже деление на мелкие команды, мне кажется на спасет. Может быть эти все "новые" методологии подходят лишь для небольших команд и проектов (10-20 человек) а в больших лучше все же использовать вотерфол, пусть и итерационный?
Итерационный вотерфол - это уже не вотерфол. :) Вообще, чистый вотерфол это научная абстрация. Не бывает проектов с неизменными требованиями.
imho нужно разделять понятия жизненного цикла проекта и методологии (методики, практик и т. п.)
Модель жизненного цикла описывает, что происходит и в какой последовательности, а методология определяет правила или рекомендации - кому, что и как делать.
У каждой модели ЖЦ есть области применения, и существуют целые талмуды с рекомендациями по выбору правильной модели.
Скрам - методология применения итерационной модели ЖЦ.
RUP - возможно, методология применения итерационной, спиральной и ещё каких-нибудь моделей (точно не знаю, никогда по РУПу не работал).
Канбан, как я понял из статьи, вообще не охватывает какую-либо модель ЖЦ целиком. Это, скорее, приёмы повседневной работы.
-
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще?<...>
Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.
В подпроектах первый (первые) спринты - проектирование и фиксация интерфейсов между компонентами, разрабатываемыми каждой из групп (эти интерфейсы стараются не менять, а если менять - обсуждать и оповещать об этом всех), и создание "заглушек" с такими интерфейсами, последний (последние) - интеграция.
Я это видел "в живую", это работало, хотя и с проблемами. IMHO они заключались в:
- Недостаточном предварительном проектировании и планирования. SCRUM-группы начали свою работу существенно раньше, чем все договорились, что же надо сделать "в большом". В результате, ответ на вопрос "что надо делать" сильно искажало то, что что-то уже сделали, не хочется переделывать.
- Систематическом нарушении правил SCRUM.
-
Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.
В подпроектах первый (первые) спринты - проектирование и фиксация интерфейсов между компонентами, разрабатываемыми каждой из групп (эти интерфейсы стараются не менять, а если менять - обсуждать и оповещать об этом всех), и создание "заглушек" с такими интерфейсами, последний (последние) - интеграция.
Да, пришел к такому же выводу, только вы все четко расписали. Спасибо