Комментарии 46
За много лет так и не понял, чем одно от другого отличается. И признаться желания никакого. Вместо работы предлагаются какие-то танцы в присяду.
А это, видимо, потому что никто эти процессы не любит соблюдать. Вот и получается либо недоскрам, либо полуканбан, либо вообще канбарам.
А так, судя по статье, скрам - это когда есть спринты с атомарными фичами и релизами, а канбан - это когда нет спринтов и релизов, а есть постоянные допиливания-улучшения по мере готовности. Когда делаем продукт на заказ к определенному сроку - лучше спринт. Если в непрерывном режиме поддерживаем и улучшаем свой продукт без обязательств по срокам конкретных фичей - больше подходит канбан.
Может нафиг тогда эти свистопляски и модные методологии, если они только мешают работать?
А кто сказал, что они мешают? Если их применять к месту и строго следовать, то они только помогают.
Если их применять к месту и строго следовать
это как с коммунизмом. Всегда все мотивируют след. вариант построяния коммунизма тем, что прошлые попытки построения коммунизма как-бы были не совсем правильные, и надо собраться и в след. раз сделать обязательно лучше. Отвлекая от того, что сама система — коммунизма — это утопия. Но ведь это никто никгда не скажет. Так же и с агилем. Если это не работает, а в большинстве своём это не работает нигде. И происходят полу-меры, то причину видят не в системе, а в её реализации.
Как-то был в гостях в одной фирме, где плоская хирархия. Никаких там начальников, никакив подчинённых, каждый в состоянии сам выбирать род деятельности, проект на которым хочется работать итд. Вроде бы — смотри — работает. А потом смотришь на средний возраст сотрудников. И выясняешь для себя, что там нет (почти) никого старше 35. Поговорив, обьясняют, что люди когда-то типа взраслеют. И это и понятно. Ведь альтруизм когда-то заканчивается, когда обзаводишся семьей, детьми и надо думать о будущем, о том, как использовать свой человеческий и проффесиональный капитал. А в агиле рамки использования этого капитала ограничены. Ведь карьера — это не агиль. Развиваться проффессионально — это инвестиция в будущее. А агиль эту инвистицию обнуляет постоянно.
Т.е. агиль — это своего рода допольнительный вариант решения задач. Своего рода как аврал в проекте. Никто его не будет видеть как «правильный» подход в проекте. Но когда надо, то такой критичный подход, где каждый участник проекта готов и отпуском пожертвовать и выходными — иногда и работающая конструкция. Но не всегда-же.
А это, видимо, потому что никто эти процессы не любит соблюдать. Вот и получается либо недоскрам, либо полуканбан, либо вообще канбарам.
Понятия "полуканбан" быть не может. Частичный канбан - это уже канбан (в отличие от скрама, где частичный скрам не является скрамом совсем). Это обусловлено оной из ценностей канбана - эволюционные изменения.
А так, судя по статье, скрам - это когда есть спринты с атомарными фичами и релизами, а канбан - это когда нет спринтов и релизов, а есть постоянные допиливания-улучшения по мере готовности.
Из статьи действительно может сложиться это ложное впечатление. В реальности же, сравнивать канбан и скрам нет смысла, потому что это то же самое, что сравнивать понедельник с Хондой. Скрам - это процессный фреймворк, заданный набор жестких правил. Канбан - это метод эволюционного изменения процессов с набором рекомендаций. Релизы в канбане очень даже могут быть, у канбана даже одна из каденций - Встреча по планированию поставки. Спринты - вопрос терминологии: если по канбану у нас встречи по наполнению очереди раз в две недели, и очередь наполняется на две недели вперед, то как раз получаются те же двухнедельные спринты.
Вообще в статье есть довольно спорные заявления, например
Канбан не заботится о времени
Либо я не так понял посыл, либо это неверное заявление. В канбане есть даже два классических класса обслуживания, намекающих на большой заболе о времени: ускоренный и с фиксированной датой поставки
В Канбане нет конкретных размеров команд или должностей
частично верное заявление. Должностей действительно нет, но есть роли, о чем можно было бы и упомянуть.
В общем, к статье довольно много вопросов.
А не поделитесь ссылкой, где бы прочитать поподробнее? А то в Википедии про канбан полтора предложения.
Можно начать с https://resources.kanban.university/kanban-guide/
Алексей Пименов хорошо рассказывает про канбан, можно поискать его материалы.
Несколько хороших статей можно найти на https://scrumtrek.ru/blog/kanban/, можно начать с https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/, чтобы получить первое представление.
В Яндекс.Музыке есть годный подкаст Kanban Talks.
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов
я должен рассказать какие у меня технические проблемы, остальные, совершенно не понимая моих проблем, комментируют.
У меня на этих комментаторов аллергия. Они во всём «разбираются». Говорят правильные слова, ничего не значущие, но позволяющие этим комментаторам считаться экспертами. И дополнение к этому, ону хотят типа вникнуть во все детали и все им раскрывают карты, пытаются показать. Но этим экспертам нужны не детали, а именно время, которое тратиться на все эти дополнительные телодвижения, которые к успеху продукта никакого отношения не имеют.
Видимо начиная с какого то большого размера абсолютно не важна - капиталистическая организация, или социалистическая, всё что реально волнует топ менеджмент, это чтобы юридически на бумагах всё было чисто. А все остальные бизнес-процессы существуют лишь для обяспечения возможности этой юридической чистоты.
В этом плане пункт манифеста аджайла Работающий продукт важнее исчерпывающей документации совершенно неверен. Документация это документ - с ним можно и в суд придти, и иск против организации выиграть с далеко идущими последствиями. А продукт это что? Кому вообще интересен продукт?
Agile может быть не токсичным и полезным если сделать всё правильно, наполнить общие безликие рекомендации конкретным смыслом, правильно подготовить и менеджеров и разработчиков. Я видел примеры здоровых скрам процессов, которые не скатились тупо в исполнение ритуалов.
Чтобы не быть голословным: правильный ежедневный стендап проводился у нас не только для того, чтобы протрекать прогресс по задачам, но и помочь снять все блоки. В нашей команде из 11 человек встреча занимала 7-10 минут: мы трекали прогресс, накидывали список текущих проблем, просили помощи если не хватало экспертизы и ничего не решали прямо на встрече — договаривались о коротких созвонах после стендапа. Обычно в течение часа-двух все блоки по задачам снимались, разработчики могли заниматься своими делами, а менеджеры не бегали к ним каждый час с традиционным «Ну как там?».
делать все правильно и "со смыслом", это - не про аджайл. В смысле, эджайл тут не причем. Это - единственный пункт универсального манифеста всех методик.
Самое забавное здесь именно то, что scrum как и коммунизм должен всех уравнять. Цель этих приседаний (планирований, работы над беклогом, стендапов) упорядочить поток задач, помочь быстрее решать проблемы тем у кого хуже развиты навыки общения и при этом остаться достаточно гибкими в планах.
Ты новичок, ты не знаешь пока что людей и участки за которые они отвечают. У вас не офис, а удаленка. Куда идти? Кого спрашивать? Звонить по каждой проблеме руководителю или тимлиду, чтобы свели с нужным человеком или ткнули в документацию? А не лучше собрать скопившиеся за день вопросы и проблемы и разом их проговорить/решить? А может к концу дня и сам разберешься. А Петя и Маша весь день сидят и ждут гостей? Они может уже работают в потоке, а тут приходит новенький и выдергивает их оттуда.
Всё очень знакомо, правда, к счастью, не настолько было плохо :)
А так да, церемонии заседаний где каждый говорит о прогрессе и проблемах, но в итоге никто ничего с этим не делает.
Когда начинаешь тыкать всех в грязь лицом потому, что начальник не понимает почему нет продвижения, то оказываешься ещё и крайним, т.к. "заставляешь" других работать на себя.
Итого все говорят, что всё хорошо, но прогресса нет совсем и все довольны этой игрой.
Правильным ответом, как оказалось, было взять на себя обязанности других и просто выполнить их работу, хотя при этом никто твою делать не собирался.
В общем, цирк остался, а я ушёл.
У меня немного другой опыт с канбаном.
Есть flow, по которому движется задача.
Требование только одно довести задачу (таск) до конца (самый левый столбик)
Нет ограничения по времени, темп работы выбираешь сам.
Т.к. работаем удаленно, то на дейли можно договориться о помощи, если требуется.
Работать комфортно.
Так что как обычно проблема не в методологии а в людях.
Это как в анекдоте. "Команда работала по agile, пока не стали внедрять agile." :-)
У вас интересный опыт, но странные выводы: негативное отношение к Аджайлу, когда в вашей фирме его толком и не было.
Если мошенник продаст вам фейковый Айфон, ругаться из-за низкого качества вы будете на Эппл?
Сколько лет уже этому манифесту
http://macode.ru/
Скрам и канбан роднит общий управленческий подход, где любые сколь угодно сложные работы, выполнение которых требует специальных знаний и навыков, абстрагируются до карточек - задач. Это даёт возможность передать контроль над процессом от того, кто лучше делает тому, кто лучше говорит.
В остальном же это лишь разные методы управления очередями задач и мотивацией команды, где вопросы теории очередей и управленческой психологии метафорически изложены в виде готовых рецептов, что позволяет быстро вводить в строй новых менеджеров.
Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.
Очень люблю этот пример. Почему-то всегда получается так что разработчик кому-то начинает помогать. А бывает ли наоборот? QA начинает писать код, сапоги тачать пирожник бизнес-аналитик настраивать сервера?
QA начинает писать код, сапоги тачать пирожник бизнес-аналитик настраивать сервера?
С точки зрения скрама — так и должно быть, в нём нет разделение на роли в команде разработки. На мой взгляд — один из самых существенных недостатков скрама.
Дальше-больше :)
Некоторые считают, что эффективная команда должна помощь другим менее эффективным.
Но разбираться почему другая команда менее эффективна никто не собирается.
Выходит, что выгоднее завысить сроки и просто плевать в потолок, чтобы успеть к интеграции также «быстро» как и другие.
Product owner и клиент устанавливают все правила
С каких это пор в скраме все правила устанавливают product owner и клиент?
Всё должно быть «сделано» в течение одной или двух недель
Нет, не должно. Просто после каждого спринта клиенту показывают что за его время успели сделать.
Скрам определенно лучший вариант для доставки вашего продукта в отведенное время.
С чего это вдруг? В скраме планировка по хорошему идёт на следующий спринт. продукт вы за спринт вряд ли сделаете.
С чего это вдруг
А вы думаете, что такие высказывания в скраме или о скраме кто то будет или должен доказывать? Нет. Это принимается всеми как аксиома. Ведь не дураки же назвали это agile, если бы это не было бы agile?! #ирория
В агиле "пацаны" по понятиям живут. Им не нужны никакие доказательства.
Скрам это скорее набор ингредиентов, чем рецепт (а аджайл вообще - философия). Что получится в итоге: пельмени, беляши или что-то несъедобное - зависит от того, как вы решите это приготовить (ну или кто там у вас решает). Поэтому личный опыт с ним у всех насколько противоречив. У меня скорее отрицательный в российских компаниях, и в целом положительный в паре зарубежных. Похоже, что разница на уровне каких-то общих управленческих традиций. Вероятно это то, что заставляет смотреть на текст под определенным ракурсом и не передается в буквальном переводе.
Мне это чем-то астрологию напоминает. Использует вроде что-то похожее на инстременты как и в астрономии. Но вместо научного обоснования — набор понятий и хотелок.
Работал во многих зарубежных компаниях. От мала до велика. Во всех одно и то-же по agile — хотелки/обещания/неподдающее расчёту использование человеческого ресурса и денег, постоянное невыполнение результатов/срыв сроков на года/постоянный вылет продукции, хоть и тестируется вроде до потери пульса итд. Никто не отвечет ни за срывы, ни за качество, ни за простои или за невыполнение обещаний, за безхозное расходование денег и подавно. Лафа да и только.
Интересная метафора. В принципе и в русском языке говорят "искусство управления". Поставить управление на научные рельсы пытаются уже давно, пробуя применять различные подходы - от классических научных до кибернетики и управления отношениями. Периодически из этой деятельности выпадают какие-то рецепты, но успеха ни кто не гарантирует - иначе бы уже давно все всё сделали правильно (и даже раньше всех остальных).
Например, есть фреймворки с большой степенью деталиции, где методы управления, активности и процессы описаны достаточно подробно. Это ITIL, PMBOK, DSDM и иже с ними. Но то весьма объемные, скучные в изучении и непростые во внедрении вещи, требующие много компетенций, воли и денег. Опять же без особых гарантий.
Но то весьма объемные, скучные в изучении и непростые во внедрении вещи, требующие много компетенций, воли и денег
… ну это всегда так — та-же политика полна компромиссов, полу-тонов, а можно как Шариков, взять и всё поделить, или те козлы, а эти друзья, типа упрощать на словах — всё белое или чёрное. Что оно не такое — а кому это интересно. Зачем мучить себя формулами подсчёта срока, нужных ресурсов итд. Можно демократично проголосовать и можно-же все эти «ненужные и нудные» формулы вообще убрать и обещать сделать столько, сколько сделаешь.
Сгущу краски. На мой взгляд, худшее что случалось в IT - эти самые гибкие методологии. С ними иногда думаешь так - а благодаря ли им все получалось или вопреки. И чего только стоил бизнесу этот весь ненужный инженерам культ.
Scrum, Kanban или оба?