Сообщений в теме: 29

[greesha]

На уровне частностей - я тебе лично напишу, а то тут автор переполнен сарказмом и очень ранимый в плане высокочеловеческого достоинства...

И охота двум благородным донам на шпильках фехтовать? Чисто школьники, ей-богу.

[barancev]

Представьте себе -- повсюду один только Скрам. Ну или RUP :)

Стагнация и отсутствие новых идей и течений -- это всегда реально плохо. Но я о другом. На уровне идей - мне действительно кажется, что канбан "приходит" преждевременно. Со скрамом еще не разобрались как следует... А канбан, с его более упрощенной схемой подхода к задачам, потребует от команды еще большего уровня самостоятельности в работе. Разве за прошедшее время эти уровни и нужные умения повсеместно поднялись?

Дело не в том, что схема более упрощённая. Просто скрам несколько гм... идеализировал реальный мир. Трудно организовать распределённую работу, трудно организовать выделение ролей (кросс-функциональность -- это хорошо, но...), трудно организовать работу с подрядчиками, трудно добиться быстрого исправления критичных багов (быстрее, чем итерация). Ну и так далее. Причина -- искусственно созданные в скраме ограничения. Канбан от них избавлен. Зато, наверняка, имеет другие отрицательные стороны. Упомянутое собрание как раз и имело целью понять, можно ли используя канбан избавиться от проблем скрама, и при этом не впасть в анархию. А контроль, на мой взгляд, в канбане гораздо более строгий, причём это внешний контроль.

[greesha]

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

Сама идея сведения всех бирок на одну доску, как я понимаю, ничего общего с оригинальным канбаном не имеет. А за словами "оптимизируйте постоянно процесс" в "третьем правиле" скрывается целый материк - система ценностей кайдзен (ещё одно красивое японское слово).

[astenix]

Точно! Я смотрел все материалы указанного обсуждения, и все ждал, когда прозвучит "кайдзен". Но не прозвучало. Мабуть, это связано с тем, что кайдзен прочно ассоциируется с дизайном? До сих пор я встречал этот термин только в такой связке - дизайн, юзабилити, удобство.

[rlabs]

Вообще, насколько я понял, связь этой методики с оригинальной тойтовской системой "канбан" сводится только к использованию самого этого слова.

Ну... не совсем, я так думаю. Уши-то тойотовские торчат.

Ограничение на число задач на одном участке конвеера - прямая отсылка к Lean Development: попытка избежать скопления полуфабрикатов на выходе из участка.

Таким образом, в идеале, у нас не возникает ситуации, когда разработка уходит на полгода в реализацию фич, а потом вываливает все это в тестирование. Пока идет тестирование, разработка не получает никакой обратной связи, а потом оказывается поздно переделывать "брак", и пользователи получают дополнительно напильник в коробке с продуктом.

По поводу визуализации и оптимизации процесса ничего сказать не могу - особо не вникал.

[SALar]

Точно! Я смотрел все материалы указанного обсуждения, и все ждал, когда прозвучит "кайдзен". Но не прозвучало. Мабуть, это связано с тем, что кайдзен прочно ассоциируется с дизайном? До сих пор я встречал этот термин только в такой связке - дизайн, юзабилити, удобство.

А что кайдзен? Кайдзен - это обычное советское производство годов 70-80. Японцы прямо говорят, что многое, если не все позаимствовали у нас. Хотим вернуться на 40 лет назад? Так это, вряд ли получится. Да и то, что они копировали у нас они существенным образом пребразовали.

Кроме того есть у нас с японцами существенная разница. Настолько существенная, что тот же канбан у нас работать не будет никак.
Ну как вы себе представляете, что куча материально неответственных лиц свободно и бесконтрольно ходит по складу и не выписывая и не регистрируя материал выносит его за пределы склада. Представили картинку? Сколько секунд после этого будут жить запасы на складе?

[SALar]

Таким образом, в идеале, у нас не возникает ситуации, когда разработка уходит на полгода в реализацию фич, а потом вываливает все это в тестирование. Пока идет тестирование, разработка не получает никакой обратной связи, а потом оказывается поздно переделывать "брак", и пользователи получают дополнительно напильник в коробке с продуктом.

Это не самое важное в канбане. Уменьшение складских запасов важнее.

На автомобильном заводе фирмы “Ниссан”, выпускающем 420 тысяч машин в год, комплектующих частей имеется на два часа работы конвейера. Смежники привозят эти части с точностью плюс - минус два часа, и на заводе не помнят, чтобы конвейер останавливался. Благодаря отсутствию складских помещений и рабочих, занятых в них, японские автомобилестроители экономят на издержках производства в расчете на одну машину в среднем 94 доллара.

В софте это иногда работает, иногда нет. Проблема в том, что среднестатистический ПМ никак не может отличить одну ситуацию от другой.

Коллеги, а похоже накопилось вопросов еще на семинар.

[rlabs]

Это не самое важное в канбане. Уменьшение складских запасов важнее.

Вот я вроде бы как раз и описывал влияние ограничения числа активных задач на затоваривание склада. Неправильно?

В софте это иногда работает, иногда нет. Проблема в том, что среднестатистический ПМ никак не может отличить одну ситуацию от другой.

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

[SALar]

Это не самое важное в канбане. Уменьшение складских запасов важнее.

Вот я вроде бы как раз и описывал влияние ограничения числа активных задач на затоваривание склада. Неправильно?

Правильно, если мы рассматриваем в качестве связаного капитала любую задачу, которую еще не плставили конечному потребителю. Я говорил немного о другом. о том, что передача большого куска в тестирование не так критично, как больший обьем не поставленный потребителю, но над которым уже началась работа.

В софте это иногда работает, иногда нет. Проблема в том, что среднестатистический ПМ никак не может отличить одну ситуацию от другой.

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

Запас на складе греет сердце почти любого россейского менеджера. Для производства же это связанный капитал и, как следствие, удорожание производства. Проблемы же простоев решаются частично буферами. Но! Чаще всего простои - это нормально. И так и должно быть.

Давайте как нибудь на эту тему соберемся? Я материал для семинара подготовлю.

[greesha]

7 июля в прошло очередное собрание сообщества AgileRussia, посвященного занимательнейшей теме – сравнению методологий разработки Scrum и Kanban. И если Scrum уже начал терять ореол свежести и модности, уже накопились претензии не от тех, кто «Пастернака не читал, но осуждает», а от реально практикующих Scrum в течение пары лет, то Kanban – штука в софтверной индустрии новая, и при этом не выдуманная заумь от софтверных методологов (или даже целых Институтов Программирования), а реальная практика, пришедшая из японского автомобилестроения – индустрии, уважаемой большинством программистов, даже не ездящих на «японках».
...
Этим и объясняется успех Scrum-а для измученных нарзаном RUP-ом или MS Project-ом. Но с другой стороны, у многих, особенно у пришедших к Scrum-у от «методологии Бей и беги Code-and-Fix», возникает много претензий к Scrum-практикам – можно ли еще упростить? Можно ли выкинуть еще один (детский? туземный?) ритуал? …

Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP.

Ещё размышления вдогонку.

imho внешняя простота kanban может оказать медвежью услугу. Kanban "проще" скрама, но его правила более расплывчаты и, глядя со стороны, просто не увидишь, что за ними стоит.

Прийти к kanban после Скрама можно, но никак не наоборот. Да и то, пожалуй, только после хорошего, качественного скрама, когда каждый разработчик уже проникся духом Agile, не мыслит работу без ежедневного общения и привык использовать карточки для фиксации ежедневных задач. А самое главное: он психологически готов брать на себя долю ответственности за общее дело.

Тогда менеджер может снять доспехи скрам-мастера, и немного расслабиться: всё работает как часы, каждый на своём месте знает, что и как ему нужно делать. И вот на этом этапе можно начать замену чётких инструкций Скрама на более расплывчатые принципы Канбана. А расслабляться придётся недолго. Главное, на чём теперь можно и нужно сосредоточиться - это та самая вторая половинка третьего правила: "оптимизируйте постоянно процесс".

Ну и за "как часами" всё равно придётся следить. Любой механизм со временем засоряется и изнашивается.