Форум Сообщества Аналитиков

×


Канбан в IT (Kanban Development)(Прочитано 12063 раз)
Канбан в IT (Kanban Development) : 21 Июля 2009, 16:42:10
Появилась интересная статья, которая объясняет основную концепцию Канбан Разработки (Kanban Development) на русском языке. По описанию данный подход мне даже больше нравится, чем Scrum, Xp и др. Agile: тут есть место для полноценных Аналитиков и Тестировщиков, а также место для оптимизации производства и применения TOC , и т.д. Читайте полную версию статьи Канбан в IT (Kanban Development) и комментируйте. Также можно почитать более полное описание Канбан в статье Kanban vs Scrum , но уже на англ. языке.   Оригинал: Канбан в IT (Kanban Development)



Re: Канбан в IT (Kanban Development) Ответ #1 : 21 Июля 2009, 16:42:15
.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Канбан в IT (Kanban Development) Ответ #2 : 21 Июля 2009, 17:10:57
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Канбан в IT (Kanban Development) Ответ #3 : 21 Июля 2009, 17:27:26
А вот и Гриша вернулся живой из отпуска :)
Да, про твою новость я прочитал чуть позже после публикации ...
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Канбан в IT (Kanban Development) Ответ #4 : 22 Июля 2009, 00:58:53
Попробую на следующей итерации одного из продуктов использовать "IT-канбан" для оперативного контроля внутренней команды, совмещая с "классическим" планированием.

----

В описанном в статье виде, в "IT-канбан" есть те же проблемы, что и в SCRUM: невозможно оценить продолжительность, трудозатраты, цену выдачи, непонятно, в каком состоянии находится проект, сколько (времени, денег, трудозатрат) осталось до выдачи. В таком виде "продать" выдачу инвестору сложно.

Выдавать результаты каждой отдельной задачи? Тоже не очень эффективно, тем более что результаты далеко не всех задач обладают самостоятельной ценностью. И тут возникает вторая проблема: задачи связаны между собой, они могут объединяться и дробиться, причём одни части могут пойти в один столбец доски, другие - в другой.

Тут же становится видна третья проблема: некоторые задачи удобнее выполнять в "пакетном" режиме. Например - согласование и приёмочное тестирование.

Чтобы оставаться на нужном уровне абстракции и количества задач, наверное, в "IT-канбане" имеют смысл только большие и длинные задачи, которых десятки, а не тысячи. Иначе они не поместятся на одной доске. И тут же натыкаемся на четвёртую проблему - внутреннее противоречие: цель "IT-канбана" - в том, чтобы незавершённых задач было как можно меньше, а приходится делать их длинными. И это противоречие граничит с границами применимости "IT-канбана", да и просто agile: небольшие проекты и короткие, не подразумевающие НИР задачи.

Опять же, доверие исполнителям, "всё равно при обычном менеджменте существует только иллюзия контроля". Это при плохом менеджменте. Исполнители бывают разными, и их цели - в т.ч. благие сами по себе цели повышения квалификации и самореализации - могут идти в разрез с проектом. Внутренняя мотивация? Интересных задач на всех не хватает, а получать удовольствие от хорошо сделанной рутины умеют не все. Средней демотивированности рядовой программист на зарплате? "Работа стоит, а срок идёт". Средней ответственности внешний исполнитель? "Ничего, до сдачи работы ещё целая ночь". Возможно, дробить задачи до размера 4-8 часов рабочего времени, и спрашивать о них каждый день - это микроконтроль, но это иногда необходимо. И тут же получается, что даже в небольшом проекте задач - многие сотни, и доска "IT-канбана" для них неудобна.

Кстати, в столбцах доски задач "IT-канбана" нет ячеек с именами людей, не ведётся статистика выполнения задач, не накапливаются исторические данные для будущей оценки и планирования, не видно, что нагрузка ложится на исполнителей неравномерно.

Как и scrum, "IT-канбан" не учитывает выгоды от специализации. Разные люди решают проблемы с разной эффективностью. То, что кто-то по своей воле берётся за задачу, не говорит о том, что он являются самым эффективным её исполнителем. Кстати, к вопросу о том, что повышении квалификации и самореализация могут быть вредными.

----

В общем, IMHO такой "IT-канбан", как и scrum в более-менее чистом виде, похож на очень быстрый и живой бег по сильно пересечённой местности без карты и компаса. Цель известна (но не видна), бежать приятно (пока силы есть), а результат... зависит от везения, количества сил, умения бегать и сложности местности.
« Последнее редактирование: 22 Июля 2009, 01:01:27 от AlexTheRaven »



Re: Канбан в IT (Kanban Development) Ответ #5 : 24 Июля 2009, 18:04:23
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще? Нужно еще учесть что большие проекты без планирования далеко не уйдут и получается что руководитель проекта все равно должен быть и аналитики и тестировщики и тп. Даже деление на мелкие команды, мне кажется на спасет. Может быть эти все "новые" методологии подходят лишь для небольших команд и проектов (10-20 человек) а в больших лучше все же использовать вотерфол, пусть и итерационный?
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



Re: Канбан в IT (Kanban Development) Ответ #6 : 24 Июля 2009, 18:19:57
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще? Нужно еще учесть что большие проекты без планирования далеко не уйдут и получается что руководитель проекта все равно должен быть и аналитики и тестировщики и тп. Даже деление на мелкие команды, мне кажется на спасет. Может быть эти все "новые" методологии подходят лишь для небольших команд и проектов (10-20 человек) а в больших лучше все же использовать вотерфол, пусть и итерационный?

Итерационный вотерфол - это уже не вотерфол. :) Вообще, чистый вотерфол это научная абстрация. Не бывает проектов с неизменными требованиями.

imho нужно разделять понятия жизненного цикла проекта и методологии (методики, практик и т.  п.)

Модель жизненного цикла описывает, что происходит и в какой последовательности, а методология определяет правила или рекомендации - кому, что и как делать.

У каждой модели ЖЦ есть области применения, и существуют целые талмуды с рекомендациями по выбору правильной модели.

Скрам - методология применения итерационной модели ЖЦ.
 
RUP - возможно, методология применения итерационной, спиральной и ещё каких-нибудь моделей (точно не знаю, никогда по РУПу не работал).

Канбан, как я понял из статьи, вообще не охватывает какую-либо модель ЖЦ целиком. Это, скорее, приёмы повседневной работы.
greesha.ru

Реальность - это убийство прекрасной теории бандой мерзких фактов. (Роберт Гласс)



Re: Канбан в IT (Kanban Development) Ответ #7 : 29 Июля 2009, 11:59:12
Коллеги, а как применять Kanban и Scrum в больших проектах с фиксированной стоимостью и реально ли это вообще?<...>

Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.

В подпроектах первый (первые) спринты - проектирование и фиксация интерфейсов между компонентами, разрабатываемыми каждой из групп (эти интерфейсы стараются не менять, а если менять - обсуждать и оповещать об этом всех), и создание "заглушек" с такими интерфейсами, последний (последние) - интеграция.

Я это видел "в живую", это работало, хотя и с проблемами. IMHO они заключались в:
  • Недостаточном предварительном проектировании и планирования. SCRUM-группы начали свою работу существенно раньше, чем все договорились, что же надо сделать "в большом". В результате, ответ на вопрос "что надо делать" сильно искажало то, что что-то уже сделали, не хочется переделывать.
  • Систематическом нарушении правил SCRUM.



Re: Канбан в IT (Kanban Development) Ответ #8 : 29 Июля 2009, 12:13:22
Да, вполне реально, но сложно. Сначала производится сбор требований, проектирование архитектуры, оценка трудоёмкости и планирование "в общем". Затем проект разделяется на подпроекты. На подпроекты выделяются SCRUM-команды, максимум по 5-6 чел, и уже ПМ, аналитик и архитектор являются для них product owner'ами.

В подпроектах первый (первые) спринты - проектирование и фиксация интерфейсов между компонентами, разрабатываемыми каждой из групп (эти интерфейсы стараются не менять, а если менять - обсуждать и оповещать об этом всех), и создание "заглушек" с такими интерфейсами, последний (последние) - интеграция.
Да, пришел к такому же выводу, только вы все четко расписали. Спасибо
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19