Сегодня большинство компаний используют методологию Agile при разработке программного обеспечения. У Agile есть разные системы с похожими принципами и конечными результатами, но они различаются по структуре и подходу к управлению. Какой из них лучше всего подходит для вашего проекта? Это Скрам или Канбан? Или оба?
В преддверии старта курса Agile Project Manager поговорили об этом с экспертом Otus - Олегом Мельником.
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
Agile
В последние годы это стало самой популярной стратегией управления проектами. Ключевые особенности методологии - открытое общение и гибкость, всегда ориентированная на результат . Его основная цель - предоставить покупателю ценность.
Agile - это интерактивная и поэтапная методология управления проектами, характеризующаяся постоянной адаптацией проекта к требованиям конечных пользователей посредством совместной работы и адаптивности. По моему опыту, этот подход всегда требует адаптивного планирования , эволюционных решений и точной доставки программного обеспечения.
Scrum
Scrum - это гибкий метод управления потребностями проекта. Он используется в основном при разработке программного обеспечения, где задачи эффективно делегируются небольшой команде . Этот тип управления доказал свою эффективность благодаря своей простоте и производительности . В последние годы он стал самым широко используемым подходом при разработке программного обеспечения.
Фактически, термин «scrum» происходит от scrimmage , позиции игрока в регби, образованной членами команды, толкающими друг друга, чтобы получить мяч. Соответственно, основная идея структуры - это регулярное сотрудничество внутри команды, направленное на устранение коммуникационных пробелов. Таким образом, становятся ясными цели проекта и задачи, возникающие на его пути.
В Scrum есть три роли : Product owner, Scrum Master и команда разработчиков, которые разбивают работу по разработке продукта на небольшие этапы, называемые спринтами. Это временные рамки, состоящие из мероприятий по планированию спринтов, ежедневных схваток, обзоров спринтов и ретроспективных мероприятий спринта, которые проходят каждый спринт. В каждом спринте высокопроизводительная команда Scrum находит инновационные решения сложных проблем, чтобы разработать, выпустить и поддерживать продукт.
Команда относительно небольшая, обычно 3–9 человек. Product owner и клиент устанавливают все правила , Scrum Master выступает в роли фасилитатора и коуча, а разработчики привержены своим обязанностям.
Команда Scrum поставляет программное обеспечение постепенно, с пометкой «Готово», чтобы максимизировать обратную связь и повысить эффективность.
Kanban
Подобно Scrum, Kanban - это управленческий подход, предназначенный для удовлетворения меняющихся требований. Он ориентирован на непрерывную поставку работающего программного обеспечения без установления строгих правил. Как правило, он состоит из нескольких небольших команд, работающих независимо над конкретными задачами, размещенными на доске Канбан. Гибкость - один из основных принципов Канбана. «Канбан» в переводе с японского означает рекламный щит. Следовательно, визуализация доски является основным организационным инструментом для фреймворка Канбан.
В Канбане нет конкретных размеров команд или должностей. На доске указаны главные приоритеты каждой команды. В канбан-менеджменте нет временных ограничений. Это дает членам команды свободу работать так интенсивно, как они хотят, чтобы выполнить свою работу. Фактически, свобода дает больше обязанностей. Команды должны организоваться и полагаться на свой опыт, не ожидая присмотра.
Нет необходимости в ограничении задач или мерах контроля. Однако менеджер может измерить среднее время выполнения задач и обсудить это с командами в качестве попытки улучшения. Также он организует доску, на которой записываются все цели, будущие задачи, тесты и выполненные задачи.
Отличия
Рабочие роли и обязанности
Как обсуждалось выше, у членов команды Scrum есть предопределенные роли, в то время как Kanban более свободны. Владелец продукта Scrum полностью контролирует постановку целей , делегирование задач и планирование процессов. Существуют иерархии, которые обычно не меняются на протяжении жизненного цикла проекта.
В Kanban менеджер является организатором проекта, где команды разработчиков сотрудничают и помогают друг другу независимо от того, над какой стороной проекта они работают. Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.
Какая команда работает лучше? Это зависит от характера проекта. Проект разработки программного обеспечения, требующий строгого набора правил, будет лучше управляться командой Scrum. Напротив, если проект требует непрерывной реализации , гибкая команда Kanban подойдет лучше. Таким образом, тип команды зависит от гибкости проекта, делегирования задач и организации.
Планирование и сроки поставки
Скрам - это самое время. Всё должно быть «сделано» в течение одной или двух недель. Сразу после этого начинается следующий Спринт. После точного измерения возможностей команды в предыдущих графиках, в обзорах спринтов обсуждается оптимизация рабочей нагрузки и времени.
Канбан не заботится о времени. Речь идет о прозрачности, эффективности и продолжительности. Если Scrum - это «марафон», то Канбан - это «путешествие». В Scrum продукт доставляется часто, в то время как в Kanban он доставляется как единое целое, когда это будет готово.
Планирование времени лучше или нет?
В идеале руководство должно отвечать ожиданиям клиента относительно того, когда будет выпущен продукт. Скрам определенно лучший вариант для доставки вашего продукта в отведенное время. Из-за спринтов Scrum желателен для проектов, в которых клиент и руководство фиксируют прогресс. Отсутствие согласованного расписания в канбане предназначено для более сложных проектов в долгосрочной перспективе, когда работа выполняется точно, а не в спешке.
Производительность и измерение
Scrum и Kanban нацелены на улучшение качества , наряду с производительностью, чтобы повысить эффективность компаний, занимающихся разработкой программного обеспечения. Команда Scrum сотрудничает для выполнения задач, уделяя особое внимание решению всех проблем, возникающих при разработке и тестировании программного обеспечения. Ежедневный скрам и обзоры спринтов позволяют непрерывно измерять производительность труда. Это способствует способности команды выполнять сложные проекты.
Канбан ориентирован на достижение индивидуальных целей, записанных на доске Канбан. Прогресс не имеет конкретных мер. Обычно визуализация задач показывает прогресс каждой небольшой команды.
Является ли одна гибкая методология более продуктивной, чем другая? Конечно же нет. Не существует правильного рецепта гибкого управления. Это зависит от потребностей проекта. Просто дайте понять: каковы цели проекта? Какой рабочий процесс лучше всего подходит членам команды? Каков спрос со стороны конечного пользователя?
И Scrum, и Kanban усиливают управление проектом, но по-другому. Так зачем выбирать только один из них? Что, если есть третий метод, сочетающий в себе их лучшие качества?
Scrumban?
Scrumban создан для того, чтобы помочь в переходе Scrum на Kanban. Это гибрид , характеризующийся методами управления, которые позволяют постоянно совершенствовать разработку программного обеспечения. Предполагается, что у Скрама есть место для улучшения, применяя принципы Канбан.
Визуализация рабочих элементов из системы Канбан представлена в Scrum. Рабочие элементы Scrum, находящиеся в процессе выполнения, подробно описаны на доске Kanban. Диаграммы применяются для выявления слабых мест и выявления возможностей для улучшения. Следовательно, Scrumban будет иметь растущую прозрачность, где каждый может видеть, что происходит с проектом.
Команда Scrum становится более специализированной. Обычно есть рабочие роли, но делегирование обязанностей более гибкое. Таким образом, команда работает в полную силу . Члены команды мотивированы работать вместе, как в Scrum, но у них есть индивидуальные задачи. Scrumban помогает повысить эффективность обязательств в команде.
Команда Scrum иногда может прийти к незавершению нескольких задач из-за ограничений по времени. При применении метода планирования Канбан задачи полностью завершаются до перехода в столбец «Готово». Вместо того, чтобы выпускать рабочие элементы раз в 2–3 недели в Sprints, существует постоянная поставка рабочего программного обеспечения. Качество превыше времени. Таким образом, в Scrumban есть улучшения по запросу, чтобы максимизировать поток работы.
Поэтому, не любите Scrum. Самыми важными стали метрики Канбан, а не скорость. Улучшение проекта выявляется внутри каждой команды самостоятельно. Это позволяет более достоверно оценивать прогресс.
Однако в Scrumban структура Sprint по-прежнему присутствует для обратной связи с командами.
Обзоры спринтов используются для анализа результатов каждого рабочего цикла. Далее, как и в Scrum, ежедневные встречи отслеживают непрерывную работу над требованиями.
Scrumban - это инновационный гибкий подход, при котором руководство стремится повысить эффективность проектов разработки программного обеспечения. Это обеспечивает гибкость Scrum и измерение потока работы Kanban. Качество работы улучшается за счет минимизации потерь времени и выполнения задач вовремя, но с максимальной загрузкой.
На этом все. А тех, кто желает подробнее узнать о курсе, познакомиться с преподавателями и почерпнуть еще больше полезной информации, приглашаем на бесплатный демоурок по теме: "Как уточнять статусы задач и подружиться с соседями".
Комментарии (44)
K_Chicago
08.12.2021 23:58+10Можно я расскажу про то, как agile в приказном порядке применяется в нашей фирме?
Итак, IT команда составляет ~20 человек, 14 из них работают удаленно из Индии. Все работаем из дома.
Проект: миграция существующего приложения на Oracle Forms в приложение на Oracle ADF, т.е. переход от простого и оптимального front-end GUI PL/SQL на запутаный, забагованый, тормозной и хаотичный ADF и Java. В команде есть четверо индусов которые имеют 1-2 года опыта в ADF на простеньких формочках и б-м знают Java. Все остальные хорошо знают SQL, PL/SQL, Forms&Reports, но никто из них никогда не работал с Java. Велено просто брать скрины из имеющегося приложения на Forms и воспроизводить их на ADF. Приказано использовать метод разработки Agile.
Как это выглядит, на своём личном примере. Каждому было предоставлено выбрать, какую форму он будет переделывать на ADF. Выбрал ту, которую я же пару лет назад сделал на формсах, она довольно хитрая, непрямое редактирование данных (т.е. не просто грид с редактируемыми полями а исключительно процедурно), хитрая программная навигация, не вполне тривиальные запросы. В ADF я полный ноль. Сейчас готово на ~80%, после 3(!) месяцев разработки с нуля.
Наш "agile":
Нам установили Jira (раньше никто с этим не работал). Каждому велели разбить свою работу на "таски", т.е. какие-то этапы разработки, по собственному усмотрению. Каждому "таску" велели приписать "пойнты", которые как бы эквивалент сложности этапа. Запрещено давать больше 3х пойнтов.
ввели "церемонии" Agile и назначили от балды "скрам-мастера". В нашей комаде это бывший таксебе разработчик, в соседней - вообще бывший руководитель фальшивого QA, армейский парень, в разработке никогда не участвовавший, чисто администратор с армейскими замашками. Общий принцип назначения - аккуратность, испольнительность, безоговорочная лояльность менеджменту, готовность исполнять любые указания сверху с восторгом и преданностью.
каждое утро в 9:00 - daily standup. На 20 человек 15 минут, каждый обязан сказать что он делал в прошедший день, иногда - от балды сказать процент выполнения текущего таска. Никакие технические, проблемные вопросы не разрешены. Скрам-мастер вызывает всех по очереди, всем говорит "хорошо, спасибо". Если нужно, заносит слова разработчика в Jira. Вопросов не задаёт. Это все его функции.
Разумеется, каждый работает над своей личной задачей, задачи никак не пересекаются. Например, я работаю над своим скрином, я знаю что я его буду делать 3-4 месяца, никаких деплойментов не предвидится. Но мне приказали придумать таски так чтобы к концу каждого "спринта" - а спринт приказали делать 10 рабочих дней - я мог сказать что этот таск выполнен и это отметят в Jira. Во время этих стэндапов никто не интересуется что говорят другие, у всех свои задачи.
Также раз в две недели обязательный двухчасовой митинг под названием backlog grooming, с непонятной целью. Делается не на всю команду, а группами по 3-4 человека. Например, я должен рассказать какие у меня технические проблемы, остальные, совершенно не понимая моих проблем, комментируют.
Также перед концом каждого "спринта" двухчасовой митинг, называется Sprint review и назначаются "добровольцы" которые обязаны продемонстрировать чего-нибудь, обычно текущее состояние того ADF приложения, над которым они работают. Кому и зачем - непонятно, никого это не интересует, все заняты своими ADF страницами.
Также есть еще один часовой митинг в конце "спринта" когда "скрам-мастер" вызывает каждого по очереди и ты обязан сказать "что мы сделали хорошо и что мы можем сделать лучше", смысл высказывания значения не имеет, вопросов не задается, твои "соображения" скрам-мастер тщательно записывает в Jira.
Вот пожалуй и весь "agile". Да, все это протоколируется и отправляется начальству наверх, а оно отправляет еще выше.
Итог: потеря времени на "митинги" доходящие до 8 часов в неделю, скорость разработки упала в 3-4 раза. Все понимают что это цырк с кОнями, я говорил со всеми ведущими девелоперами, каждый сказал "я понимаю что это все глупость, но я делаю это для того чтобы just to pay my bills.
Началось все это 4 месяца назад. Они планируют и в самом деле продеплоить несколько простейших страничек в "production" через пару месяцев. ЧтО такое этот "Production" и кто будет его использовать - непонятно. Вся компания использует старое приложение. Чтобы воспроизвести его функциональность в ADF такими темпами понадобится минимум 2-3 года.
"Спринты" никоим образом не связаны ни с каким деплойментом, ни даже с коммитом в Git.
Скрин невозможно продеплоить "частями" , он или готов или не готов. Я на одном из митингов сравнил то что мы делаем с попыткой рожать ребеночка по частям каждые две недели в течении 9 месяцев. Посмеялись. Скрам-мастер (кстати,еврей из СССР) написал на меня донос что мои высказывания плохо влияют на мораль команды. Это такая традиция у еврейских комиссаров видимо - доносы писать.
Местоимения: транспортная компания с 30 лет работы, принадлежащая одному из крупнейших (в 5 верхних) частных финансовых бизнесов США.
Я увольняюсь через неделю.
Myclass
09.12.2021 01:44я должен рассказать какие у меня технические проблемы, остальные, совершенно не понимая моих проблем, комментируют.
У меня на этих комментаторов аллергия. Они во всём «разбираются». Говорят правильные слова, ничего не значущие, но позволяющие этим комментаторам считаться экспертами. И дополнение к этому, ону хотят типа вникнуть во все детали и все им раскрывают карты, пытаются показать. Но этим экспертам нужны не детали, а именно время, которое тратиться на все эти дополнительные телодвижения, которые к успеху продукта никакого отношения не имеют.K_Chicago
09.12.2021 02:36+1я например в таких "обсуждениях" никогда ничего не говорю, за это мне в performance review написали что "недостаточно активно учавствует в Agile церемониях". Это офисная экосистема о которой только стыдливо намекнули в прекрасном фильме Office space, она доминирует абсолютно везде в Штатах, но обсуждение этой заразы табуировано.
Myclass
09.12.2021 02:43и вот это мне и не понятно. Ведь капитализм должен смотреть всегда на затраты/ценны/сроки/качество. А тут социализм какой-то. Как-будто та фирма, в которой к этому принуждают не принадлежит хозяину. Просто логикой это не обьяснить.
K_Chicago
09.12.2021 03:44+2про "капитализм должен" - нет.
Это представление о капитализме 19 века...ну или из совковой агитации.
Я здесь в капитализме живу уже 15 лет. Мне многое очень нравится, но я был поражён, насколько производственные идиотические принципы близки к совку. Именно "социализм какой-то". В общем те принципы, о которых вы говорите, здесь применимы, скажем, если вы откроете закусочную со штатом в 3 человека, включая вас, вашу жену и бедолагу-негра.
А когда речь идет о мега-корпорациях, размером в сотни тысяч человек - это вполне себе идиотический социализм внутри, государство в государстве. Совет директоров состоит из миллиардеров, им потеря/получение сотни-другой тысяч безразлично. Их мотивации вообще плохо понятны...я подозреваю, они вообще теряют мотивацию. Типа, не допускать глобальных косяков, боятся они ну, может быть во многих случаях, только правительства, а больше никого. Потому что провительство единственный орган который может взять их за жопу, например, Wells Fargo, создали без ведома клиентов, несколько миллионов(!) фальшивых счетов, им наложили штраф в пару миллиардов, и запретили расширять бизнес. Это да, это хозяева понимают. А что какая-то мелкая фирмочка из сотен, принадлежащих Wells Fargo, покажет годовую прибыль на 2 миллиона меньше чем в прошлом году - "боже мой, да всем насрать!"
GospodinKolhoznik
09.12.2021 11:58+1Видимо начиная с какого то большого размера абсолютно не важна - капиталистическая организация, или социалистическая, всё что реально волнует топ менеджмент, это чтобы юридически на бумагах всё было чисто. А все остальные бизнес-процессы существуют лишь для обяспечения возможности этой юридической чистоты.
В этом плане пункт манифеста аджайла Работающий продукт важнее исчерпывающей документации совершенно неверен. Документация это документ - с ним можно и в суд придти, и иск против организации выиграть с далеко идущими последствиями. А продукт это что? Кому вообще интересен продукт?
K_Chicago
09.12.2021 21:53+2"в этом плане" ВСЕ пункты "Манифеста" не то чтобы неверны, а совершенно не соответствуют бизнес-реальности. Эти 16 (на самом деле 17) хипстеров которые манифест родили, имели ввиду что-то вроде стартапа, маленькую неформальную группу энтузиастов работающих вместе над каким-то продвинутым проектом. Вот тогда это будет работать. По таким принципам Возняк и Джобс могли бы делать первый Эппл.
Как я уже говорил, эффективные менеджеры быстро распознали в этой "мясокрутке" продукт двойного назначения, отобрали его у хипстеров и провозгласили своей идеей светлого будущего, полностью извратив.
Именно чтобы продемонстрировать это, я и процитировал принципы манифеста на одном из митингов. Под видом "как я люблю эджайл и как же здорово что наше мудрое руководство позволило нам его использовать". Так чтобы даже самым тупым стало ясно, что тот цырк, к которому нас принудили, не имеет к Agile никакого отношения. Менеджмент понял, что это была провокация, и мне через пару дней сильно прилетело, с несформулироваными обвинениями, но в общем смысле.
lonelylockley
09.12.2021 09:45+1Частая история когда к организации процессов по скраму относятся как к волшебству: «Сделай скрам и дальше всё завертится само!». Любая методология разработки — инструмент. Тяжелым инструментом можно забивать гвозди, а можно разбить головы всем вокруг. С вами приключилось второе.
Agile может быть не токсичным и полезным если сделать всё правильно, наполнить общие безликие рекомендации конкретным смыслом, правильно подготовить и менеджеров и разработчиков. Я видел примеры здоровых скрам процессов, которые не скатились тупо в исполнение ритуалов.
Чтобы не быть голословным: правильный ежедневный стендап проводился у нас не только для того, чтобы протрекать прогресс по задачам, но и помочь снять все блоки. В нашей команде из 11 человек встреча занимала 7-10 минут: мы трекали прогресс, накидывали список текущих проблем, просили помощи если не хватало экспертизы и ничего не решали прямо на встрече — договаривались о коротких созвонах после стендапа. Обычно в течение часа-двух все блоки по задачам снимались, разработчики могли заниматься своими делами, а менеджеры не бегали к ним каждый час с традиционным «Ну как там?».
leon_nikitin
09.12.2021 13:09делать все правильно и "со смыслом", это - не про аджайл. В смысле, эджайл тут не причем. Это - единственный пункт универсального манифеста всех методик.
K_Chicago
09.12.2021 22:03+3"Коммунизм может быть не токсичным и полезным если сделать всё правильно, наполнить общие безликие рекомендации конкретным смыслом, правильно подготовить коммунистов и беспартийных. Я видел примеры здоровых коммунистических процессов, которые не скатились тупо в исполнение ритуалов."
Шютка.
По существу ваших идеальных "стендапов": - "чтобы помочь снять все блоки". В команде разработки здорового человека, "блоки" снимаются немедленно в процессе возникновения путем - "застрял? курил мануалы, гуглил и ничего? Ладно, иду вон к Пете или к Маше за соседним деском, я знаю они с похожим сталкивались, попрошу помочь когда им будет удобно и когда у них будет время, а за мной ответка не пропадет".
В чумной палате Agile: "дождусь утреннего стендапа, сообщу всей команде какой я мудак и тупень, еще поебу всем мозги договариваясь о созвонах с занесением в Jira и назначением митинга в расписании команды, сесли будет свободная комната для митингов, приглашу на всякий случай менеджера и скрам мастера".
Видна разница?
Это один из пунктов моего бодания с холуями скрама: здесь нет начинающих кодеров-первогодок, мы все друг друга знаем по 10 лет, если у меня есть проблемы - я знаю куда идти и кого попросить помочь, мне для этого не нужно ждать очередной "церемонии" и не нужно заниматься всей этой хуетой с организацией митингов и дрочкой на Jira.
lonelylockley
10.12.2021 08:05+2Вы просто с порога отказываетесь видеть то рациональное, что есть в данных методологиях и начинаете раздувать мои аргументы до гротеска.
Самое забавное здесь именно то, что scrum как и коммунизм должен всех уравнять. Цель этих приседаний (планирований, работы над беклогом, стендапов) упорядочить поток задач, помочь быстрее решать проблемы тем у кого хуже развиты навыки общения и при этом остаться достаточно гибкими в планах.
Ты новичок, ты не знаешь пока что людей и участки за которые они отвечают. У вас не офис, а удаленка. Куда идти? Кого спрашивать? Звонить по каждой проблеме руководителю или тимлиду, чтобы свели с нужным человеком или ткнули в документацию? А не лучше собрать скопившиеся за день вопросы и проблемы и разом их проговорить/решить? А может к концу дня и сам разберешься. А Петя и Маша весь день сидят и ждут гостей? Они может уже работают в потоке, а тут приходит новенький и выдергивает их оттуда.
NN1
09.12.2021 13:22Всё очень знакомо, правда, к счастью, не настолько было плохо :)
А так да, церемонии заседаний где каждый говорит о прогрессе и проблемах, но в итоге никто ничего с этим не делает.
Когда начинаешь тыкать всех в грязь лицом потому, что начальник не понимает почему нет продвижения, то оказываешься ещё и крайним, т.к. "заставляешь" других работать на себя.
Итого все говорят, что всё хорошо, но прогресса нет совсем и все довольны этой игрой.
Правильным ответом, как оказалось, было взять на себя обязанности других и просто выполнить их работу, хотя при этом никто твою делать не собирался.В общем, цирк остался, а я ушёл.
Polaris99
09.12.2021 17:46каждое утро в 9:00 - daily standup. На 20 человек 15 минут. Скрам-мастер вызывает всех по очереди, всем говорит "хорошо, спасибо". Если нужно, заносит слова разработчика в Jira. Вопросов не задаёт.
Я так понимаю, вот эти 15 минут плюс, может быть, еще 15 минут на занесение в Джиру - это весь его рабочий день? Плохо разве? Хорошо ж устроился человек!
K_Chicago
09.12.2021 22:07ну там у него есть еще доклады начальству, в Джиру он заносит с чувством и с толком, по часу и дольше. А так конечно, отлично устроился, это классическая холуйская должность с хорошей перспективой продвижения в менеджеры. Воняет говнецом конечно, но ведь "говно - не сало, потрёшь - отстало".
mad_nazgul
09.12.2021 18:39У меня немного другой опыт с канбаном.
Есть flow, по которому движется задача.
Требование только одно довести задачу (таск) до конца (самый левый столбик)
Нет ограничения по времени, темп работы выбираешь сам.
Т.к. работаем удаленно, то на дейли можно договориться о помощи, если требуется.
Работать комфортно.
Так что как обычно проблема не в методологии а в людях.
Это как в анекдоте. "Команда работала по agile, пока не стали внедрять agile." :-)
tundrawolf_kiba
09.12.2021 23:23Не так страшен аджайл, как его внедренцы. На самом деле из опыта — просто в 9 случаях из 10, или даже чаще — внедрение происходит «для галочки», без понимания процессов, что и приводи к проблемам. Всего один раз довелось работать на проекте, где аджайл был адаптирован под проект, но до сих пор считаю тот проект — лучшим, по организации, на котором довелось работать.
K_Chicago
10.12.2021 03:17это верное наблюдение, но тогда возникает резонный вопрос - а если в 9 из 10 случаев продукт внедряется с точностью до наоборот - а может быть что-то надо в консерватории подправить? Т.е. мы наблюдаем при этом некое скрытое свойство продукта...а не внедренцев? Типо, если по чертежам сборки, скажем, пылесоса, раз за разом собирается АКМ - так может дело не в сборщиках?
tundrawolf_kiba
10.12.2021 03:30Думаю, проблема именно в ожидании чертежей теми, кто внедряет, игнорирование гибкости аджайла. Знаете, вот если сравнивать — то на ум пришло сравнение с xpath. Новичок будет строить абсолютный путь, который будет ломаться при каждом изменении верстки, но это не значит, что технология плоха, т. к. человек поопытнее — будет использовать относительные пути или просто попросит разработчиков добавить удобные идентификаторы и такое уже будет ломаться очень редко. Так и тут — вместо того, чтобы почитать подробно, изучить плюсы и минусы подходов, подводные камни — просто берут шаблон из интернета и пытаются втиснуть свой процесс в прокрустово ложе шаблона, хотя правильный подход предполагает как оптимизацию процессов, так и оптимизации методологии так, чтобы она упрощала ведение процессов, а не наоборот.
Myclass
10.12.2021 15:54да всё просто — раньше, чтобы управлять проектом, организацией, командой надо было пройти много стадий и учиться. Методом проб и ошибок получать опыт. Постоянно вникать в суть вещей, в технологии. А сейчас этого не надо. После небольшого введения (1-3 недели) в agile, scrum, safe — ты уже «начальник» — мастер. Ну кто тут будет противится такому лёгкому пути?! Где не надо ночами сидеть над книгами, понимать или заучивать научные труды по управления проектов.
Reposlav
10.12.2021 16:28У вас интересный опыт, но странные выводы: негативное отношение к Аджайлу, когда в вашей фирме его толком и не было.
Если мошенник продаст вам фейковый Айфон, ругаться из-за низкого качества вы будете на Эппл?
HemulGM
09.12.2021 07:52+2Сколько лет уже этому манифесту
http://macode.ru/
K_Chicago
09.12.2021 09:05как я уже сказал, 20 лет. Был выпущен в феврале 2001 года. "Эффективные менеджеры" внедрение извращенного и бессмысленного agile всё еще называют "переход к современным технологиям разработки". На одном из митингов про modern technology я сказал "it was modern 20 years ago", начальник IT отдела посмотрел на меня неласково.
funca
09.12.2021 11:19-1Скрам и канбан роднит общий управленческий подход, где любые сколь угодно сложные работы, выполнение которых требует специальных знаний и навыков, абстрагируются до карточек - задач. Это даёт возможность передать контроль над процессом от того, кто лучше делает тому, кто лучше говорит.
В остальном же это лишь разные методы управления очередями задач и мотивацией команды, где вопросы теории очередей и управленческой психологии метафорически изложены в виде готовых рецептов, что позволяет быстро вводить в строй новых менеджеров.
piton_nsk
09.12.2021 12:55+3Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.
Очень люблю этот пример. Почему-то всегда получается так что разработчик кому-то начинает помогать. А бывает ли наоборот? QA начинает писать код,
сапоги тачать пирожникбизнес-аналитик настраивать сервера?tundrawolf_kiba
09.12.2021 23:27QA начинает писать код, сапоги тачать пирожник бизнес-аналитик настраивать сервера?
С точки зрения скрама — так и должно быть, в нём нет разделение на роли в команде разработки. На мой взгляд — один из самых существенных недостатков скрама.
NN1
11.12.2021 10:32Дальше-больше :)
Некоторые считают, что эффективная команда должна помощь другим менее эффективным.
Но разбираться почему другая команда менее эффективна никто не собирается.
Выходит, что выгоднее завысить сроки и просто плевать в потолок, чтобы успеть к интеграции также «быстро» как и другие.
Kanut
09.12.2021 15:59+1Product owner и клиент устанавливают все правила
С каких это пор в скраме все правила устанавливают product owner и клиент?
Всё должно быть «сделано» в течение одной или двух недель
Нет, не должно. Просто после каждого спринта клиенту показывают что за его время успели сделать.
Скрам определенно лучший вариант для доставки вашего продукта в отведенное время.
С чего это вдруг? В скраме планировка по хорошему идёт на следующий спринт. продукт вы за спринт вряд ли сделаете.
Myclass
09.12.2021 20:36С чего это вдруг
А вы думаете, что такие высказывания в скраме или о скраме кто то будет или должен доказывать? Нет. Это принимается всеми как аксиома. Ведь не дураки же назвали это agile, если бы это не было бы agile?! #ирория
В агиле "пацаны" по понятиям живут. Им не нужны никакие доказательства.
funca
09.12.2021 23:30Скрам это скорее набор ингредиентов, чем рецепт (а аджайл вообще - философия). Что получится в итоге: пельмени, беляши или что-то несъедобное - зависит от того, как вы решите это приготовить (ну или кто там у вас решает). Поэтому личный опыт с ним у всех насколько противоречив. У меня скорее отрицательный в российских компаниях, и в целом положительный в паре зарубежных. Похоже, что разница на уровне каких-то общих управленческих традиций. Вероятно это то, что заставляет смотреть на текст под определенным ракурсом и не передается в буквальном переводе.
Myclass
10.12.2021 01:33+1т.е. это больше искусство чем научный подход. Со всеми отсюда вытекающими последствиями. Каждый, труженник искуства желает себе создавать только шедевры. Но шедеврами становятся единицы. Но в настоящем искустве никто никому даже в высшем заведении не гарантирует успеха. Здесь-же только и слышишь — используй agile и всё — успех в кормане. А оно видешь — как подойдёт, как понравиться, как справятся с этим итд.
Мне это чем-то астрологию напоминает. Использует вроде что-то похожее на инстременты как и в астрономии. Но вместо научного обоснования — набор понятий и хотелок.
Работал во многих зарубежных компаниях. От мала до велика. Во всех одно и то-же по agile — хотелки/обещания/неподдающее расчёту использование человеческого ресурса и денег, постоянное невыполнение результатов/срыв сроков на года/постоянный вылет продукции, хоть и тестируется вроде до потери пульса итд. Никто не отвечет ни за срывы, ни за качество, ни за простои или за невыполнение обещаний, за безхозное расходование денег и подавно. Лафа да и только.funca
10.12.2021 11:59Интересная метафора. В принципе и в русском языке говорят "искусство управления". Поставить управление на научные рельсы пытаются уже давно, пробуя применять различные подходы - от классических научных до кибернетики и управления отношениями. Периодически из этой деятельности выпадают какие-то рецепты, но успеха ни кто не гарантирует - иначе бы уже давно все всё сделали правильно (и даже раньше всех остальных).
Например, есть фреймворки с большой степенью деталиции, где методы управления, активности и процессы описаны достаточно подробно. Это ITIL, PMBOK, DSDM и иже с ними. Но то весьма объемные, скучные в изучении и непростые во внедрении вещи, требующие много компетенций, воли и денег. Опять же без особых гарантий.
Myclass
10.12.2021 15:29согласен с Вами и с выводами, как раз про это я и говорю…
Но то весьма объемные, скучные в изучении и непростые во внедрении вещи, требующие много компетенций, воли и денег
… ну это всегда так — та-же политика полна компромиссов, полу-тонов, а можно как Шариков, взять и всё поделить, или те козлы, а эти друзья, типа упрощать на словах — всё белое или чёрное. Что оно не такое — а кому это интересно. Зачем мучить себя формулами подсчёта срока, нужных ресурсов итд. Можно демократично проголосовать и можно-же все эти «ненужные и нудные» формулы вообще убрать и обещать сделать столько, сколько сделаешь.
beduin01
За много лет так и не понял, чем одно от другого отличается. И признаться желания никакого. Вместо работы предлагаются какие-то танцы в присяду.
Kolonist
А это, видимо, потому что никто эти процессы не любит соблюдать. Вот и получается либо недоскрам, либо полуканбан, либо вообще канбарам.
А так, судя по статье, скрам - это когда есть спринты с атомарными фичами и релизами, а канбан - это когда нет спринтов и релизов, а есть постоянные допиливания-улучшения по мере готовности. Когда делаем продукт на заказ к определенному сроку - лучше спринт. Если в непрерывном режиме поддерживаем и улучшаем свой продукт без обязательств по срокам конкретных фичей - больше подходит канбан.
beduin01
Может нафиг тогда эти свистопляски и модные методологии, если они только мешают работать?
Kolonist
А кто сказал, что они мешают? Если их применять к месту и строго следовать, то они только помогают.
Myclass
это как с коммунизмом. Всегда все мотивируют след. вариант построяния коммунизма тем, что прошлые попытки построения коммунизма как-бы были не совсем правильные, и надо собраться и в след. раз сделать обязательно лучше. Отвлекая от того, что сама система — коммунизма — это утопия. Но ведь это никто никгда не скажет. Так же и с агилем. Если это не работает, а в большинстве своём это не работает нигде. И происходят полу-меры, то причину видят не в системе, а в её реализации.
Как-то был в гостях в одной фирме, где плоская хирархия. Никаких там начальников, никакив подчинённых, каждый в состоянии сам выбирать род деятельности, проект на которым хочется работать итд. Вроде бы — смотри — работает. А потом смотришь на средний возраст сотрудников. И выясняешь для себя, что там нет (почти) никого старше 35. Поговорив, обьясняют, что люди когда-то типа взраслеют. И это и понятно. Ведь альтруизм когда-то заканчивается, когда обзаводишся семьей, детьми и надо думать о будущем, о том, как использовать свой человеческий и проффесиональный капитал. А в агиле рамки использования этого капитала ограничены. Ведь карьера — это не агиль. Развиваться проффессионально — это инвестиция в будущее. А агиль эту инвистицию обнуляет постоянно.
Т.е. агиль — это своего рода допольнительный вариант решения задач. Своего рода как аврал в проекте. Никто его не будет видеть как «правильный» подход в проекте. Но когда надо, то такой критичный подход, где каждый участник проекта готов и отпуском пожертвовать и выходными — иногда и работающая конструкция. Но не всегда-же.
K_Chicago
Мне довелось почитать первоисточник, называется Agile Manifesto. Это 20 лет назад в мормонском штате Юта собрались 16 программистов, дунули как пологается, и родили вот это:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Звучит вполне себе в стиле хипстерских 60-х, и в каком-то очень частном случае софтверной разработки может оказаться полезным. Но это как у АБС, изобретённая отцом Кабани мясокрутка для приготовления "нежного мясного фарша", оказалась очень востребована в пыточных подвалах дона Рэбы. В точности та же ситуация, эффективные менеджеры вцепились в это руками и ногами потому что это прекрасный способ осуществлять микроменеджмент и иллюзию бурной дейятельности под видом нового и прогрессивного.
Reposlav
Понятия "полуканбан" быть не может. Частичный канбан - это уже канбан (в отличие от скрама, где частичный скрам не является скрамом совсем). Это обусловлено оной из ценностей канбана - эволюционные изменения.
Из статьи действительно может сложиться это ложное впечатление. В реальности же, сравнивать канбан и скрам нет смысла, потому что это то же самое, что сравнивать понедельник с Хондой. Скрам - это процессный фреймворк, заданный набор жестких правил. Канбан - это метод эволюционного изменения процессов с набором рекомендаций. Релизы в канбане очень даже могут быть, у канбана даже одна из каденций - Встреча по планированию поставки. Спринты - вопрос терминологии: если по канбану у нас встречи по наполнению очереди раз в две недели, и очередь наполняется на две недели вперед, то как раз получаются те же двухнедельные спринты.
Вообще в статье есть довольно спорные заявления, например
Либо я не так понял посыл, либо это неверное заявление. В канбане есть даже два классических класса обслуживания, намекающих на большой заболе о времени: ускоренный и с фиксированной датой поставки
частично верное заявление. Должностей действительно нет, но есть роли, о чем можно было бы и упомянуть.
В общем, к статье довольно много вопросов.
Kolonist
А не поделитесь ссылкой, где бы прочитать поподробнее? А то в Википедии про канбан полтора предложения.
Apathetic
Можно начать с https://resources.kanban.university/kanban-guide/
Reposlav
Алексей Пименов хорошо рассказывает про канбан, можно поискать его материалы.
Несколько хороших статей можно найти на https://scrumtrek.ru/blog/kanban/, можно начать с https://scrumtrek.ru/blog/kanban/1360/chto-takoe-kanban-metod-maksimalno-korotko/, чтобы получить первое представление.
В Яндекс.Музыке есть годный подкаст Kanban Talks.
Везде засветился тот же Пименов, но это не удивительно, он один из главных евангелистов канбана в России.
Если есть много времени и хочется углубиться больше, то книга создателя канбана Дэвида Андерсена "Альтернативный Путь в Аджайл", хотя она уже довольно устарела.
И, конечно, ссылка от товарища Apathetic.
Тут надо отметить, что информация о канбане от ресурса к ресурсу разнится. Это связано с тем, что канбан очень живой и постоянно эволюционирует. А в русском сегменте это усугубляется часто неправильными переводами и, следовательно, неверным пониманием некоторых моментов