Comments 58
Спасибо большое, очень внятный текст, наконец-то стала проясняться разница между Scrum и Agile (пойду обновлю резюме :).
Надеюсь, в комментариях будут представлены оппозиционные точки зрения.
Спасибо, очень интересный разбор.
Справедливости ради, заголовок несколько провокационный, и если прочитать и полностью принять текст, то сильных противоречий между Agile и кастомными вариантами scrum нет (ну, если вы не ставите целью обязательно называть его Scrum Framework) - вы можете адаптировать их.
Справедливо. Если инициатива по модификации произошла от разработчиков, и направлена на улучшение качества кода, то это действительно в духе Agile. Если же модификация произошла от руководства, и внедряет темные практики, тут мы начинаем встречать проблематику, которая описана в статье (Dark Scrum).
Принципы agile очень разумными выглядят.
А вот идею спринтов я вообще не могу принять. Даже название неверное - типа бежим стометровку и как только пересекли финишную черту начинается вторая стометровка?
Вот проходит неделя спринта и я почему-то должен делать задачу номер 12 а не 23 просто потому что ее положили в спринт а 23 не положили, хотя у меня возникла идея по поводу задачи 23 и сейчас я ее сделаю за день а задачу 12 - за неделю, потому что не хочу ей заниматься прямо сейчас.
Релизы - гораздо более разумные чекпоинты. Хотя бы понятно, что ты делаешь задачу не потому что просто менеджер выбрал что-то рандомное а потому что задачу пообещали какому-то клиенту выпустить в конкретный срок и результат работы над релизом - это новая версия продукта а не просто закрытые задачи в жире.
вроде на планировании следующего спринта именно такие вопросы и задаются.
Конечно, всегда есть место самодурам ("вы - программисты, вы всего лишь исполняете, вам планировать нельзя"), но тогда скорее всего - стоит обновить своё резюме ...
Идея проста, бежим 100 метровку по определенной дороге, и никто не должен вам на эту дорогу добавлять препятствий или ям. Вы заранее видите весь участок в 2 недели. Не должно быть такого, чтобы вам в спринт постоянно прилетали новые задачи, которые двигают все остальные. Если у вас и бывает очень много багов с прода, то спринт планируется с запасом времени под такие баги. Условно у вас забито 8 дней задачами и 2 дня под возможные баги с прода. Если вы выполнили все задачи из спринта, то это никогда не означает что оставшееся время вы ничего не делаете.
А что за работа такая где вы сами определяете что бизнесу нужно прямо сейчас? То есть как это вы решили что бизнесу задача 23 важнее чем задача 12? Ну ок, если есть какие то мысли по поводу задачи 23, ну пометьте себе в todo и продолжайте задачу 12. Как правило спринт имеет цель, которая согласована с продукт оунером. И он ожидает что вы сделаете задачу 12, и на демо покажите именно ее, а не задачу 23. Согласитесь было бы странно, если бы он пришел посмотреть на задачу 12, а вы ему говорите что у вас там была идея и вы сделали задачу 23 вместо задачи 12. Если ваша идея позволит вам сделать задачу 23 за 1 день, то какая разница, сегодня это или через неделю?
С релизами не всегда все однозначно. Какие то задачи могут уходить в релиз по готовности, а какие то с фичатогл флагами. Одна большая фича может по частям добавляться в релизы, а доступной для всех пользователей она может стать намного позже. И нет смысла ждать окончания спринта, если задача уже сделана, и ничего не мешает отдать ее в прод. Релизы это не всегда конец спринта.
Если бы программисты были бездушными искусственными интеллектами то да, назначил любые задачи - всё переварят.
В реальности производительность программиста может меняться в десятки раз если не сотни раз в зависимости от того, в каком порядке и какую работу он делает. Сейчас я задачу 23 сделаю за час а через месяц - за неделю. Зачем мне надо ждать планирования, вместо того, чтобы сделать задачу 23 прямо сейчас? Она лежит в беклоге, на неё есть постановка, она точно нужна бизнесу и она точно так же как и задача 12 должна быть сделана к релизу, который будет через месяц. Почему бы не оптимизировать и не сделать задачи в том порядке, в котором я сделаю их быстрее?
Я совсем вас не понял. Вы задачу оцениваете перед тем как ее делать? Как может быть такое что, сейчас вы задачу оценили в 1 час, а через месяц вы оцените эту же задачу в 7 дней? Разработчики всегда оценивают задачи с учетом какого то запаса времени, но это не 7 дней к задаче на 1 час. Именно поэтому многие уходят от оценки по времени, в оценку в сторипоинтах. Именно поэтому есть такие встречи как скрам покер.
Задача в беклоге уже лежит оцененная. Мы берем в спринт задачи которые точно успеем сделать. Если вы способны вырабатывать в спринт 40 часов, то никто не возьмет на вас задач на 80 часов. Если вы не успеваете в ваши же оценки, то это лично ваша проблема. Это говорит о том что у вас какая то проблема с оценкой. Оценили задачу в 1 час, то и сделайте ее в 1 час. Сегодня или завтра, или через месяц.
Помимо этой задачи в беклоге есть еще 100500 задач. И все они нужны бизнесу, иначе их бы не было в беклоге. И приоритет задач не может управляться желанием исполнителей, иначе мы получим ситуацию где все делают только то что хотят делать, а то что нужно бизнесу будет сдвигаться на потом по различным причинам. Парадокс, бизнес платит зарплату, за то что разработчики делают то что они хотят делать прямо сейчас, а не то что нужно бизнесу прямо сейчас.
Я не про оценки говорю а про реальное время работы над задачей. Пример - я сейчас закончил какую-то похожую задачу, у меня настроено окружение, готовы данные, запущены все нужные сервисы локально чтобы сделать задачу 23. И я сам нахожусь в контексте, весь код у меня прямо в голове в быстрой памяти. Надо только потратить час на написание кода.
А через неделю мне придется потратить день на подготовку окружения, день я буду сидеть и ничего не делать злой, из-за того, что мне пришлось опять всё готовить хотя я мог бы сделать раньше. день надо потратить на то, чтобы все вспомнить и после этого я еще 2 дня буду писать код.
Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего.
Есть очень редкие исключения, когда надо срочно сделать что-то, чтобы получить какой-то большой контракт например. В таких случаях имеет смысл потратить неделю сейчас и получить контракт, чем затратить час когда-нибудь потом и контракт не получить. Но если таким руководство будет злоупотреблять, то в сумме за полгода будет не сделано ничего.
"Бизнесу на самом деле наплевать, когда будет сделана задача 12 а когда задача 23, главное чтобы в сумме за полгода было сделано более-менее много всего."
Это совсем не так. То есть ну просто СОВСЕМ не так. Каждая задача происходит от какого-то бизнес-проекта. Что-то обещано уже существующим клиентам, что-то нужно для новых, что-то - чтобы выполнить всевозможные требования или законы... Зависит от бизнеса, конечно. Но даже если речь идет просто о развитии продукта, то на выполнение задач в определенное время может быть завязано очень много чего - связи с другими компонентами, тестирование, документация...
А что касается переключений контекста... При планировании спринта эти соображения вполне нужно высказать, и совершенно нормально (если только не зверский цейтнот) включить задачу в спринт именно потому, что уже делается что-то близкое. Но вообще меня как руководителя весьма заинтересовало бы, почему на переключение окружения нужен целый день. Ну а про два дня на "буду сидеть злой" и "буду вспоминать" даже как-то и говорить неловко. Но да, переключение контекстов не бесплатно, и при планировании спринта это обычно по возможности стараются учитывать.
Чтобы клиенту доставить к определенному сроку фичу есть механизм релизов. Я же написал, что релизы я понимаю. Я не понимаю, почему я должен обязательно делать какую-то задачу просто потому что ее положили в спринт и больше нипочему. А более того, почему я не могу сделать задачу, которую не положили в спринт, при условии, что спринтовую я всё-равно успею сделать.
Ну потому что задачу не просто положили в спринт, а весьма осознано и обдумано положили именно в этот спринт а не какой-то другой. Задача команды сперва убрать все риски по провалу спринта, а потом уже делать все остальное. Ваше условие, что спринтовую вы все ровно успеете, оно имеет какую то вероятность. И никто не хочет рисковать, чтобы потом на ретро не рассказывать, о том что вы рискнули, но не получилось, и поэтому спринт провален.
Вот такие оценки - что задача займет час независимо от того, сейчас, через неделю или через полгода её делают - это вообще величайшее заблуждение менеджеров.
Поясните, что влияет на вашу оценку задачи сегодня, и через неделю? Я понимаю когда за полгода в проекте поменяется кодовая база и потребуется переоценка некоторых задач. Но даже эта переоценка не поменяется ведь у вас через неделю? Вы что, разное время задачи указываете с поправкой на то, что вы злой будете, или не будете? То что вы про контекст подготовки и переключения написали, это должно учитываться в оценке изначально.
Как вы с коллегами работаете в команде? Допустим вы оценили задачу в 8 часов, а ваш коллега оценивает эту же задачу в 4 часа. Что после этого происходит?
То что вы говорите, о том что бизнесу неважно время доставки фич, это не так. Бизнесу очень важно время появления той или иной фичи в продукте, я бы даже сказал жизненно важно, потому что рынок решает. Представьте что у вашего конкурента вышел релиз с новой важной фичей, а у вас аналогичная фича появится примерно где то в сумме в пол года в вперемешку со всем остальным. Вы не боитесь что за эти пол года ваши клиенты уйдут к вашему конкуренту из-за как раз той самой новой фичи, которая у него уже есть, а у вас появится непонятно когда? Выбирать приоритеты задач это на самом деле отдельное искусство. И можно очень сильно с этим накосячить или наоборот очень сильно преуспеть.
Обычная оценка довольно большая и учитывает то, что нужно время, чтобы погрузиться в задачу, но есть много вариантов, как это время можно сильно сократить. Например починить 5 однотипных багов подряд займет не намного больше времени, чем 2. Или можно взять задачу в работу, понять задачу и отложить ее, пока в голову не придет хорошая идея и начать делать другую задачу.
Задачу обычно берет тот разработчик, которому меньше всего придется разбираться с чем-то и большую часть времени он потратит именно на написание кода.
По поводу сроков доставки задач вот тут есть трейдофф. Можно либо сделать большую пропускную способность либо маленьку задержку при выполнении задач. Я считаю что надо в первую очередь обеспечивать высокую пропускную способность и свести к минимуму вот такие случаи, что надо что-то срочно сделать чтоб через 2 недели было готово. Но даже в таких случаях спринты ну никак не помогут.
Вот допустим чтобы сделать фичу надо чтобы C++ разработчик потратил 3-5 дней, после python-разработчик 5-10 дней а потом frontend - 2-4 дня. На мой взгляд тут следует выбрать более-менее надежных исполнителей, собрать всех троих вместе, объяснить важность выполнения срока и сказать, чтобы каждый следующий приступал к работе сразу после того, как закончит предыдущий. Да, в этом случаи какие-то другие задачи могут отодвинуться, зато успеем к сроку. И 2 недельные интервалы никак не помогут при планировании.
Так ведь вы сами, вместе с командой и оцениваете задачи. Не менеджеры. И вы же принимаете участие в обсуждениях какие задачи брать в следующий спринт, а какие пока просто положить, оставить в product backlog
Я думаю в названии отражается стремление к итеративности и фрагментации фич.
То есть мы не пытаемся бежать марафон, потому что не знаем, куда на самом деле бежать.
Поэтому мы пробегаем дистанцию пошустрее, останавливаемся и оцениваем, куда прибежали и куда нужно бежать дальше.
Справедливости ради есть случаи когда спринт может быть не оптимален - может быть одна крупная фича, которую крайне сложно оценить без реализации всех компонентов.
Соответственно пытаться уложить ее в пайплайн со спринтами - значит получить просто несколько неоптимальных недофич, которые ничего не покажут, но понести все издержки реализации промежуточных решений - промежуточные настройки, тестирование, взаимодействие компонентов, которые будут выкинуты в корзину после полной реализации.
Соответсвенно спринты могут не подходить для некоторых стадий разработки, но хорошо подходят для регулярной работы по улучшению функциональности.
Впрочем аджайл то сам по себе не требует спринтов, он просит сосредоточиться на доставке качественного продукта.
Не очень понятен ваш тезис про задачу 12 и 23. Смысл не в том, чтобы разработчик кодил быстрее, а в том чтобы в работу шли важные и приоритетные задачи для клиента. Не надо брать задачу 23,возьмите задачу 12,т.к. она для продукта важнее. И при хорошем owner это может быть как техническая, так и бизнесовая, если диалог у команды разработки и owner встроен адекватно.
А мне не понятно, что тут может быть непонятно :) Если дать разработчикам чуть больше свободы в выборе задач, то скорость работы программистов вырастет в несколько раз (а расходы на зарплату сократятся, так как нужно будет меньше людей). Я не говорю, что они будут пилить ненужные фичи, они будут брать бизнес задачи из беклога или задачи на улучшение и рефакторинг кода, просто в том порядке, в котором им этого хочется.
Для того чтобы доставить задачу клиенту к определенному сроку есть релизы и апдейты, спринты вообще там не причем.
Хорошо жить в иллюзорном мире, где все просто, как у ребенка. Вот это хочу и буду делать, а остальные пусть подождут.
Простой пример из реальной жизни. Компания задумала акцию к новому году, закупилась товарами, разработала и подготовила рекламную компанию, в том числе на ТВ, но на сайте программисты так и не сделали нормальную работу с этой акцией, потому что другая задача показалась им «важнее именно сейчас». В итоге убытки в миллионы рублей :)
Идея спринтов чётко завязана на процессы CI/CD, на постоянную и регулярную доставку ценностей заказчику в краткие сроки для получения обратной связи и как следствие быстрой реакции если что-то идёт не так.
Релизов, мейлстоунов этот подход не отменяет.
Гибкости при принятии задач в работу тоже.
И кстати, в противовес мнению автора статьи, рефакторинг тоже не отменяет. А наоборот утверждает что 15-20% спринта, вынь да полож на техдолг.
Спринты не нужны.
Зачастую, релизы тоже не нужны.
Смысл спринтов в воспроизведении и постоянном улучшении одной и той же рутины. Поэтому спринты всегда одной длины и все церемонии регулярны - чтобы оттачивать действия команды. В идеале - самонастраивающийся конвейер.
Лично у меня на конвейере производительность будет нулевая - я сдуюсь через час из-за "рутины". При этом с релизами и дедлайнами у меня работать получается достаточно неплохо.
Для менеджеров конечно удобно считать, что команда - это конвейерные рабочие.
Т.е. вы предпочитаете переработку, героическое превозмогание, простои из-за несогласованности и прочую драму хорошо отлаженному процессу?
Я не утверждал, что не надо настраивать процессы, я написал только, что не вижу смысла в двухнедельных спринтах. Вообще я за порядок, но считаю что порядок должен быть в первую очередь в коде и в истории гита.
К тому же когда интересную творческую работу свели к "рутине" на "конвейере" - это на мой взгляд как раз плохой процесс.
Регулярных переработок быть не должно, но иногда приложить максимальные усилия чтобы получить результат просто необходимо, пусть даже придется задержаться или поработать в выходной.
А разве Sprint Retrospective не является тем самым "Люди и взаимодействие важнее процессов и инструментов" ? Ведь как раз на этой встрече и нужно поднять вопрос о том как люди взаимодействовали, какие инструменты нужны или не нужны. Именно тут надо все это выяснять и фиксировать.
Допустим команда решила что общается в slack, но один из людей будет постоянно общаться со всеми в telegram. Он же не может ссылаться на то что у нас Agile и люди и взаимодействие важнее процессов и инструментов?
В современном мире практически у каждой компании свое понимание scrum,agile,kanban
Мне кажется, нет такой компании, которая строго следует какому-либо манифесту/методологии и люди всегда меняют под себя
Плохо ли это ? На мой взгляд нет: идеи не умерли, а стали развиваться и превращаться, наследуя от родителя какие либо признаки, но добавляя что-то свое
Да! И это замечательно. Проблемы начинаются, когда людям не дают сформировать свое понимание, и используют методологию как инструмент повышения эффективности, а не средство к достижению лучшего продукта.
Даже слово "Agile" изначально задумывалось как "прилагательное", можно было сделать что угодно "угловатым". Этим подчеркивалось, что Agile - это не что то конкретное, это просто принципы (как KISS, например), и каждый мог по своему их внедрять под свои нужды.
Интересная статья, спасибо!
Пойду покажу коллегам, как оно бывает :)
Практически со всем согласен, особенно с итоговыми выводами, хотя я занимаюсь не чистым IT, а комплексной разработкой электронных устройств проблемы те же.
Огромная проблема - взаимодействие с заказчиком. Большинство любят работать по схеме - сдал рамочное ТЗ и забыл...
Считая что я должен на 100% угадать его затаённые желания, о которых он сам на этапе составления договора не подозревает!
Хорошая статья, полезно иногда напоминать историю. Вот только с посылом противопоставления программистов, которые дескать знают как код писать, если им не мешать и бизнеса, который ничего не знает, я не согласен.
Програмисты пишут то, что бизнесу нужно. Когда хотелок много, какие-то приоритеты уползают, какие-то детали теряются в процессе формализации задачи. Картина мира и понимание важности каждой фичи в глазах разрабов отличается от картины мира в голове продакта и так далее.
В идеальном мире, разрабы и бизнес могли бы друг друга понимать и синхронизироваться, в реальности так почти никогда не бывает, и нужны доп костыли чтоб хоть как-то доковылять до финиша. И мерам мастера в различных ипостасях это как раз один из костылей, точнее способ удержать разрабов, которые не всегда понимают зачем они что-то делают от растекания мыслью.
Цитата: Она предоставляет услуги по внедрению и курированию Scum для компаний и является единоличным владельцем прав на торговую марку Scrum.
Опечатка по Фрейду?
С посылом согласна на 100%. Но есть грубые неточности, которые режут глаз.
Agile это не методология, это именно что набор ценностей и принципов. Можно называть философия, но не методология.
Dark Scrum автор называет именно неудавшийся Scrum. Не Agile. Ещё есть названия типа ScrumBut, или по-русски СкрамНо. Это и правда "отступление" от скрам гайда.
Тут как раз скрам мастер или другой опытный пользователь методологий, объединяющихся под Agile, скажет, что юной и неопытной в Agile подходах команде в первый раз нужно научиться работать по типовому фреймворку/методологии, по её четким правилам.
Когда команда уже понимает, что ценности и принципы у них работают и как работают - вот тут можно крутить/вертеть процессы на своём опыте, опираясь на Agile. Без стартового опыта эксперименты будут дольше и болезненнее как для команды, так и для продукта и для бизнеса.
И самое болезненное для меня, душнилы этого вечера, Scrum - продукт 2х авторов ещё 90х годов прошлого века, которые обоснованно ввели роль Scrum master в своем гайде. Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников). Кен например сейчас в Scrum.org состоит. Альянс только сертифицирует людей по гайду.
Я к тому, что посыл отличный и как действующий тестировщик и практикующий Scrum master согласна. Было бы круто, если бы аргументы проверялись на точность.
Спасибо за отзыв!
Действительно, Agile - это не методология, тем не менее, во многих источниках (Википедия, например) ее называют гибкой методологией разработки. Но я лично считаю по другому. Поэтому описывая историю Agile я написал, что Agile - это скорее парадигма, цитата:
Agile представил принципы, которые должны были стать основой для будущих методологий. Даже не так, эти принципы должны были стать парадигмой, которую можно внедрить в любую методологию, чтобы она стала гибкой.
По поводу неопытной команды, согласен. Но я постарался осветить проблемы применения Agile в общем плане, а не для начинающих.
Если команде подходит Scrum - пожалуйста! Статья направлена не на критику Scrum. Я лишь говорю, что если вам пытаются навязать Scrum сверху, когда у вас он не работает, или работает плохо, это не Agile. Scrum — это инструмент, а не панацея.
Они не входят сейчас в сам альянс (на сколько мне известно из открытых источников).
Я ничего не говорил по поводу того, входят ли сейчас оригинальные основатели компании в нее. Исторический экскурс рассказывал только про создание Scrum Framework (Scrum).
Подходит agile\scrum команде или нет, определяется не командой, а теми задачами, которая эта команда решает. Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum, а в том, что команда как то не так его использует или под видом scrum практикует нечто другое. Так что если сверху для решения этой проблемы спускают не просто директивы, а скрам-мастеров и обязательные тренинги, это не противоречит agile.
Отсюда же растут ноги у другого вашего противоречия. Скрам-мастер это не человек, это роль. То что на первых этапах внедрения scrum это отдельный, часто сторонний человек, ничего не меняет и ничему не противоречит.
Waterflow это не ругательство, а подход к разработке для задач, решения которых хорошо известны.
Ну что же вы сразу так про Waterflow, никто ничего плохого про него не писал :)
Не важно сверху внедряется scrum или нет, но если он в принципе должен работать для решаемых задач, но не работает, значит проблема, видимо, не в самом scrum
Вполне может быть что именно в Scrum. Я уже писал, что Scrum - не панацея, а инструмент. У нас кажется конфликт интересов. Вы как Scrum мастер не хотите увидеть другую сторону и посмотреть шире. В статье я писал про Agile, а не про Scrum.
Топик статьи - отделение организации труда от работника. А вы пытаетесь свести его к тому, нужны ли Scrum мастера.
Не панацея, не важно agile вообще или scrum в частности имеется ввиду. Гибкие методологии стоит применять только для решения определённых типов задач, а именно для таких, решения которых ещё не наработаны, отсутствуют Best practise, но в то же время это уже не хаос.
Если scrum применяется неверно или agile применяется там, где он не нужен, или даже вреден, это не проблемы методологии, принципов, фреймворков итд. Это проблемы именно применения, неправильного позиционирования себя, своих решений, своих задач.
Вы же отталкиваетесь от команд, организаций, а не от задач. И видите противоречия там где их нет.
Вот начиная с "прожарки", все видимые вами противоречия на самом деле не в самом agile, а в том что вы сами игнорируете границы его применимости.
PS я простой разработчик
"Простой разработчик", который знает методологию Киневин))) Ну-ну))
У меня тоже по статье сомнения о точке отправки. Я как раз писала про применение Scrum в зрелых и не зрелых командах. И вы подмечаете про типы задач.
Я была удивлена, когда мой знакомый в каком-то бородатом 2013 или 2015 году (не помню год, к сожалению), сказал, что он Коуч, который помогает Камазу по Agile проекты делать. Я прям тогда сильно не поняла - зачем заводу гибкие подходы. Теперь знаю, что в разные этапы работы компании нужны разные инструменты и если вы "завод", то при внедрении новинок можно их и по Agile внедрять/разрабатывать
ок
Имхо вредная статья
В скрам-гайде есть про принцип сюхари. Автор находясь на этапе СЮ, ещё сам не разобравшись, не научившись правильно понимать scrum, позиционирует себя в РИ
Вопрос к практикующим(!): как Scrum или Kanban управляются с разветвленными зависимостями задач?
"Причина, собственно, одна: подобно Копенгагенской интерпретации квантовой механики Agile хорошо отвечал на вопрос "что делать", но не отвечал на вопрос "как делать". Данные упущения постарались исправить Scrum и Kanban."
Agile пригоден в условиях неопределённости. Если вы не знаете, как сделать в ваших условиях, никто не скажет вам "как" делать
"Компания Scrum Alliance имеет программу выпуска сертифицированных Scrum мастеров (Certified Scrum Master, CSM). Она предоставляет услуги по внедрению и курированию Scrum для компаний и является единоличным владельцем прав на торговую марку Scrum."
А как насчёт Scrum.org? И здравого смысла?)
"Спринт представляет собой набор задач (Sprint Backlog) из продуктового беклога, в процессе спринта набор задач изменять нельзя"
Цель изменить нельзя, задачи можно.
Именно поэтому метрика %выполнения спринта - бесполезная метрика
"В конце спринта, на отдельном совещании вы обсуждаете результаты спринта (Sprint Review), где обсуждаете результаты спринта. Удалось ли достичь цели спринта? Что поменялось во время работы над спринтом? Это обсуждение ограничено четырьмя часами, не является презентаций, а скорее активным обсуждением."
Основная цель Sprint Review - не пообсуждать, а получить обратную связь по дельте разработки
"Developers — это разработчики, которые выполняют задачи спринта."
Только задачи спринта выполняют?)
"Владелец продукта (Product Owner), который манипулирует приоритетом задач в продуктовом беклоге и является звеном между бизнесом и разработкой. Владелец продукта должен устанавливать Product Goal — долгосрочную цель по улучшению проекта. Он не участвует в ежедневном Scrum."
Манипулирует - не самое лучшее слово. В дейлике участвовать ему никто не запрещает
"Задачи оцениваются не в человеко-часах, а в некоторых абстрактных сторипоинтах (Story Points). Один сторипоинт представляет собой сложность некоторой тривиальной задачи, или самой простой задачи в спринте. Далее, все остальные задачи оцениваются как число сторипоинтов относительно этой тривиальной задачи."
Этого в скрам-гайде нет ;)
"Родоначальником методологии Kanban можно считать компанию Toyota."
Канбан-метод и канбан в тайоте - это разные канбаны. И официально, Канбан-метод - это не Agile. А альтернативный путь к гибкости)
"Хотя Scrum и Kanban называют разновидностями Agile, в полной мере они ими не являются. Первый пункт манифеста Agile гласит:
Люди и взаимодействие важнее процессов и инструментов"
Scrum и Kanban - конкретные инструменты, не разновидности.
Да, начинать нужно с людей.
Интересный факт, Scrum помогает понять, с кого начать 😅
"Во-первых, само по себе присутствие человека, который не участвует в разработке, но при этом формирует процесс, уже нарушает манифест Agile"
Неверное утверждение. Скрам-мастер не формирует процесс, формирует команда. Скрам-мастер помогает. В идеале при выходе скрам-мастера из команды все процессы должны остаться действующими и стабильными. Потому что они управляются командой, а не скрам-мастером.
"Увольте вашего Scrum-мастера, откажитесь от идеи Scrum и дайте разработчикам самим организовать процесс"
Интроверты-программисты уткнулись в свои компы и привет организованный процесс
Вообще говоря, наверно, у нас эта схема и сработала. В скрам-мастера я вышла, будучи разработчиком😂
Стоит посмотреть на тезисы статьи с другой стороны.
Одно дело, когда менеджмент нагоняет Agile, а разработчики не хотят.
Другое дело, когда разработчики хотят, а менеджмент прямо или косвенно против.
Это в статье никак не рассмотрено
Комментарий - золото!
Про неопределенность - самая ценная фраза... ППКС, в это и есть смысл Аджайл и разница с предсказательным подходом который зачем-то называют водопадом. :-) Хотя суть именно в этом - можем уверенно предсказать - то не нужен Аджайл. Не можем - не сработает никакой водопад.
А насчет процесс или люди - они ж не зря приписали сразу же после 4-х пунктов: "мы не отрицаем важности того что справа, но ценим то что слева больше". Как раз видимо предполагая что будут интерпретации манифеста в стиле статьи - противопоставлением людей и взаимодействий процессам и инструментам. :-(
Статья написана про распространенную проблему - о том как “делают Ажайл ради Ажайла”, не понимая ни сути, ни цели. Проблема действительно есть, и проблема действительно легко выявляется простой проверкой применяются ли на самом деле 4 ценности и 12 принципов. Если бы статья этим ограничилась - была бы просто шикарная, полезная статья. И хороший эталонный образец мышления как его хотят от Аджайл команд.
Но с тем что дальше, когда начали жарить… Пережарили. К сожалению Аджайл хорошего кода и не мешания программистам - ничуть не лучше и не ближе к тому что описано в манифесте. Соавтор скрама и один из авторов манифеста, Кен Швайбер в своей книге очень четко сказал про “не мешать”, объясняя смысл тайм-боксов: “ничто так не стимулирует творчество как веревка на шее”.
Люди о которых шла речь и ради которых задумывался аджайл вообще и скрам в частности - не исполнители. Это пользователи. Это именно для них создается работоспособный продукт, это с ними взаимодействие важнее формальных документов, а они сами - важнее красивого процесса. Собственно Швайбер и пошел дальше, развив идеи в EBM - Evidence-Based Management (управление на основе доказательств). Мы работаем ради того, чтобы принести пользу потребителям. Это и есть профессионализм (ага, то самое “скрам-команда должна состоять из мотивированных профессионалов”). И измеряют наш успех не по крутости и чистоте кода. А по удовлетворенности конечного пользователя. В этом плане Аджайл как раз не за красивый код. Слово которое там постоянно - just enough. То код ровно настолько хороший, чтобы принести требуемую пользу. И ни граммом больше.
Ну а в остальном выше правильно сказали - и про Shu-Ha-Ru, принцип привнесенный в Agile еще одним подписантом - Алистером Коберном. О том что конкретная техника не цель, а отправная точка. И да, глупость считать ее целью. Но не меньшая глупость начинать сразу с изобретения велосипеда. Впрочем, те же PMI в Disciplined Agile не просто так постоянно повторяют что их плейбук - это начальная точка, а не цель :-) Видно наелись.
Ну и в комментарии выше - есть самая ценная фраза, но боюсь большинство ее пропустило. Аджайл о том когда непонятно. По науке - когда мы столкнулись со сложной системой, которую не способны понять и предсказать своим ограниченным умом. Именно поставка результата, при минимизации потерь, в условиях когда предсказать нельзя - и есть цель. Если смотреть на это так - станет понятнее многое. От принципа “… через ЧАСТУЮ поставку” (потому что поставка - это ЕДИНСТВЕННАЯ возможность проверить свои предположения) до принципа спринтов - коротких, эффективных и контролируемых экспериментов по проверке гипотез. И оно конечно подход DevOps с ежедневной и даже несколько раз в день поставкой - еще лучше чем спринт, но давайте будем честными - для большинства программистов даже раз в месяц - уже болезненно. Поэтому месяц - хорошая отправная точка. Быстрее всегда лучше будет, но пусть для начала раз в месяц сделают.
Как-то так. И да, я знаю что интерпретация Аджайла в статье греет душу, а то что написал я - с точностью до наоборот. Но если рыть в то что на самом деле писали и говорили те, кто подписал манифест - как-то так оно и выходит. Такие дела.
Вспомнилась шутка про:
"АГИЛ - запрещённая на территории РФ организация"
Что прям "шоркнуло". "дайте разработчикам самим организовать процесс" - как показывает практика, такие команды месяцами пилят релиз и ничего не выводят. Такая команда строит комфортный для себя процесс, не ориентируясь на требования бизнеса.
А автор понимает разницу между производственным Канбан родом из Тойоты и Канбан-методом авторства Андерсона? А то кажется что смешались люди и кони.
У вас не Agile