Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которых мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.
Зачем мы используем скрам?
Сферический разработчик в вакууме (а именно к этой фигуре стремится инженер, которого не таскают на митинги) не требует сложных методик. Обычно этот человек просто выполняет рабочие задачи, зачастую даже выполняет их хорошо, а иногда проявляет инициативу и думает на несколько уровней выше и ниже своих задач.
Однако когда инженеров накапливается много, встает задача ими управлять, распределять работу, и как-то следить, что она выполняется в срок. Чем больше и сложнее задачи, тем больше сил уходит на организацию, и тем сложнее выстроить коммуникации в команде.
На помощь приходит скрам - серебрянная пуля всех методик, волшебная таблетка всех процессов. От мала до велика - все работают по скраму - и стартап, и мегакорпорация. И это не удивительно - за пару десятилетий подход превратился в золотой стандарт индустрии, отход от коротого обсуждают презрительным шепотом.
Но почему же я раз за разом, в одном проекте за другим, вижу одинаковые проблемы? Эти проблемы были десять лет назад, есть и сейчас. И кажется, мы их вот-вот решим, стоит только сильно захотеть...
Разделяй сейчас, властвовать переносим в другой спринт
Сколько раз вы слышали подобное:
Эта задача не умещается в спринт, поэтому нужно разделить ее на две.
Не знаю как вы, но я встречал эту практику в 10/10 компаний где я работал, где был внедрен скрам. Казалось бы, что в этом плохого?
Концепция разбиения задач на атомарные части проста, но умна в то же время: разбивайте задачу на части до тех пор, пока части не будут так малы, что их нельзя больше разбить. А раз задача настолько мала, значит должно быть очевидно, как ее делать, и сколько времени это займет, так?
Так, но с одной оговоркой: это работает для задач, где мы точно знаем, что нужно сделать, или хотя бы в какую сторону идти. Чтобы разбить задачу на части, нужно для начала понимать, из каких же частей она состоит. А это само по себе требует некоторых знаний о задаче, и часто не самых поверхностных.
Нюанс в том, что под это определение не попадают RnD задачи, то есть задачи, в которых присутствует большая доля неизвестного. Причем часто это не такое неизвестное, которое известно как найти, а неизвестное неизвестное - то есть мы не знаем, что это, и где его искать, но знаем только, что нам оно пока не известно.
RnD задачи не вписываются в спринты
Например, исследование новых технологий, дизайн архитектуры, разработка нового функционала (особенно вкупе с интеграцией) - это задачи, где всплывает множество неизвестных неизвестных. Так много, что их просто невозможно оценить заранее - задачу можно выполнить за день, "случайно наткнувшись" на решение проблемы, а можно две недели изучать документацию, проводить эксперименты и сидеть в дебаггере, но по-прежнему не найти выход.
Может быть, точная оценка решит проблему неизвестности?
Оценивай, или оценят тебя!
Оценка - ключевая концепция скрама. Каждый спринт строится вокруг оценки задач и наполнения ими спринта. А уж сколько инструментов для оценки у нас есть! И Planning Poker, и Bucket System, и T-Shirt Sizes, и множество других.
Они все разные, но у них есть одно сходство - ни один не предоставляет работающей методики оценки объема задач. Это либо гадание, либо соревнование, либо аукцион "кто назовет меньше". Ни один метод не даст гарантированного хотя бы с 25% погрешностью результата оценки.
А в чем же причина? Неужели разработчики саботируют свою работу? Или метрики не подходят, и нужно изменять не в числах Фибоначи, а в прыжках лягушки? Или размеры футболок нужно корректировать в разных странах?
Нет, дело не в этом. Все дело в том, что мы не умеем оценивать задачи. Нет, не так.
Мы не умеем оценивать задачи!
В индустрии до сих пор нет механизма, позволяющего оценивать RnD задачи с хоть сколько бы то ни было приемлемой погрешностью. И попытки построить на этой недостоверной информации целую систему приводит к одинаковому результату - задача переезжает из спринта в спринт, а скрам мастер все больше и больше теряет терпение.
Может мы просто недостаточно стараемся?
Церемония
Спросите у любого скрам мастера: "Из-за чего возникают подобные проблемы?". Ответ ожидаемо похож - "недостаточное соблюдение церемоний" или "недостаточное внедрение скрам практик".
Что это значит в переводе на разговорный язык? То, что в неправильной оценке задач виновата команда, которая проводит недостаточно refinements, и недостаточно усердно делится переживаниями на ретроспективе. А может, кто-то неправильно стоит на daily standup? Или нужно больше времени тратить на планирование спринта, чтобы уж никто не смог отмазаться от данных оценок!
Ведь по мнению многих скрам мастеров и прочих менеджеров, инженеры - это просто лентяи, которые не способны самостоятельно решать проблемы, поэтому тянут резину и переносят задачи из спринта в спринт. Проблемы может быть две - недостаточная мотивация, или недостаточное разбиение задач. Таким образом любую инженерную задачу можно решить, побив ее на мелкие части, и повысив мотивацию работника.
Что мы имеем в реальности? По 10 часов скрам церемоний в неделю, которые не дают сосредоточиться на выполнении задач, на которых постоянно спрашивают про статус этих задач (хотя статус можно узнать, просто заглянув в Jira). Вместо фокуса на работе, мы занимаемся "дрессировкой джиры", коллективно тренируемся разделять задачи, которые не влезают в спринт, и тыкать пальцем в небо с умным видом, когда нас спрашивают об оценке.
Мотивации и церемоний недостаточно, чтобы решать задачи.
Иногда может потребоваться работать.
Весь процесс скрама в RnD команде превращается в попытки натянуть рабочий процесс на методологию, которая ничего общего с ним не имеет. При этом сотрудники находятся под постоянным давлением из-за того, что задачи не ложатся идеально на спринты, и приходится либо отрезать кончики, либо докладывать. С другой стороны, они чуствуют себя перманентно виноватыми в том, что их оценки не сбываются, а значит они подводят команду и руководителя.
Но это еще не все.
Скрам - новый Ватерфол
Доводилось ли вам работать в крупной международной компании? Слышали ли вы про SAFe? Держали ли в руках книгу на 100 страниц про процессы жизненного цикла software в компании?
Если да, я вас поздравляю - ваша компания купилась на аферу под названием "аджайл для взрослых"! А именно, жесткие и сложные методологии под эгидой "гибкости" и "легкости".
Что такое аджайл? Откройте Agile Manifesto. Вы удивитесь, насколько мало общего такие вещи, как SAFe, имеют с этим документом. Мне не сложно включить его прямо в статью:
Люди и взаимодействие важнее процессов и инструментов
Работающий продукт важнее исчерпывающей документации
Сотрудничество с заказчиком важнее согласования условий контракта
Готовность к изменениям важнее следования первоначальному плану
Однако ловкие продавцы церемоний усвоили только часть:
процесс важнее всего
документация не нужна
плохой план можно исправить итеративностью
бумажка превыше всего
В итоге мы получили все, против чего боролись авторы agile manifesto - жесткие фиксированные сроки, запланированный объем работ для каждой фазы, давящие кросс-командные планирования, загоняющие команды в жесткие рамки и лишая гибкости коллаборации, а также большое количество бюрократии и бумагомарания.
Но ведь это аджайл, верно? Мы же продаем компании гибкость! А как этого добиться?
Легко! Возьмите классический waterwall, теперь разбейте фазу реализации на двухнедельные отрезки, добавьте церемоний (не важно, подходят ли они процессу или нет), и заставьте разбивать задачи на атомы! Скажите клиенту, что это делается во благо обратной связи, и не забудьте выписать счет!
SAFe это совсем не ватерфол, ну вот ни разу!
Продавец скрама, аджайл-коуч, бизнес-тренер
В итоге мы получили поголовное помешательство на скраме под соусом "гибких методологий". Однако скрам давно перестал хоть отдаленно напоминать исходную идею, и оброс огромным слоем корпоративного мусора, сертификаций и мастер-классов.
В итоге применение скрама к таким задачам превращается в бюрократический цирк, в котором никому не до смеха.
Все кончено?
На самом деле нет. Есть надежда.
К счастью, аджайл не ограничивается скрамом. Даже наоборот, скрам несмотря на все старания не смог убить хорошую идею в основе гибкого подхода.
Для RnD существуют более подходящие методологии - например, Kanban. Практика не требует четких оценок, которые сложно дать в условиях высокой неизвестности или новизны. К тому же, Kanban не привязывает задачи к синтетическим временным контейнерам, позволяя выполнять задачи в той мере, в которой они этого требуют - иногда один день, а иногда и целый месяц.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
Есть другие практики, который подходят к разным ситуациям и разным командам. Однако спустя годы я пришел к иному выводу.
Аджайл предоставляет большое количество методик, но всего лишь несколько ключевых идей. Подбирайте практики, которые позволят вам реализовать эти идеи в вашем конкретном процессе. Нравится парное программирование - никто не мешает вам внедрить его на постоянной основе. Хочется оценивать задачи по факту выполнения - вы вольны сделать это.
Начните с Agile Manifesto. Экспериментируйте. Стройте свой уникальный процесс.
Гибкость также и в том, чтобы быть гибким в выборе методик и их применении. Многие команды экспериментируют с технологиями и инструментами. Не бойтесь подвергать экспериментам и аджайл - тем более, что это не требует расходов на лицензию.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Такая работа идеально ложится на скрам - задачи легко оценить, они обычно невелики, а работа заключается в поиске и исправлении ошибок, либо мелких доработках. Идеально для скрам! Только не забывайте приносить часть рабочих часов в жертву своему мастеру, иначе это не будет работать.
Утешительные Итоги
Если прочитав статью, вы узнали себя - не стоит вешать нос! Хоть скрам и является карго-культом, он все-таки худо-бедно работает, а значит помогает решать задачи. По крайней мере это позволяет бизнесам двигаться вперед, а значит у вас и завтра будет работа.
Но если вы стоите перед задачей построения гибкого процесса разработки - не слушайте тех, кто громче всех кричит. Вернитесь к истокам agile, и выберите то, что будет работать лучше всего для вас. И если это будет скрам - примите это решение осознанно!
P.S.: спасибо за комментарии, мне приятно их читать и отвечать. Хочу добавить:
Скрам сам по себе хорошая, целостная и продуманная методология, и наверняка есть те, кто освоил ее в совершенстве. Однако я не встречал таких проектов, работая и в малых, и в огромных компаниях, и в продукте, и в оутсорсе, и в консалтинге. И множество моих знакомых имеет сходный опыт.
Скрам - как коммунизм - в теории элегантен и эффективен, на практике сколько ни пробовали - работает только в Китае, и то с оговорками.
Если концепция хрупкая и неустойчивая, а для ее "правильного" применения нужно очень очень постараться (с чем большинство не справляется) - стоит заключить, что эксплуатационные характеристики не соответсвуют ожиданиям.
Индустрия же пошла своим путем - компании пытаются "накормить" скрамом своих сотрудников, насаждая практики не разобравшись. В итоге имеем то, что в заголовке.
Картинки
Braden Collum
Clark Douglas
Julia Arte
Parabol
Ozan Safak - продавец скрама
Stormseeker - обложка
Комментарии (232)
deseven
12.06.2024 10:19+18Чаще всего проблема не с методологиями, а с людьми, которые эти методологии применяют. Поработал разок с каким-нибудь упоротым менеджером, а потом ходишь рассказываешь про ужасный скрам. Ну, бывает :)
ReaderReader
12.06.2024 10:19+11Когда в руках молоток, весь мир состоит из гвоздей. К сожалению Скрам воспринимается многими как тот самый молоток. Если к этому еще добавить типовое понимание Скрам по принципу "Там есть спринты и оценка эффективности. Любая задача должна быть завершена за один спринт", то на выходе получаем адскую жесть, после которой люди начинают шарахаться от слова Скрам как черт от ладана. Если же к этому добавить, что найти нормального Скрам-мастера еще сложнее чем нормального менеджера проектов, то результат отношения людей к подобной псевдо-Скрам организации процесса абсолютно предсказуем.
Знаю пару особо упоротых случаев, когда дэйлики использовались начальством для штрафов и наказаний. Ведь как удобно, когда народ сам говорит о проблемах: не надо даже искать кого наказывать. Т.е. некий Вася сказал на дейлике, что у него по таким-то причинам затормозилась разработка и все будет реализовано с задержкой в сколько-то дней. Васю немедленно карают, т.к. он по мнению начальства плохо работает. Что в результате думает о Скрам Вася, можно описывать только ненормативной лексикой.
MrNutz
12.06.2024 10:19+5Проблема в том что упоротых менеджеров слишком много. Так и не встретил адекватных. Везде всякие скрамы и аджайлы применяются как попало.
Ушёл в итоге нафиг из большого ИТ и сам себе техдир, строю свое ИТ в небольшой компании.
Okeu
12.06.2024 10:19я сам лишь со стороны поддержки этого всего знаком, но вот со стороны впечатление такое, что менеджеры просто берут либо тот инструмент, которым они умеют пользоваться (типа "всегда работал в скраме, не хочу канбан - там ниче непонятно") либо тот, который именно им удобен. Не смотря на необходимость и/или удобство для команды конкретно этого инструмента
Okeu
12.06.2024 10:19+2да и без всякого скрама, меня лид HR вгонял в ступор, обозначая огромную бесформенную гига-задачу на "подумать" и мгновенным вопросом - сколько тебе нужно времени на нее?
Я долгое время думал, что это со мною что-то не так, и наверное когда-нибудь я научусь их оценивать... (а там, например, на одну только четкую формулировку задачи из этого бесформенного может уйти не одна неделя) И вот я стою, представляю, что это может занять от 1 минуты до бесконечности - и прямо так в лоб и отвечаю - может завтра сделаю, а может через год - не знаю)
Arioch
12.06.2024 10:19+3— Капитан, как скоро вы сможете приземлиться?
— Не могу вам сказать.
— Мне можно, я доктор.
— Я просто этого не знаю.
— А предположить вы не можете?
— Займёт не меньше двух часов.
— Вы так долго будете предполагать?
ReaderReader
12.06.2024 10:19+13А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Простите, но вышенаписанное абсолютно неверно. Скрам создан как противовес водопадной разработке и нужен в первую очередь как раз для задач, когда мы (или заказчики) сами точно не представляем, что именно хотим получить. Когда требования и планы могут меняться каждый месяц. Когда сам заказчик сначала говорит сделать "А", а потом через пару недель приходит и говорит, что они опробовали "А", и лучше переделать его в "Б". Или когда у нас есть 100500 теоретически требуемых фич, а порядок их реализации (и нужна ли реализация вообще) определяется по факту их реального использования в поле. Легкость или сложность оценки задач при этом вообще не важна. Описанное вами является не Скрамом, а, к сожалению, очень типовым случаем, который представляет собой водопадную разработку, завернутую в псевдо-Скрам. В вашем сценарии не имеет никакого значения, будет задача реализована за 2 спринта, или за один, т.к. конечная цель неизменна: реализовать заранее определенный заданный функционал. В такой ситуации Скрам вообще не нужен, т.к. если у нас нет изменений требований в процессе разработки, то нам не требуется Скрам. Если я буду писать софт для управления ядерным реактором, то использовать там Скрам не имеет никакого смысла, т.к. все требования к его функционалу жесточайшим образом уже прописаны на 100500 листах документации, и никаких отклонений изначально не планируется и не допускается. А вот если я буду разрабатывать игру, то Скрам там зайдет просто идеально, т.к. изменение требований может происходить чуть ли не каждую неделю, и ни разработчики, ни сама целевая аудитория заранее не могут 100% быть уверены, что понравится, а что нет.
Color Автор
12.06.2024 10:19+3Когда требования и планы могут меняться каждый месяц...
Вы сейчас описываете не скрам, а аджайл манифесто.
Скрам то изначально и задумывался действительно как противовес ватерфолу и как одну из реализаций идеи гибких методологий. Но со временем вырос в большой корпоративный карго-культ.
ReaderReader
12.06.2024 10:19+3"Scrum is an agile project management framework"
https://www.atlassian.com/agile/scrum
Скрам - это одна из аджайл методик, которых довольно много. Скрам, Канбан, Скрамбан и т.д. А то, что он вырос в карго-культ (как вы абсолютно верно написали), как раз и является причиной всех мучений автора статьи.
ogost
12.06.2024 10:19+1который представляет собой водопадную разработку, завернутую в псевдо-Скрам.
Я всегда думал, что если скинуть всю шелуху, то весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.
ReaderReader
12.06.2024 10:19+1Могу вас одновременно обрадовать огорчить :)
Вы на 100% ошибаетесь, когда понимаете Скрам как "серия коротких (длиною в спринт) вотерфолов "
-
К сожалению 99% "внедрятелей Скрама" именно так его и понимают + дэйлики, которые часто длятся по часу каждый день, где внезапно могут начать решать любые проблемы и т.д. В результате народ совершенно справедливо шарахается от Скрам как черт от ладана.
Проблема на мой взгляд состоит в том, что есть два основных ресурса, связанных со Скрам, которые отвечают на вопрос "как", но абсолютно игнорируют вопросы "в каких случаях?" и "зачем?"
Agile Manifesto
https://agilemanifesto.org/iso/ru/manifesto.html
Собственно документация по Скрам
https://www.scrum.org/Игнорируют они эти вопросы потому, что авторы этих методик прекрасно себе представляли, для решения каких конкретных проблем они создаются, и совершенно не рассчитывали на то, что успех данного подхода в его конкретной нише приведет к настоящему карго-культу, когда Скрам пихают везде и всюду, при этом не имея ни малейшего представления, как он на самом деле должен быть организован, и зачем он нужен.
Дополнительных проблем добавляет то, что другие аджайл методики, не документированы практически никак. Т.е. есть те, кто в теме, и знают, как и когда ими пользоваться, но эти знания передаются исключительно коллегам во время работы. Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности. Между тем имеется целая охапка только наиболее популярных базовых аджайл методик: Scrum, Kanban, Scrumban, Feature-Driven Development (FDD), Extreme Programming (XP)б Dynamic Systems Development Method (DSDM), и еще масса менее известных.
Теперь конкретно про Скрам и ваше заблуждение. Я, разумеется, не могу тут пересказывать всю документацию, но это и не надо. Основной проблемой, которую решает Скрам, является разработка с заданием "Сделай то, не знаю что". Заказчик представляет, что он хочет, в самых общих чертах (хочу программу торговли на бирже, хочу шутер и т.п.), т.к. не имеет опыта, не знает, что понравится его аудитории, как будет работать его персонал, какие конкретно процессы появятся во время и т.д. и т.п. Как эту проблему решает Скрам (очень короткое и поверхностное описание). Мы пилим очень небольшой функционал в течении короткого времени (тот самый спринт) и сразу отдаем его заказчику на обкатку. Заказчик играется с полученной версией и дает отзыв в виде обратной связи, что и как надо поменять, а команда немедленно (уже в следующем спринте) реагирует на этот отзыв. Т.е. имеем список а-ля (просто как пример)Фича A отлично подошла, но там есть пара багов. Вот баг-репорты
Фича B получилась неудобной в использовании, уберите ее. Вместо нее нам срочно нужна фича X, которая ранее была с очень низким приоритетом. С этого момента бросьте все силы на ее разработку, что мы получили фичу X как можно скорее
Фича C в общем неплохая, но там надо поменять вот это и это. Эти изменения важны, но их приоритет ниже чем у фичи X
Понимаете глобальную разницу между отписанным вами "серия коротких (длиною в спринт) вотерфолов" и данным процессом?
Во-первых, если у нас нет нужды менять функционал, и заказчик точно знает, что он хочет получить, что нам не нужен Скрам. Нам необязательно использовать водопад, возможно лучше подойдет другая аджайл техника. Чаще всего это Канбан или Скрамбан (надо смотреть ситуации). Но вот Скрам нам точно не нужен. Более того, даже если мы точно знаем, что функционал будет меняться на ходу, то и здесь Скрам не всегда оптимален. Повторюсь: это конкретный инструмент, созданный для решения конкретной (хотя и достаточно часто встречающейся) проблемы. Если я буду пытаться проделать отверстие в доске при помощи рубанка, это не значит, что рубанок плохой. Это значит, что я - идиот, который использует инструмент не по назначению
Во-вторых нет никакого водопада. Мы не разбиваем один большой отрезок разработки на кучу маленьких, а заказчик видит продукт в самом конце.
В-третьих заказчик принимает участие в разработке наравне с командой. В водопаде мы берем задание и заказчик может идти спать до даты релиза. В Скраме такое в принципе невозможно, т.к. для разработки нужно прямое и постоянное участие заказчика в процессе.
В-четвертых, у нас нет и не может быть сколько-нибудь долгого плана по работе, т.к. никто не знает, что будет разрабатываться даже в следующем спринте, не говоря уже о следующем месяце или квартале. Горизонт планирования - один спринт (обычно 2 недели)
И еще забавный момент. Если спросить "внедрятелей Скрама", какой длины должен быть спринт, то 99% ответов будет: "2 недели". Но если спросить "А почему именно 2 недели? А можно короче или длиннее?", то ответа не будет., т.к. у них нет ни малейшего понимания о вышеописанном процессе. На самом деле ответ очень прост, если знать вышеописанное: по результатам практического использования выяснилось, что 2 недели - наиболее оптимальный срок для заказчика, чтобы обкатать новую функциональность и дать по ней отзыв. Неделя - слишком короткий срок (хотя иногда встречаются проекты, где неделя оптимальна), а 3 недели и тем более 4 - слишком долгий срок без обратной связи, за который можно успеть наворотить массу ненужного заказчику функционала.
Arioch
12.06.2024 10:19+1> что 2 недели - наиболее оптимальный срок для заказчика
...а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Потому что это очень сильный критерий применимости скрама.
абсолютно игнорируют вопросы "в каких случаях?"
Следовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
ReaderReader
12.06.2024 10:19а это где-то описано в "документации, которая есть только у скрам", что длина спринта в первую очередь задаётся необходимой длительностью реальной работы новой версии софта у покупателя?
Не в настолько явном виде. 30 дней прописаны в явном виде, а вот насчет времени для обкатки прописаны в виде "Product Goal". Тут мы опять приходим к тому, что создатели не описывали некоторые очевидные для них вещи. "Product Goal" - заказчик доволен текущей версией продукта. Он доволен, если успел ее обкатать и дать отзыв, что там надо поменять. А для этого ему нужно время и т.д.
https://scrumguides.org/scrum-guide.html#the-sprintСледовательно, если мы не можем гарантировать, что заказчик начнет пользваться новым релизом
немедленно
на реальных или идентичных реальным задачах
то вот и получился критерий "не тот случай"
Именно так. Только под "пользоваться" надо, разумеется, понимать тестовую обкатку с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Arioch
12.06.2024 10:19+1с использованием всего реализованного в последнем спринте, а не выкат каждой версии в боевой прод.
Первое требует второго. Хотя, конечно, второе не гарантирует первого.
"В лабораторных условиях" я и сам могу протестить, мне для этого даже и QA не нужен. А реальные задачи вне боевого не тестируются. У покупателя тоже нет лишних сотрудников, которые будут буквально повторять все реальные задачи обычных сотрудников на отдельном контуре.
...и это я ещё про "плавающие ошибки" не говорю ;-)
ReaderReader
12.06.2024 10:19Первое совершенно не требует второго. Вы путаете тестирование в смысле тестирование на наличие багов и тестирование функционала. Под тестированием в Скрам имеется в виду именно функционал, а не ловля багов. Для тестирования функционала совершенно необязательно выкатывать его в прод. Как в Скрам организуется качество разработки (в смысле отлова багов) - это отдельная большая тема
Arioch
12.06.2024 10:19+1так чтобы понять "удобно или не удобно" - опять же требуется долгосрочная работа по реальному, каждодневному сценарию.
то, что покажется удобным, в течении 5 минут, может оказаться нифига не удобным за 5 часов. То, что кажется удобным при тестировании одной функции, может оказаться неудобно, когда надо выполнять разные функции (в том числе никак не относящиеся к изменённому функционалу).
условно, в качестве фичи для фастфуда выкатили кофе-машину, в которой оператор работает на площадке, на которую надо по лесенке подниматься. Пока оператор тестирует ТОЛЬКО изменения - всё зашибись. А вот как только из тестового контура передеплоим в боевой, где надо продавать не только кофе, - сразу становится плохо. Но в чистой теории, конечно, если покупатель выделит несколько сотрудников которые в full time будут повторять работу других сотрудников и ничего кроме этого - тогда можно и на тестовом. Либо частичный деплой, берём 5% сотрудников покупателя и переключаем их на работу с тестовой сборкой в реальном контуре.
будь оно иначе - не требовалось бы две недели на спринты давать, хватило бы полдня.
ReaderReader
12.06.2024 10:19Мне кажется, у нас есть глобальное недопонимание, т.к. некоторые очевидные для меня вещи, для вас неочевидны :) Разумеется, некоторые версии выкатываются в реальный прод после соответствующих тестов на баги. И если по результатам реального прода будет выявлено, что какая-то уже одобренная фича не подходит, то она снова будет изменена. Проект в Скраме не является чем-то застывшим, в.т.ч и уже одобренный функционал. Абсолютно любой функционал может быть изменен в любой момент, если окажется, что он не устраивает заказчика. Это процесс продолжается до тех пор, пока заказчик не будет удовлетворен результатом и / или пока у него есть время и деньги на разработку.
M_AJ
12.06.2024 10:19+1Ресурсов а-ля как для Скрам для них нет, есть только множество статей на разных сайтах различной степени детальности.
Канбан неплохо описан в книгах по управлению производством, правда там отдельный упор на вытягивающее производство, а это далеко от разработки ПО
ruslan_sverchkov
12.06.2024 10:19+1весь аджайл - это серия коротких (длиною в спринт) вотерфолов. Буду рад ошибаться.
Вы так говорите как будто это что-то плохое)
Batalmv
12.06.2024 10:19+1Ну, если взять только третий принцип, творчески его перефразировать, а остальные 11 выкинуть - то да :)
Но уже наверное доллжно быть понятно, что оставив только 1/12, вы наверное пришли к чему-то другому :)
Gold_fish
12.06.2024 10:19+5Проблема не в методологиях, а в их применении. Если шуруповертом забивать гвозди, то это не шуруповерт плохой, а дурак тот кто взял его в руки. Скрам хорошо ложится на продуктовые компании с плановыми релизами. Но абсолютно не подходит для корпоративных разработок и внедрений где важні сроки и бюджеты. Канбан хорошо подходит для поддержки. А какой нибудь XP для проектов которые прое.... и уже подгорает ж.....
cat-chi
12.06.2024 10:19+18Скрам - это новый ватерфол
Waterfall: *не существует*
Идеологи Agile: всю жизнь воюют с Waterfall
Ненавистники Agile: начинают применять "Waterfall"...Проблема ведь не в скраме. Возможно, проблема в том, что "фасилитаторы встреч" вдруг начали называться "проджект-менеджерами". И внезапно все начали думать, что достаточно прочитать небольшую книжечку, внедрить некоторые ритуалы из неё, и вот оно – управление разработкой! Простое, удобное, осилит даже
обезьяна. Теперь мы называем её скрам-мастером.А может проблема в том, что "настоящие" проектные менеджеры внезапно повымирали и не оставили потомства. Новое поколение же как слепые котята тычутся в булшит-слова "Waterfall", "Agile", "Scrum" и "Kanban". Ни одно из которых не имеет отношения ни к проектному менеджменту, ни к управлению разработкой.
Starl1ght
12.06.2024 10:19+2Когда я это говорил 10 лет назад, мне рассказывали про то, какой плохой водопад и что я ничего не понимаю. Ну, или что надо попробовать и сам все увидишь!
usego
12.06.2024 10:19+4Водопад за 10 лет избавился от своих проблем?
Starl1ght
12.06.2024 10:19+11Я за 10 лет не видел водопада ниразу. Я видел только сектантов, рассказывающих об ужасах водопада, и почему я должен принять именно их религию.
cat-chi
12.06.2024 10:19+4"Водопада" никогда не существовало. Каскадная модель вот прям с момента её первого упоминания в 1956 – это гипотетический антипаттерн, с которым сравнивают все остальные подходы.
Как люди разрабатывали между 1956 и 20...-каким-то, т.е. до появления Agile манифеста и сопутствующих фреймворков?
Вопрос, конечно, интересный. Но ответ на него – НЕ водопад.
Так что да. Думаю, не избавился ;)
Daemonis
12.06.2024 10:19+3"Водопада" никогда не существовало
В молодости работал в аутсорсе. Ко мне приезжал документ с описанием требований к фиче. Я писал дизайн документ, он проходил ревью и утверждение. Потом документ с тест кейсами. Потом писал код.
Если это не водопад, то я даже не знаю... Правда, это было больше 10 лет назад.
cat-chi
12.06.2024 10:19Если это не водопад, то я даже не знаю...
Я, пожалуй, неточно выразился, позвольте чуть уточню.
"Водопада" никогда не существовало как некой целостной "модели управления разработкой ПО, которой все раньше придерживались". Напротив, все работы, на которые ссылаются современные "евангелисты водопада", описывали эту модель как гипотетический антипаттерн и предостерегали от её использования. Повторюсь – вот прямо в 1956. Т.е. уже в 50-х были более адекватные и прогрессивные методики, задолго до всяких там аджайлов и скрамов.
Существует ли водопад сейчас? О, конечно. Посудите сами – люди несколько десятилетий воевали с водопадом как с ветряной мельницей. К чему это привело?
Ну вот представьте, к вам несколько десятилетий приходят люди и говорят – "смотрите, у нас есть Agile/Scrum/любой булшит, который намного лучше водопада, попробуйте его". Вы пробуете – и не получается. Реакция? "Ну к чёрту, может всё-таки водопад?"
Помножьте на массовое невежество в области проектного менеджмента, которое в последние годы поразило мир подобно чуме. Ну вот не знает человек (некий гипотетический ПМ) других слов, кроме Agile и Waterfall, так что и выбор делает между ими двумя.
Так что да, возможно вы работали по "водопаду". Рискованный шаг, но если результат адекватный, то кто вас осудит.
А может быть вы просто работали по обычной неитеративной модели, которую современные ПМы в силу неграмотности по ошибке называют "водопадом"?
denis-isaev
12.06.2024 10:19Водопада" никогда не существовало как некой целостной "модели управления разработкой ПО, которой все раньше придерживались".
А для кого были писан вагон ГОСТ-ов? Хотите сказать они не применялись в госсекторе и всяких крупных хоз. секторах? Да чего там ГОСТ, в том же PMBOK до середины 2000х итеративные модели не рассматривались.
cat-chi
12.06.2024 10:19Ну, собственно, все материалы по управлению разработкой начиная с 1956 как раз предостерегают от использования подходов, применимых к промышленности, строительстве и т.п. в разработке ПО.
PMBOK – это вообще не про водопад.
Нет, если любую неитеративную модель называть "водопадом" – то пожалуйста. Называют же любой итеративный подход "аджайлом" ;) хотя итеративную разработку уже применяли в NASA ещё в 60-х...
Но как я и говорил, это слегка безграмотно. Т.к. "каноничный водопад" довольно жёсткий и содержит ряд искусственно придуманных недостатков, чтобы другие методологии с ним было сравнивать удобно. И если кто-то реально хочет внедрять себе вот прям водопад-водопад, то это карго-культ не лучше скрама, т.к. добавляются ненужные ограничения.
denis-isaev
12.06.2024 10:19А что такое "каноничный водопад"? Вики под этот термин подводит любые каскадные модели, в том числе в PMBOK-е опиcанные. Думаю большинство собеседников примерно так же используют этот термин: waterfall - каскадные модели, agile - итеративные.
Ndochp
12.06.2024 10:19И много есть каскадов, в которых прям вот не возвращаются на предыдущий этап, но проект выстреливает? Ну то есть увидели ошибку в ТЗ в момент производства, но чертежи не правят?
Portnov
12.06.2024 10:19+3водопад как 10 лет назад не существовал примерно нигде, так и не существует...
dstarakozhev
12.06.2024 10:19+1Вся статья пропитана субъективным восприятием по типу
"я из за не умения пользоваться молотком размаждил себе палец, по этому молотки это зло созданное чтобы ломать пальцы"
В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.
Проблема в людях, которые относятся к нему как к унивирсальной пилюле, сующтх скрам туда где он не нужен.
Потом его" адаптируют" и получается нечто что можно охарактеризовать как "работа по спринтам"
А дальше пишут статьи что скрам плохой...
Color Автор
12.06.2024 10:19В самом скрам нет проблем, это узкоспециализировнный инструмент, подходящих для конкретных задач, а для каких то неподходящий.
Как и везде? Было бы странно рассматривать методологию в отрыве от практики ее применения.
Сам по себе скрам неплох, но увы - делают с ним что-то не то.
shkirman_ruslan
12.06.2024 10:19+1Ну когда у тебя и пм и аналитик и скрам мастер это один и тот же человек, а какой эффективности может идти речь?)
ermadmi78
12.06.2024 10:19+2Вот всегда было интересно - а зачем нужны одновременно ПМ и срам мастер на одном проекте? Дейлики по очереди проводить и задачки по борде двигать?
BorisTheAnimal
12.06.2024 10:19+2ну в теории, ПМ(Product Manager?) должен быть адвокатом бизнес/клиентов команды, в то время как скрам мастер - помощником команды. Объединять их в одну роль, значит создать конфликт интересов.
Ну и по объемам - для маленькой команды с ограниченным потом задач можно еще найти баланс в одном человеке, но когда будет много задач, несколько команд(в теории SM должен поддерживать максимум 2 команды, на деле может быть и 5-6) - то тут будет банальный завал + желание по пути наименьшего сопротивления.
mysherocker
12.06.2024 10:19+3PM -- по умолчанию всегда Project Manager, так же как "филфак" по умолчанию филологический, а не филосовский.
Скажем, PMBOK -- про управление процессами, а не продуктом.
Объединять их в одну роль, значит создать конфликт интересов.
Забавно, что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
BorisTheAnimal
12.06.2024 10:19PM -- по умолчанию всегда Project Manage
Я бы тоже рад так думать (меньше путаницы), но в большинстве современных американских компаний, PM это Product Manager. А чистый Project Manager уже давно вымирающий вид. Даже TPM - это Technical Program Manager.
что в это самое время в соседнем цехе празднуют победу объединения dev и ops как раз для избегания межличностного конфликта интересов.
ну у бизнеса и разработки слишком разные интересы. Дай волю бизнесу, разработка будет в мыле и работать 24х7.
David_Osipov
12.06.2024 10:19+1А дай волю разработке, так продукт будет делаться годами и так и не выйдет в прод. Поэтому требуется конфликт интересов и переговорный процесс, чтобы люди про-бизнес и про-разработка могли вести переговоры и удерживать этот самый баланс.
BorisTheAnimal
12.06.2024 10:19Правильно. Но мы начали разговор выше о том, почему объединение роли представителя заказчика и роли представителя разработчиков в одну персону, создает внутренний конфликт интересов и может закончиться не сильно хорошо.
mysherocker
12.06.2024 10:19Cоздает внутренний конфликт интересов и может закончиться не сильно хорошо.
Почему "внешний" конфликт интересов лучше "внутреннего"? Я же не просто так привёл пример про DevOps. Я застал времена, когда продуктовых разработчиков премировали за изменения, а системных администраторов за отсутствие проишествий. Надо ли говорить, что изменения в коде -- главный источник проишествий в проде, который системные администраторы едва ли контролируют? Продуктовым разработчикам же часто не хватало мотивации понять боль ops коллег, они жили несколько в разных загонах и, порой, друг друга не понимали.
В итоге я регулярно наблюдал встречи, когда продуктовая разработка просит ускорить релизы, а эксплуатация их тормозит, как может. Когда разработка хочет добавить побольше компонентов-зависимостей, а сисадмины стараются умерить их пыл.
Глядя на то, что произошло после, мне очевидно, насколько продуктивной оказалось замена устаревшей командной топологии с "внешнего" на "внутренний" конфликт интересов, а именно, на разработчиков, которые сами релизят и сами просыпаются по ночам от звонков мониторинга и платформенную команду, которая позволяет им делать всё это, не разрываясь от когнитивной нагрузки.
Теперь разработчки сами решают (в том числе с помощью методик вроде SRE Error Budget), когда надо начинать разгребать влияющий на надёжность технический долг, временно переключив деятельность с разработки бизнес-фич, на стабилизацию продуктов).
sashailinsky
12.06.2024 10:19+1В руках мастера любой инструмент — грааль. Это я так ласково о том, что если не получается танцевать, то, возможно, дело не в балетках. Самое важное в любом фреймворке — это: понимать, когда нужен не он; и правильно внедрить.
GoodGod
12.06.2024 10:19+2Когда я сталкиваюсь с тем, что моя работа не может уложиться в какую-то методологию, и меня спрашивают, смогу ли я селать работу по методологии, я объясняю какую работу я должен сделать (написать код) и спрашиваю менеджера (обычно методолгист - менеджер)
- я рассказал, какую работу я должен сделать, как мастер методологии расскажите мне пожалуйста как мне уложить мою работу в эту методологию?
Я просто перестал считать себя супер профессионалом Скрама (в частности), и что я все понимаю и все в нем знаю. Профессионал Скрама - менеджер, я, как профессионал написания кода пробую найти с ним, как со специалистом в другой области контакт.
homesoft
12.06.2024 10:19+2Из личного опыта. Во многоих, очень многих случаях скрам превращается в карго культ.
pOmelchenko
12.06.2024 10:19+1очень много букв, но посыл понятен. Тем не менее, после короткого практикума в скрамтрэке, я наконец понял куда этот скрам пихать надо. Если коротко — в нулёвые проекты у которых есть только идея из которой начинает порезаться проект. Как только проект набрал ход — то там уже рулит канбан.
Проблемы начинаются когда команда не понимает когда какую методолгию применяют, что менеджмент, что линейные исполнители, тогда начинаются проблемы
muxa_ru
12.06.2024 10:19+5Однако ловкие продавцы церемоний усвоили только часть:
Добро пожаловать в реальный мир.
Именно так всегда и происходит с прекраснодушными мечтами о построении идеала - в реальности, мечты воплощаются не так как мечтали мечтатели.
pyrk2142
12.06.2024 10:19+5Важно понимать, что есть две разные беды:
Кто-то неправильно понимает, как использовать методологию, где она применима и зачем нужна. Это не так плохо, можно учиться и пытаться научить людей
-
Кто-то хорошо понимает, что он неправильно что-то применяет. И делает это очень осознанно, так как это позволяет получать зарплаты/премии, руководить все большими коллективами, выступать на мероприятиях, писать статьи и книги. Практически вокруг любого бизнеса появляется толпа людей, которые хотят отщипнуть себе деньги, как только они появляются. В ИТ и в управлении проектами сейчас просто безумное количество денег, и неудивительно, что рядом летают те, кто их хочет. В такой ситуации практически бесполезно писать статьи о том, почему «ХХХ - плохая технология/методология», важно четко понимать, что именно и зачем вы делаете
Поэтому важно понимать, с кем вы работаете - с человеком, который делает что-то по ошибке, либо с тем, кто зарабатывает на этом деньги
Batalmv
12.06.2024 10:19+2Зачем мы используем скрам?
Потому что надо что-то использовать, а тут есть привычка и отлаженные "церемонии и инструменты". Что тоже неплохо.
Нюанс в том, что под это определение не попадают RnD задачи, то есть задачи, в которых присутствует большая доля неизвестного
Так их туда можно не загонять. В реальности аналитик/архитектор/дизайнер работают все скрама, ну или в спринт-1. Т.е. проблемы нет.
Откройте Agile Manifesto. Вы удивитесь, насколько мало общего такие вещи, как SAFe, имеют с этим документом.
Тут респект за обраащенгие к истокам, к сожалению да. Это проблема и многие реально потеряли "фокус" и понимание зачем
----------------------
Проблема в другом. Люди вообще часто теряют фокус, что и зачем. И по любой методике пинают балду, либо изображают очень занятых на клеточном уровне. Тут не методика нужна, а личный подход
UranusExplorer
12.06.2024 10:1910 часов скрам церемоний в неделю, которые не дают сосредоточиться на выполнении задач, на которых постоянно спрашивают про статус этих задач (хотя статус можно узнать, просто заглянув в Jira).
Это вы сейчас не скрам описали, а что-то другое. Потому что The Scrum daily is not a status pull; if it is - you are not doing Scrum.
Color Автор
12.06.2024 10:19+7Вы мне про теорию, а я вам про практику. Если такого нет, почему я это вижу во многих проектах разных компаний разных стран?
UranusExplorer
12.06.2024 10:19+1почему я это вижу во многих проектах разных компаний разных стран
Ну значит они используют не SCRUM, а что-то совершенно другое. И соответственно то, что вы описываете, к скраму не имеет никакого отношения.
tsalkin
12.06.2024 10:19+4Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать.
Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
RnD задачи не вписываются в спринты
Важно разделять этап Discovery и Delivery фичи. На этапе Discovery продакт (или другой стейхолодер) изучает и описывает фичу, а разработчик (техлид, CTO) анализирует ее техническую реализуемость. И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Однако ловкие продавцы церемоний усвоили только часть:
процесс важнее всего
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить. Как минимум потому что иначе это перестает быть управляемым.
И чем крупнее организация, тем более единообразными хочется делать эти процессы.
Инструменты Kanban, такие как проиретизация задач и WIP limit, дают возможность управлять потоком работы, не прерывая сам рабочий процесс.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер? Потому что если не опираться на размер задачи, то WiP всегда должен быть =1, иначе большие задачи будут висеть на разработчике очень и очень долго.
А что же скрам, пора отправить его на свалку? Вовсе нет, есть сферы, где он отлично работает. Там, где задачи легки в оценке, а количество неизвестного и нового довольно низко - например, проекты поддержки и сопровождения.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
AngusMetall
12.06.2024 10:19+3Вы не разбрасывайтесь словами. Kanban! Для автора 33 летний скрам это "новое".
Color Автор
12.06.2024 10:19+3Наверное, в совсем наивных компаниях (командах) Scrum - это лекарство от всего, однако сейчас люди все же понимают, что Agile != Scrum, и что методологий множество, начиная с банального Kanaban.
Не уверен, что это действительно так. Кроме каких-то совсем маленьких компаний или компнаий с "особым путем", все поголовно используют скрам, многие лишь потому что "ну все так делают".
И да, задачи на RnD можно тоже декомпозировать. И даже оценить. Потому что брать в работу задачу даже анализ которой займет месяц не всегда имеет смысл.
Наверное можно, мне не доводилось видеть процесс, где это хорошо и повторяемо работает. Я бы хотел такое увидеть и понять, как у людей это получается на постоянной основе.
В стартапе на 20 человек можно прекрасно жить без единого процесса, однако когда в разработке у тебя 100-150 человек, то процессы придется строить.
К процессам претензий нет, претензия к карго-культизму. Когда процесс не ради решения задач, а потому что надо.
А у нас WiP limit измеряется кол-вом задач или все же с поправкой на их размер?
Я бы сказал, что это зависит. Большие задачи само по себе не очень хорошо, и дробление задач оправдано, когда это делается с целью уменьшения энтропии, а не с целью "чтобы влезло в спринт". Не знаю, делают ли так, но не вижу причин не ввести поправку на размер, если конечно мы умеем определять размер.
Как раз такие проекты отлично ложатся на Kanban, когда нам нужно выполнять определенным кол-вом людей (=пропускная способность команды) определенный объем задач.
Такие проекты вообще на любую методологию хорошо ложатся. Управлять известным объемом при известном капасити много ума не надо. Сложности (и потребность в методологиях) повышается, когда растут неизвестные, а с ними и риски.
sbase
12.06.2024 10:19+8Вот так хорошо начал. Скрам плохо здесь, Скрам плохо там. Я подумал что, вот оно, сейчас приземлят на потребности бизнеса, и.... внезапно "Возьмите Канбан в нем нет оценок" я прямо осёкся.
Скрам отлично подходит для своей среды. Особенно, если вы не знаете куда идти. И особенно если Клиент не знает куда идти и какую цель достигать.
Но в RnD проектах ЕСТЬ ЦЕЛЬ. Просто часто непонятно "КАК её достигнуть". Ну так может сесть и подумать? Для этого даже специально обученные люди были.... как их там?... а вот вспомнил! Архитектор программного обеспечения!
А если вы не знаете куда идти, так может остановиться с просить Клиента, " А ты, вообще, какую проблему решаешь?"
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
1. Что происходит?
2. Когда будет готово?
И ему главное чтобы было: Сказал - сделал. Или выполняй обещания или не обещай. Правильные спринты Скрама дают эту прозрачность. Да и неправильные спринты тоже дают это. Только это называется "план-фактный анализ" и проводится каждую неделю. Часто никак даже не называется потому, что в понедельник нужно понять "Чем они будут заняты и почему я должен им платить?"Color Автор
12.06.2024 10:19+1Вы подаете свой тезис под соусом "скрам за все хорошее и против всего плохого".
У меня нет претензий к скраму как к методологии. Как мне кажется, это хорошая, продуманная и целостная методология, которая была нужна индустрии, особенно энтерпрайзам.Проблема (и моя претензия) в применении методологии на практике. Когда скрам спускают сверху, не глядя, а что там за процессы у команд. И когда на крики снизу "нам эти спринты только мешают, ну не ложится процесс на них, приходится выдумывать синтетические костыли" им отвечают "вы просто неправильно работаете, надо по скраму, а вы все по-старинке".
Совещания здесь плохо, совещания там плохо. А ничего, что стандартного бизнес-человека беспокоит два вопроса:
Что происходит?
Когда будет готово?
Ответы на эти вопросы можно найти в Jira; в любой момент времени и в любом формате. Не обязательно всех в шеренгу ставить.
sbase
12.06.2024 10:19+4Во первых, Скрам НЕ МЕТОДОЛОГИЯ! А процессный каркас, о чем прямо указано в Руководстве.
Во вторых, Скрам без XP для ИТ-проектов - что пиво без водки.
В третьих - Вы можете сколько угодно смотреть в трекер задач, но бизнес-человек хочет ПОСМОТРЕТЬ В ГЛАЗА и спросить "А не лапшу ли ты вешаешь, мил человек?" . Впрочем из истории Скрама именно эта практика и была вполне успешной (см. в книге Сазерленда) . Потому, что только сравнив план и факт можно задать вопрос глядя в глаза и нужные принять решения и относительно проекта и относительно людей в нём.
MiyuHogosha
12.06.2024 10:19+1Архитекторы - вымерший вид. В некоторых специальных сферах есть мини-архитекторы - тематики
i360u
12.06.2024 10:19+10Всем адептам секты "разбиения больших задач на малые" (которых тут много в комментах), я хочу рекомендовать почитать о таком математическом термине как "эмерджентность". Да, конечно, декомпозиция - это важно, нужно, полезно, бла-бла-бла... Вот только, когда вы делаете что-то чуть более сложное, чем веб-форма, вас ждет масса сюрпризов. Просто не кормите себя иллюзиями и не ищите потом виноватых кроме себя. Во многом согласен с автором в отношении к RnD процессам.
OhSirius
12.06.2024 10:19Отличные наблюдения - мы в нашей команде придумали специальные RnD спринты:
Копим ижесы в течение определенного времени
Объединяем их в вехи - прорабатываем задачи
Проводим что-то вроде защиты, на которой принимаем решение достаточно ли экспертизы для промышленной реализации
Потом уже запускаем стандартный процесс через скрам
petejones83
12.06.2024 10:19+5Самое бесполезное время, которое я проводил, - это оценка задач в сторипоинтах. Вся команда тратит час-полтора, чтобы все задачи оценить или в 3, или в 5, что все равно с потолка берется.
1 и так очевидно, 8 или разбивается, или совсем непонятно, а больше и не бывает.
shukrd
12.06.2024 10:19+1наверное, зависит от команды. очевидно может быть не всем.
плюс в процессе обсуждения можно выявить, что кто-то увидит подводные камни неочевидные для остальных, тогда такая оценка увеличивает вероятность выявить нюансы.
Ivan22
12.06.2024 10:19+1ну оценка важна, это факт. Но вот концепция абстрактных сторипоинтов - это дичь. Они не нужны никому, любой кто использует оценку всегда хочет поиметь её в реальных днях.
Ndochp
12.06.2024 10:19Ключевое что мы делали на оценке - это убеждались, что команда единообразно понимает задачу. То есть 3-5 это норм, а 2-13 означает, что один хочет поставить костыль, а второй-написать мини фреймворк. И вот тут надо обсудить, а что сейчас реально стоит делать. Порой это реально не очевидно.
(ну и до 8 это футболки, а не фибоначи, 1 у нас был "полденька с перерывом на перекуры")А так при нормальной нарезке оценка действительно не важна - если всем ставить 1, а факт будет различаться в 4 раза, то статистически на пяти спринтах все утрясется.
dzot_dev
12.06.2024 10:19+3Честно говоря даже читать толком не стал – автор или кто там всё это писал явно не понимает о чем вообще речь.
Скрам это лишь обертка от конфеты, а сама методология является формализацией здравого смысла до которого вы всё-равно дойдете, но со временем и опытом. Любой здоровый проект хочешь или не хочешь приходит к тому, что написано в методологии. И это вообще не связано с IT напрямую, это здравый смысл в целом в любом производстве, будь то фабрика, строительство.. или IT.
Поэтому поливать скрам, канбан, и любые гибкие методологии, это просто неумение их готовить которое выражается в превалировании процессов над здравым смыслом в производстве.
Если не работает и есть сложности – разбирайте сложности и руководствуйтесь здравым смыслом. Всё. Все эти процессы, "церемонии", и прочая типовая лабуда сама придет, но будет служить на пользу, а не потому что так положено.
Просто ищите где рвется, вот весь рецепт.
Spyman
12.06.2024 10:19+7Кажется, автор отлично описал, где рвётся. В проекте, который разрабатывает новые фичи, интеграции и имеет сложность чуть выше, чем «собрать из кубиков готовый функционал», — чтобы провести оценку и декомпозицию задачи, нужно сначала провести ресерч, который будет содержать до половины реализации задачи и при этом сам невозможно оценить. Для проектов, где таких задач несколько больше нуля, — скрам неприменим, но его там всё равно пытаются применить.
Пример задачи — увеличить размер предзагруженного буфера в плеере до 10 минут. Может быть, это xxs и решится одной строкой в настройках, может s, потому что придётся написать и подменить какой-нибудь класс, отвечающий за буфер, а может 2xl, потому что придётся менять библиотеку плеера. И оценить это за час чтения документации не получится — потому что потом окажутся нюансы: ведь строка в настройках работает, но окажется, что в память влезает только 2 минуты, а свой класс не интегрируется в зависимую библиотеку и т. д.
Arioch
12.06.2024 10:19+3...а потом (я из легаси) окажется, что после увеличения размеров буфера плеера у тебя печать документов на бумагу стала работать с задержкой в несколько часов. Пока не накопится документов страниц на 100 - принтер даже не начинает печатать. Ну вот так оно когда-то получилось, когда скрам и аджайл свели к "сделай просто, чтобы уже завтра продать".
нужно сначала провести ресерч, который будет содержать до половины реализации задачи
А вторая половина - это груминг. Когда задача уже решена, но надо её обмазать проверками ошибок, логированием, метриками, конфигурацией, документацией и прочей фигнёй, нужной для долгосрочного использования, но именно решением проблемы (в узком смысле) уже не являющимся.
Окончание ресёрча и решение задачи (пусть на уровне MVP) - это зачастую синонимы.
P.S. Кстати, вынесение задачи документирования в отдельный спринт/таск *не работает*.
По факту либо ты пишешь полную документацию "сразу в жиру", а весь таск сводится к "переписать из Жиры в Ворд" (но откуда тогда брать человекомесяцы на это?), либо таск на документацию отъезжает на пару лет, а через пару лет какой-то новый техрайтер - с нулевым знанием проекта - приходит разрабам (чьи мозги уже начисто промыты ещё 100500 тасками с тех пор решёнными) и говорит "ну, рассказывайте, что вы там за фигню наворотили два года назад, а я это в Word перепишу, один час вам на всё так и быть разрешу списать".
onets
12.06.2024 10:19+7Но вот действительно - куча народу говорит что "вы не умеете готовить скрам", но показать на своем примере как надо - пока еще никто не показал.
У меня вот недавно была задача по глубокой переработке определенного функционала - ну разбил я ее на части, а толку? Если выложить на прод я могу только все вместе, иначе есть риск что там данные поедут не туда.
Спринты по две недели, а задача вышла на месяц. И что скрам предлагает в таких случаях делать?
panzerfaust
12.06.2024 10:19показать на своем примере как надо - пока еще никто не показал
Как этот показ должен выглядеть? Расшарить вам доступ до трекера и репозиториев на 1 год? Транслировать все созвоны по ютубу?
onets
12.06.2024 10:19+2Нет, описать конкретный подход вот в подобных случаях. Роли, кто что делает, кто за что отвечает, какие существуют варианты решения и почему выбран какой-то один из них.
themen2
12.06.2024 10:19+6Скрам - это ведь когда накидывают задач с лопаты на каждый день и ты бежишь как белка в колесе и нету даже денька расслабиться?
А ещё потом к текущим задачам прибавляются задачи in progress от QA и вообще ни конца ни края не видно задачам.
Arioch
12.06.2024 10:19+2насчет "бежишь как белка" - это твоё отношение. Можно ведь и по другому посмотреть.
если тебе накидали 100 задач с равным приоритетом - то это твоя свобода и гибкость.
прочитать эти задачи, сгруппировать их для себя (по технологиям, которые нужно вспомнить, по модулям которые надо переписать, по соседним отделам с которыми совместно надо будет решать - как тебе удобнее). Потом берёшь одну группу, по своему выбору, погружаешься в неё один раз и начинаешь пилить "отсюда и до обеда".конечно, 90% задач пролетают по срокам, но они ВСЁ РАВНО пролетели бы. И твоя реальная ответственность только в ВЫБОРЕ, какие из 10% НЕ будут сорваны.
Собственно, "100 задач с лопаты" это твой личный горизонт планирования себя. Когда ты просматриваешь это список, прислушиваешься к своему самочувствию, и решаешь. Сегодня я "голодный", я хочу закопаться в глубину и нахрен отрефакторить один говномодуль. А завтра я "с похмелья" и трёх переменных в голове не удержу, сделаю я лучше три мелких фикса, которые можно на рефлексах исправлять. И т.д.
Неужели было бы лучше, если бы ты с утра видел ровно две таски, о которых ты ничего заранее не знал, но которые до заката надо отресёрчить, имплементнуть, оттестить и передать в QA ?
GospodinKolhoznik
12.06.2024 10:19Скрам-не скрам не так уж и важно. Проблема вовсе не в скраме, и не в вотерфолле. Проблема в том, что океан нынче побагровел. Конкуренция в отрасли чудовищная. На всех уровнях - как на уровне корпораций гигантов, так и на уровне мелких фирм, и даже специалистов между собой. А при такой высокой конкуренции любая работы превращается в гонку ради самой гонки на износ. Ну а скрам это лишь один из способов эту гонку организовать и придать её хоть какое то подобие цивилизованного процесса. Не было бы скрама, применяли бы старые-добрые методы чайка менеджмента, постоянно орущего начальника и регулярного биться подчинённых палкой.
OlegUV
12.06.2024 10:19Детский сад. В нормальном процессе планируются не таски, а работа и результаты. При этом инструменты могут быть любыми Скрам - ОК, Канбан - тоже ОК, банальный эксель с произвольными записями - и то подойдёт, плюс-минус. И RnD планируется тоже нормально. Автору бы спуститься на уровень и узнать, что такое планирование вообще, а потом натягивать на него конкретные методики. Все хотя быть гурами сакральных истин, а всё уже до них давно придумано, только они этого знать не хотят, иначе огонь в глазах погаснет и их идеи не купят.
BorisTheAnimal
12.06.2024 10:19+1Проблема не в Скраме как таковом, а в том, что редко где есть хоть какое-то правильное его внедрение и поддержка. Ну не может быть человек с 0 знаний в PM и прошедшего недельный курсы scrum master (для получения CSM), построить какой-либо правильный процесс. Такие курсы должны быть для членов команды, что бы просто понимать общий процесс, или уже для человека с опытом управления проектами.
Scrum это так - общая оболочка. А к нему еще нужен багаж опыта и знания(по объему не меньше классического PMBOK).
olku
12.06.2024 10:19+3Скрам, вотерфол, Канбан подбирают по соображениям атомарности. Кому весь проект сразу, а кому по фиче в день. Атомарность подбирают под жизненный цикл. Например, MVP это вотерфол, а багфиксам со скачущими приоритетами ближе Канбан. Компании часто применяют не какую-то одну практику, а комбинацию их элементов. Но холиварят до сих пор.
aimfirst
12.06.2024 10:19+2Для RnD существуют более подходящие методологии.
Это точно.Например ГОСТ Р 15.101-2021 (и его предшественники). Рекомендую. Обращаю внимание на Приложение А. Практически все значимые научные достижения в нашей стране получены благодаря этой методологии. Но мало кто ее читал и понял, о чем там написано. И еще меньше тех, кто пытался применять на программных проектах.
Что касается SCRAM, не соглашусь. Просто надо понимать условия, для которых применение этого инструмента будет эффективно. На мой взгляд, болезнь кроется в головах рафинированных менеджеров, а не в инструментах.
panzerfaust
У скрама много недостатков, но то, что автор раз за разом пинает именно разбиение задач - наводит на определенные мысли об авторе.
Декомпозиция - ключевой инженерный навык. Вообще, вне всяких методологий. Даже вне разработки ПО. Обучение джунов я всегда начинаю именно с обучения декомпозиции. Иначе все быстро скатывается в задачи без конца и края. Над ними сначала месяц сидит и охреневает разработчик. Потом месяц сидят и охреневают ревьюеры, что им нужно вникнуть в 5000+ новых строк. Потом еще месяц задача ходит по кругу In Progress - In Testing, потому что QA охреневает от количества ассертов. В итоге 3 месяца - и полный ноль результата. Спасибо, лучше буду дробить.
Разрабатываем трейдинговую платформу по скраму. Неизвестного и нового довольно дофига, скопипастить особо неоткуда. Как раз все отлично ложится в процесс, когда заказчик приходит с хотелкой, а команда накидывается, делает дорожную карту фичи и распределяет задачи по исполнителям. Опять же есть подозрения, что в тексте имеет место экстраполяция "я не умею - значит никто не умеет".
Tirarex
Это у вас в вебе все так легко и прозрачно.
А теперь зайдите в геймдев где при разработке чего-то реально нового, каждая задача тянет на полноценный рисерч в рамках которого задача может быть выполнена без всякой декомпозиции, либо наоборот потребовать еще рисерчей. Кроме того познания в графике/физике итд требуют годы опыта и задачи требующие глубоких познаний банально некому оценивать так как людей с такими познаниями просто мало, не то что в компании а в целом на рынке. Собственно на таких реально больших и сложных задачах скрам умирает. И не редко в геймдеве есть задачи с неизвестным исходом рисерч которых может длится месяцы, а если это что то уникальное (например тысячи интерактивных крыс в игре A Plague Tale: Requiem) то разработка и доработки будут длится годами.
panzerfaust
А зачем мне заходить в геймдев? Это пусть автор пишет границы применимости его теории. А то получается странный разговор:
Автор: Пингвинов не существует!!!
Хабр: Да почему же? Антарктида, Тасмания, Южная Америка - там водятся пингвины.
Автор: А вы зайдите в пустыню Гоби - там пингвинов нет!!!
Arioch
при чем же здесь пустыни? вы написали:
То есть вы написали, что не только в геймдеве, а вообще в любой промышленности - даже где компьютеров нет вообще - скрам работает. А если скрам не работает, то причина - как вы пишете - в том, что все работнгики - низкоквалифицированные джуны, которых никто не учил ГЛАВНОМУ.
В общем-то вы проиллюстрировали тезис про "элегантный коммунизм". Который в рекламе работает везде, а после продажи - почти нигде.
panzerfaust
Серьезно? Прям так и написал? А мне казалось, что:
У вас декомпозиция == скрам? В следующий раз попросите помощи ЧятикаГПТ, если настолько тяжело написанное воспринимать.
Arioch
Вы сказали, что единственная причина по которой пинают скрам, это когда пинающие не умеют в декомпозицию, и поэтому не могут заранее просчитать сложность задачи.
Других причин, кроме неумения в декомпозицию, для недовольства скрамом нет, согласно вашему тезису.
panzerfaust
Неа, не говорил, лол. Продолжаю самоцитирование
Где что-то про "единственную причину"? Я говорю конкретно про автора, что есть вероятность, что навык декомпозиции у него не наработан. А если он не наработан, то жить в целом становится тяжелее.
Насчет ЧятикаГПТ я серьезно. Говорят, умеет разжевывать написанное.
Mausglov
Может быть, дело в том, что у Вас некоторые процессы идут в не в том ключе, как у других? Как я понимаю, Вашей команде заказчикв выделил бюджет на конечный продукт ( трейдинговую платформу ), а как Вы распределите бюджет на задачи, его не волнует.
Я тоже работаю в веб, но у меня ситуация иная. Приходит менеджер, далее диалог: менеджер: заказчик хочет вот такую фичу, сколько это часов?
я: не знаю, мы такого не делали. Мы можем сделать вот такой кусочек за N часов, и понять, что делать дальше.
менеджер: а какая часть задачи это будет? Половина? Четверть?
я: говорю же, не знаю. Мы такого не делали.
менеджер: нет, меня это не устраивает, мне надо сначала продать задачу заказчику.
Та самая RnD задача, о которой писал автор статьи.
При этом на другом проекте, где заказчик просто хочет получить результат (где-то в будущем), такой проблемы нет.
Kanut
Ну так а причём здесь скрам или не скрам? Неважно как вы у себя устроите процессы, но у вас всё равно остаются две проблемы: вы всё ещё не знаете сколько будет стоить решение задачи, а менеджеру всё ещё надо её сначала продать.
То есть вам в любом случае надо сначала продать клиенту ваш R&D. Или взять на себя риски и назвать ему какую-то конкретную цену за эту задачу.
Knightt
так тут проблема не самого скрама, а попытка применить его к RnD задачам... у меня от такого тоже болит... и да, скрам тут не работает. нужно смотреть как решать RnD задачи и донести до менеджеров, что этот процесс не укладывается в дейлики и закрытию какой-то таски каждый день
numark
В чем проблема взять задачу-плейсхолдер на весь спринт (спайк, POC, RnD, называйте как хотите). В конце спринта, через условные 10 рабочих дней (в случае 2-недельного спринта) у разработчика появится примерное понимание сколько дней (стори-поинтов) _примерно_ еще потребуется. Далее создаете еще таких же задач в следующие спринты.
Если же вообще понимания не появилось (делаем что-то суперсложное, "тысячи активных крыс в Plague Tale") - ну созадавайте опять плейсхолдер на 1 инженера на следующий спринт и все.
Всем участникам процесса надо быть гибче просто, не надо все воспринимать всё "в лоб".
piton_nsk
Задачу на весь спринт, ага. Хорошо если максимальный срок по задаче 3 дня, а если один день? Как будете отчитываться о ходе выполнения задачи, как же цели спринта. Скрум-мастер быстро объяснит в чем вы не правы)
Tirarex
А зачем ? что эта задача дает кроме пересоздания задач каждые 10 дней и переназначение на нее все того же единого разработчика. Какая фактическая польза кроме того что скрам мастер сможет накормить своих детей ведь у него еще осталась работа.
anticyclope
Автор говорит про "неизвестное неизвестное". Эта задача-плейсхолдер снимает первый уровень неизвестности. Ты целый спринт на законных основаниях занимаешься вскрытием проблем и рисков, поиском решения. В результате спринта от тебя ожидают ответа в виде "невозможно никак", "надо так, оценка - 3 месяца", "надо вообще по-другому", "можно обойтись без этого" и подобных. Если через спринт бизнес узнает, что нужно влупить в эту хотелку все деньги мира, наверняка задача резко потеряет приоритет. А в водопаде будут делать до тех пор, пока деньги не закончатся, а потом еще и в кредит, потому что "уже потрачено"
piton_nsk
Это если можно срок задачи установить в 2 недели. А у фанатичных адептов так делать нельзя, надо декомпозировать, как их не волнует.
anticyclope
Для "(спайк, POC, RnD, называйте как хотите)" допускается планировать хоть целый спринт. Даже если в итоге выяснится, что решалась задача за 5 минут. Адепты, как правило, понимают, что лучше ограничить период неопределенности, чем иметь неопределенную неопределенность. За фанатичных не ручаюсь.
То, о чем мы говорим, это же вопрос культуры и коммуникаций. Если скрам-команда не имеет возможности вернуть обратную связь заказчику и работает по принципу "мы люди маленькие, нам задачу дали, мы будем её пилить пока не сделаем, либо пока не устанем", то, конечно же, никакого спайка, никакой декомпозиции и никакой ответственности не дождешься. Если же команда имеет голос и может в процессе принятия задачи в работу сказать "нет, стоп, нам непонятно, мы не подписываемся", тогда просто задача в работу не идёт. Ну и кто в проигрыше от этого?
Tirarex
А кто сказал что спринта хватит на оценку ? Спринты у кого то неделя а у других 2 месяца. Кроме того кто сказал что эти оцененные 3 месяца хватит ? А если задачу сделают в рамках рисерча ведь рисерч без mvp по таске считай бесполезен, а этот mvp уже зачастую закрывает таску.
В итоге скрам ради скрама а задача была выполнена as is, про разработчика забыли на X времени без рамок спринтов, и он все сделал. И никаких подзадач и оценок ему для этого не надо.
На самом деле если команда с опытом то сразу после озвучивания задачи идет оценка типа "изи" или "мы на этом встрянем очень надолго" из которой бизнес уже прекрасно понимает надо ему это или нет.
Hidden text
В итоге скрам полезен для менеджеров и руководства как метод слежения за производительностью сотрудников. Но чисто для работы это действительно ощущается как рак отнимающий время вникуда. банальный канбан с задачами уже покрывает 99% задач. Тут в пример хочется привести Apple / Google которые всухую слились в AI гонке на данный момент, и тот же openAI где по сути стартап мусорка без аджайла и скрама существовала годами, и только такой подход без мозгоделия позволил им реально делать работу а не красивые задачки для руководства.
Еще пример в виде разработки игр в крупных компаниях типа Rockstar и найтидог, мега крупняк с кучей людей, скрамом и аджайлом, а переработок миллион, баги в играх вылазят постоянно, все фиксят в последний момент, куча кранчей. Наверное оценивают задачи плохо, и разработчики плохие, надо наказать их.
anticyclope
я живу в мире, где работа над какой-либо задачей продвигает меня в её решении. сами по себе они, почему-то, не решаются :(
может и не хватить, но явно будет лучше, чем на старте.
идеальный случай. большей частью потому, что решена задача была в рамках установленного ограничения по времени. Х, в данном случае, не "когда нибудь", а вполне себе "через две (подставьте свое число) недели"
когда команд > 1, то начинается ручное управление:
– эти знают лучше, давайте дадим им!
– но у них уже есть другая задача аналогичного приоритета!
– пусть вспотеют посильнее!
в то время, как рядом сидит менее опытная команда, но которая может немного закосячить с оценкой. даже если они ошибутся на 50%, в рамках спринта это половина. если дать задачу опытной команде, то, по-хорошему, они сделают её в следующем спринте. результат ручного управления - задача сделана на полспринта позже, зато опытной командой. вопросы качества не затрагиваю, в этом диалоге слишком много неизвестных.
vkurilin
Как минимум – такой подход заставит тебя раз в этот самый спринт подытожить, а что же ты выяснил, и какая новая информация появилась.
Потому у тебя будет планирование, где ты подумаешь: а надо ли вообще эту задачу сейчас брать? Может быть ты потратил три спринта, команда поняла что неопределённость особо не сокращается, и за такие деньги нафиг эти тысячи активных крыс продукту не нужны.
Согласись, намного удобнее, чем разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь", а в конце говорит "ну, не получилось"
Tirarex
А что мне мешает подытожить это без скрама, без заведения задачек и спринтов ?
Если из вашего же сообщения взять " разработчик который ушёл куда-то на полгода, раз в месяц говорит "я разбираюсь"" то ему явно нечего еще сказать под конец двухнедельного спринта раз он разбирается в задаче которой требуется "ушёл куда-то на полгода", и тут хоть есть задачка и хоть нет, он работает. А если ему есть что сказать то он и без эстимейта и задач вам это расскажет без проблем.
В той же веб разработке все как в китайской потогонке, все рассчитано и уже готово, только клепай на конвейере. А в сложной разработке с неизвестными алгоритмами и результатами, как у художников, нужна тишина, покой, студя с хорошим светом, вдохновение итд =) Иначе будет как у Microsoft на последней презентации. Показали 5 игр а они все дженерик мусор, не игры с душей и именем а game_1, game_2, game_3, так как все выштампованно из готовых ассетов по скраму с оценками времени, и там небыло времени на полет души и эксперименты.
vkurilin
Так ничего не мешает :)
SCRUM – явно не единственный способ работать работу.
Но фреймворк, при правильном использовании, заставляет тебя задуматься о том, как сделать свою процесс более управляемым.
Разработчику может и хотелось бы сказать "ой, ну я ничего не узнал", но фрейморк пушит тебя завершить работу, зафиксировать результат, и запланировать новую работу (опять же, сформулировав ожидания – что именно ты пойдёшь исследовать, и что расскажешь через две недели)
Tirarex
Что мешает писать заметки по результатам изучения, и делать это без скрама с задачами оценками и переносом задач каждые 2 недели на следующий спринт ?
Я не говорю что скрам не нужен, но я привел пример где он как рак для человека, вы пытаетесь убедить меня в обратном именно в рамках этой ситуации, то вы заведомо проиграли.
Скрам жив и он полезен в определенных проектах, но не везде, далеко не везде где его пытаются пихать. И вот вы сейчас этим самым пиханием скрама и занимаетесь, вызывая все большее отвращение у тех кто с ним поработал но на моих условиях (весь геймдев)
vkurilin
Ты просто в какую сторону воюешь то? Я не говорю, что scrum – единственный способ жить.
Я говорю, что scrum может помочь структурировать в том числе RND. Мы абсолютно друг другу не противоречим)
khajiit
Структурировать RnD помогает ведение журналов и системное мышление.
Все эти ваши методологии обеспечивают лишь примитивную визуализацию для бесконечно далеких от того, чем вообще занимается команда, людей.
Gorthauer87
То, что вы описали, можно назвать Скрамбаном. То есть это эдакий канбан поперек скрама. Может тогда сразу уже перейти на канбан?
Batalmv
Я бы так не делал, так как тогда - о чем все. Ну смотрите. Есть человек, он "копает" что-то неведомое. Тут не важно, неведомое вообще, для команды или только для него (хотя эта опция явно требует другого решения).
Но в любом случае у него есть идеи, что он делат. К примеру:
ищет варианты решения
пробует конкретный вариант
формулирует требования
...
И это уже формализуется и легко вносится в спринт
karrakoliko
чтобы внести в спринт нужно оценить.
как оценивать "ищу варианты решения" и уложиться в дедлайн? нужно дать обещание неизвестного и уложиться в него
Batalmv
Ну смотрите. Если мы примем, что требования к решению есть либо описана проблема, которую надо решить, то очевидно декомпозируются либо требования, либо сама проблема
К примеру, очень сложный пример. Мы хотим долететь до Марса и высадить там Марсоход и вы ищете решение. Очевидно, что начинать надо с декомпозиции задачи, которую повторять многократно. Первый уровень может быть разбиение на:
Ракета носитель для выхода на орбиту Земли
Ракета для того, чтобы долететь до Марса и выйти на его орбиту
Корабль, чтобы приземлить на Марсе
Сам марсоход
И дальше разбиваете до требуемого уровня детализации
Если простой пример, медленный отклик приложения. Разбиваем и ищем
------------
Тогда ваша первая задача - сделать декомпозицию. Вот и все
karrakoliko
Я вполне четко задал вопрос и он был не в том, как декомпозировать задачу
Batalmv
Это и есть ответ :) Не знаешь как делать - бей на части. Либо требования, либо проблему, либо архитектуру решение.
И так часть или части, которая будет разбита до элементов, о которых можно сказать "знаю" - будет оценена и внесена в спринт/план.
Или исполнитель не обладает требуемой квалификацией для занимаемой позиции
-------------
Мне даже грустно писать этот ответ, если честно
Ndochp
Так знаешь как делать.
Набрейнштормить варианты решения - 2 дня с разгребанием, в спринт укладываемся
Копать наиболее перспективный вариант либо до точки отказа либо до получения ясности - мы не можем внести в спринт, так как до брейншторма мы не знаем, что это за вариант, какие ресурсы потребует, какой будет признак отказа
Довести наиболее перспективный вариант до решения или начать копать следующий по перспективности вариант или провести новый брейншторм с учетом полученных на п.2 данных - да, для третьего пункта мы не знаем не только ресурсов, но и что это будет за задача. Вносить в спринт нечего. А за один спринт по 2 дня на гипотезу мы можем и до 5 пункта дойти. А уже здесь вносить нечего.
Batalmv
Ну видите, мы начинаем сходиться. Уже есть первая таска на борде. Как будут варианты - еще раз собираемся и либо декомпозируем дальше, либо оценивает и делаем :)
Главное помнить, что не мы для процедур, а процедуры для нас и нет проблем добавить таску по ходу :)
askharitonov
То, что нужны ракета, марсоход и т.д. — это очевидно, здесь декомпозицию сделать достаточно легко. А вот дальше уже сложнее. Например, в марсоходе нам нужен некий двигатель и некие колёса, ну или что-то вместо них, а их нельзя проектировать совершенно отдельно, потому что от мощности двигателя зависит вес марсохода и, значит, характеристики колёс, которые должны всё это везти, а, в свою очередь, увеличивая колёса увеличиваем общую массу, изменяем габариты, меняются размеры корпуса и передаточного механизма, то есть, это снова может повлиять на требуемую мощность двигателя, а увеличенные размеры нового двигателя возможно повлияют на расположение центра тяжести, что для марсохода может быть критично, и т.д. Нельзя просто взять и разделить конструкцию на отдельные элементы и их отдельно спроектировать. Тем более, если нужно минимизировать размеры и массу конструкции (чтобы легче было доставлять её на Марс).
Batalmv
Конечно, но я специально взял граничный кейс с мега задачей. Если мы остаемся в плоскости планирования, а не как это сделать технически (я тут не претендую на экспертность по очевидным причинам), но именно декомпозиция, которую вы продолжили позволяет в конечном итоге прийти к измеряемым задачам
В нашем варианте это может быть задача определить направления, определить состав групп проекта и т.д.
Суть в том, что камрад спросил - как делать и планировать то, что еще не знаешь как сделать. Ответ прост, декомпозировать то, что знаешь. Либо принять, что ты не соответствуешь позиции :)
-------------------
На самом деле на старте любого проекта возникает такая ситуация, когда ты еще на знаешь, но уже есть конкретные задачи, исполнители и сроки :)
Поэому вообще вопрос вызывает, как минимум, чуток недоумения
Color Автор
Именно про это я и говорю! Какая польза от этого? Мы синтетически "натягиваем" рабочий процесс на спринты, чтобы "было по скраму", при этом скрам никак не отражает реальный процесс, а то, что мы видим в нем - фикция, плейсхолдер.
В итоге рабочий процесс идет как и шел, а в трекере стоят нерепрезентативные заглушки, но зато менеджмент доволен, все под контролем!
Ndochp
Скрам ритуалы требуют даже по такой задаче плана эксперимента и отчета о результатах - та самая демка "которую можно в прод".
Тем самым механически не дает нырнуть на полгода в свободное плавание переходящее в броуновское движение с одной укладывающейся в WIP задачей канбана в InProgress.
Да можно избегать этого и без скрама. И возможно 100%RnD процесс эффективнее вести не по скраму. Но если вы уже работаете по скраму 90% задач, то и оставшиеся 10% RND логично оставить в том же процессе, если их делают те же люди.
karrakoliko
втыкаемся в эту проблему.
заказчик захотел
пм с дизайнером нарисовали макет
макет приносят команде на оценку по срокам
разработчику ставят задачу на оценку. эта задача выполняется в течение спринта рядом с обычными
разработчик оценивает
к оценке добавляется x запаса
если не отказались от идеи, увидев оценку - задачу ставят на разработчика, дедлайн = оценка
это тоже ломается об r&d
как оценивать решение задачи неизвестным образом - неизвестно. можно было бы закладывать время на "попробовать варианты абв и выбрать", но для этого нужно комплексно продумать каждый
оценку надо успеть выдать к следующему диалогу ПМа с заказчиком, чтобы они договорились о приоритетах
во время работы по задаче можно придумать лучшее решение, чем то что заложено в оценке. лучшее не значит более быстрое, а значит что в будущем поможет с другими задачами, емли заложиться в нее сейчас
на одной неделе тебе дают задачу x, а через еще две - x'. для решения задачи x не вводили новых сервисов/слоев, а для x' уже не получится. можно было сразу делать инфраструктуру для x', чтобы потом быстро закрыть обе задачи, но не вышло. теперь тебе нужно переносить x на x'. системно не решаемо, тк ПМ не может обобщить
12rbah
Хз в чем тут особенность геймдева, но это работает в любой сфере, если нужно что-то новое сделать, то нужен ресерч
skovoroad
Исследование (рисёч) всегда с неизвестным исходом, в этом его смысл. Но вообще говоря, мысль о том, что исследование нельзя спланировать и декомпозировать, это большое преувеличение.
В начале исследования программист вполне может сформулировать, как он планирует исследовать:
- ознакомиться с такими-то материалами
- если узнает то-то, то проверить такую-то гипотезу
- если это работает, написать прототип
- если нет, то поставить более конкретные задачи на другие исследования
Это уже декомпозиция, которую можно оценивать. Хоть целиком, хоть по отдельности.
Если человек говорит что он хочет "просто посмотреть такую-то тему" без понимания, что и как он будет исследовать, это уже плохой звоночек.
И если этого не делать, человек может месяцами даже не замечать, что занимается ненужной фигнёй. А декомпозиция и оценка (если остальные не понимают в теме - ну ок, не будут ставить оценку, но даже блин кошке полезно объяснить, что ты собираешься делать) спасёт его же самого от непродуктивной траты времени.
SAWER
Вот эти самые несколько слов, которые толком ничего не значат: "если узнает то-то" и содержат ошибку. Ты не знаешь, что узнаешь в процессе изучения материалов и проверки гипотез. И не можешь этого знать в принципе. Так и выходит, что планирование возможно только ближайшего шага, или просто полагаясь на интуицию и известные величины(вроде известных частей прототипа).
Только исследование, как правило, включает в себя десятки гипотез, до исчерпания идей. По сути, каждая новая гипотеза - новое исследование. Какие именно будут гипотезы невозможно узнать, пока не дойдёшь до них.
Проработка для оценки гипотез почти = проверке гипотезы во множестве случаев, т.е. дешевле сразу код писать. Фактически это то же программирование, но без собственно кода, что ещё сложнее и подвержено большому кол-ву ошибок.
Кстати, если делать по скраму, то "поставить более конкретные задачи на другие исследования" = новому спринту, что = полной потере гибкости. Если делать иначе - это уже не скрам. Цепочка гипотез растянется на годы работы, вместо дня
Batalmv
Да, но это не отмазка ничего не писать в описание задачи :) Никто ж не просит описать все, просто внесите в задачу
И все. Дальше напишете результаты и создадите таски для следующих задач
maclaudstein
был аналогичный опыт, только я тот самый менеджер продукта, который ставит ограничения сверху. Нет в этом ничего особо сложного, ты оцениваешь как-то сверху, сколько тебе нужно времени на разобраться, это время явно укладывается в спринт (если ты хочешь несколько месяцев разбираться, то сорян, задача уже, очевидно, не нужна вообще). После старта задача уточняется, и уже можно ее разбивать на более конкретные вещи.
Да и в целом планирование же нужно не чтобы кого-то поставить
ракомв рамки, а чтобы спланировать загрузку и прогнозировать результат этой загрузки, команда же не сама по себе ради своего интереса живет, такие вот дела, что за это кто-то платит, а кто платит, тот и заказывает музыку. А если хочется просто в свободного ученого поиграть - то это уже не про работу, а про любопытство, и то на это в рабочее время принято выделять время, но в целом - это нерабочая активность. Если потрогать технологию занимает больше месяца, то надо уже не ее изучать внутренними силами, а привлекать кого-то, кто за месяц сделает, это эффективней как-тл для проекта. Для человека, который хотел потрогать - нет, но для команды и проекта - однозначноopusmode
Смешались в кучу кони и люди.
Вам говорят, что декомпозиция это отличный навык.
Вы говорите, что декомпозиия не подходит для каких-то задач RnD, потому скрам это плохо.
Простите, возможно в момент написания вы не поняли этого, но надеюсь сейчас до вас дойдёт, что:
Декомпозиция это хороший инструмент.
Нет универсальных инструментов для всего. Для разных задач лучше подходят разные инструменты и это навык инженера - уметь их применять.
Неприменимость инструмента к задаче не делает инструмент плохим.
Ну и отдельно - честно говоря, ваши примеры скорее больше говорят не о том, что в вебе всё просто, а у вас сложно, а о том, что в вебе порядка больше, чем в геймдеве, притом в первую очередь в головах.
1755
Всегда было интересно про геймдев. Со стороны кажется что там кранч на кранче и костыль на костыле и происходит это потому что игру нужно выпускать асап в определенное окно, но при этом большой список хотелок и релиз в духе "все или ничего".
А как это выглядит изнутри индустрии?
numark
Геймдев разработчики всегда игры позиционируют как что-то из ряда вон выходящее. Про "окно" согласен. Но почему игру надо выпускать "асап", а не когда она доведена до ума? Потому что так решил менеджмент и инвесторы ждут (если они есть). Чем это отличается принципиально от релиза в каком-нибудь retail крупном? Там зависимостей от окружающей среды не меньше: топ менеджмент ставит сроки и ждёт их соблюдения, в горячий сезон релизить нельзя из-за рисков все сломать и упустить прибылью. Конкуренты толже могут поджимать.
А так - и в геймдеве бывают нормальные релизы, почти без багов и коанчей (Baldurs Gate 3), а бывает забагованное дерьмо с лопаты и кранчи. Все от комнды и менеджмента зависит, а не от того что это "геймдев".
1755
Да вот поэтому интересно в чем такая особая специфика геймдева, что оттуда историй про кранчи, багованные баги и костыли в виде поездов-шапок больше, чем в других отраслях.
k_p_v
это безболезнено и смешно. никак не сравнить с реальным миром, как баг (и костыль MCAS) у боинга, когда самолёт не может взлететь из-за одного неправильного датчика. или у атомного реактора, но хорошо, хоть защита сработала. пара багов в реальном мире - и самолётам запретили летать. А в это время в геймдеве - набираем предзаказы на новые костыли и баги, кто быстрее заплатит, то будет главным тестировщиком багов!
maldalik
Я думаю тут дело в том, что даже посредственная и багованная игра, как правило окупается, поэтому менеджеров устраивает что выйдет говно - главное побыстрее выпустить и продать.
ExternalWayfarer
Нифига не как правило. Откуда вы это взяли? Да, может посредственная и багованная окупиться, может шедевральная и отполированная провалиться. Но шансы одинаково низкие для этого, и они тем ниже, чем известнее и богаче студия.
ExternalWayfarer
Приведите пример, что это за ритейл крупный?
Мне вот про геймдев как раз всё понятно.
Suvitruf
Если задача длится 2 месяца, нету никаких этапов и рубежей, чтоб оценить прогресс, то это не проблема геймдева, а проблема декомпозиции и оценки задач.
markmariner
Так вы разбиваете задачу на исследовательские, которые влезают в спринт и в каждой новой указываете направление исследования, на основе того, что наисследовали в прошлый раз. А если получилось в прошлый раз не только наисследовать, но и понять, что надо делать, ставите задачу на выполнение.
Это же тоже никак не связано со скрамом. Независимо от того, как вы работаете, вы каждый день выходите на смену и что-то делаете, и получаете какой-то результат, который примените в будущем. А если вы не можете сформулировать результат после выполнения работы, то и работа выполнена не была.
Color Автор
Краткий ответ - декомпозиция очень важный инженерный навык, с этим спорить было бы глупо.
Однако разбивать RnD задачи на мелкие атомарные части часто не получается, или получается плохо, так как скоуп задачи заранее неизвестен, и часто может измениться на несколько порядков от оценки.
Можно свалить на неумение разбивать - с этим тоже не спорю. Большинство аргументов в пользу скрама и сводятся к тезису "вы просто не умеете его готовить".
Но если мало кто умеет его готовить, может не в поваре дело?
panzerfaust
Удивительно, но вообще не существует такой методологии, куда RnD вписывается как родной. Вернее, есть, и это называется грантовая система. Но это не про разработку ПО.
Если у вас именно в разработке постоянно возникают RnD задачи поперек скрама, то у меня большой вопрос, что вы там такое разрабатываете? AGI?
У нас RnD задачи тоже есть и тоже встречают сопротивление менеджмента. Но их не так много и для этих целей самых скилловых просто на время освобождают от спринтов. Да, команда разработки должна иметь кахонас, чтобы иногда проталкивать свою повестку.
inkelyad
RnD задачи, по идее - стандартная задача поддержки(которую почему-то уж слишком сильно разделяют с разработкой). "Произошло нечто. Нам кажется, что это не правильно и хочется, чтобы не происходило". И тут может быть так, что причина/исправление за 5 минут ищется, а может - что очень долго нужно разбираться, а как и почему оно вообще произошло.
panzerfaust
У меня другое понимание RnD. Вот, например, сидим мы на одном инстансе, который еще с MVP остался, а хотим хайлоад, отказоустойчивость, мультиинстанс, доступность 99999. Вот как этот скачок совершить, продолжая работать в проде, - это как раз задача RnD.
Ну а баги расследовать - такое себе RnD. Опять же, если постоянно возникают баги, которые расследуются неделями, то точно скрам виноват?
Ivan22
ну саппорту разобраться в спагетти-коде доставшемся от разработки - это целый RnD
Gorthauer87
Это больше на детектив тянет
morijndael
Повезло, что не на хоррор
ermadmi78
Банальный highload например. Когда стандартные архитектурные паттерны перестают работать. И на привычные инструменты (СУБД, библиотеки, фреймворки) уже нельзя положиться. Когда не понимаешь, где "горлышко бутылки", даже обложившись метриками сверху до низу. Когда не готов дать внятного теоретического обоснования возникающим проблемам. И всё, что ты можешь - генерировать гипотезы и проверять их экспериментально. И когда внезапно выстреливает самая безумная и неперспективная гипотеза, проверить которую решились от отчаяния. Вот какой тут нахрен скрам?
Knightt
подготовка материала по best practice решения RnD задач - менеджеру нужно объяснить, что "это другое"
брайншторм гипотез, взвешивание каждой - 1 день
задача на исследование каждой гипотезы - покрытие метриками - фиксирование результат(не важно удачного или нет) - 1-2 дня на каждую гипотезу
груминг фикса
а тут уже дальше технические задачи
что-то такое я предоставлял менеджеру.. )
opusmode
Ну, генерируйте и проверяйте. Но вообще-то в хайлоаде вполне себе часто видны бутылочные горлышки.
Я прочитал ветку и у меня впечатления, что люди, жалующиеся на скрам и приводящие примеры, чаще не видят, что проблема не в скраме, а в их подходах и, возможно, уровне компетенций. Как следствие идёт перекладывание ответственности на "внешнего врага".
Опять же, даже если мы берём за константу, что вы правы и всё так и есть и даже если скрам вам вообще не подходит, это не делает его хуже и уж тем более раком. Он всё ещё просто не подходит вам.
ermadmi78
В самом скраме ничего плохого нет. Раком его делают люди, которые по умолчанию пихают его куда можно, и куда нельзя. И религиозные фанатики, доводящие рекомендации скрама до абсурда.
PS
В нескольких своих проектах я сам лично вводил разработку по скраму. И ничуть об этом не жалею. Просто там он был по делу.
eee94
Именно так! Если команда берет задачу и 2 месяца даже не знает как начать решать - зачем брала то?
Если задача не имеет решения для конкретной команды - не поможет никакой скрам. Но, возможно, скрам поможет выявить этот факт побыстрее.
ReaderReader
Никогда не работал в чистом R&D, поэтому возможно предположу что-то совершенно неправильное. Поправьте меня тогда, пожалуйста, но мне кажется, что Канбан зайдет в R&D на ура. У вас имеются некие задачи. Срок выполнения этих задач очень размытый, и не факт, что каждая вообще может быть выполнена на 100% В то же время имеется ограниченное количество ресурсов (ученых, доступного времени на лабораторных установках и т.д.), поэтому нельзя допустить, чтобы в работе было одновременно 100500 задач, т.к. это будет крайне неэффективно. Соответственно, мы имеем доску задач с колонками:
Общий список задач, над которыми еще не начинали работать, но возможно будут взяты в работу. Количество задач нелимитированно.
Список задач которые решено взять в работу, но работа над ними еще не начата. Количество от нелимитированного, до некоего предела, чтобы не получилось очень большого списка.
Список задач, над которыми ведется работа. Количество жестко лимитировано. Нельзя взять в работу новые задачи, пока не решены предыдущие
Время решения каждой задачи неограниченно. Или ограничено неким приемлемым для всех логическим пределом (нельзя решать одну задачу год, или 10 лет и т.д.) Такая организация не подходит для R&D?
ermadmi78
Да - Канбан это наиболее подходящий для R&D инструмент.
aegoroff
Можно много чего - статический или динамический анализ кода, компиляторы (например для нового языка), формальные доказательства корректности программ, профайлеры, линтеры и все такое. Например в статическом анализе кода (нормальном), используется, так называемое символьное выполнение (не путать с обычным), так вот, полностью его, на реальной программе выполнить невозможно (экспоненциальный рост сложности), поэтому приходится постоянно искать приближение к идеалу, и это - terra incognita
SAWER
Ну вот честно говоря, у меня почти все задачи RnD полностью или с элементами. И, кмк, элементы встречаются всегда в работе программиста.
Для начинающих это любая задача с вопросом "как?", коих... все. Потом становится всё лучше, но появляются сторонние проблемы. Баги IDE, системы, фреймворков и т.д. Чем дальше, тем больше таких проблем. И решает эти проблемы тот у кого опыта больше вырулить на опыте и общих знаниях, т.к. другие просто не справятся за адекватные сроки. Я одинаковых задач то знал буквально по пальцам руки. Даже если называются одинаково, то делались принципиально по разному через год.
PS: сам я в геймдеве больше работал. Может в других сферах и иначе, но что-то сомневаюсь, что там простая перегонка json-чиков для кодеров.
clarifyingman
Когда я занимался джедайскими техниками, то заметил один удивительный факт. Люди думали, что навык планирования зависит от инструмента.
Пример: У меня проблемы с планированием, а я вижу как хорошо у Васи получается планировать с помощью Jira (или Notion, или Singularity). И начинаю думать, что я научусь планировать так же хорошо как Вася как только начну применять его инструмент.
Только это так не работает. Я не стану хорошим фотографом от того, что куплю себе крутой фотик. Для этого нужно что-то ещё, кроме инструмента, а именно умение увидеть и поймать хороший кадр. И от перехода в Jira у меня не появятся навыки планирования.
Сдается мне, что с декомпозицией та же история. Любой процесс разработки будет идти сложно (хоть ватерфол, хоть скрам), если вы не умеете декомпозировать. Однако я предполагаю, что в скраме проблема с декомпозицией будет лучше видна.
Но многие продолжают думать, что переход на скрам автоматически научит людей декпомозировать/планировать/делать то, что они раньше не умели делать.
И в этом проблема. В ложной связке "я купил пианино - и теперь я классный пианист". Или "Стоит мне перейти на скрам - я сразу стану таким же крутым разрабом как тот чувак"
В целом это основная причина плохой готовки скрама. Что кроме скрама надо знать и уметь много чего, о чем не говорят в силу того, что это сложно и неочевидно. А среднестатистический тренер находится в ложной связке "сейчас введем процедуры дейли, демо и ретро, и тогда научимся всему тому, чего раньше не умели". При этом этот же тренер даже не осознает, что среди навыков, которым надо научиться, может быть умение декомпозировать. И не знает как научить декомпозиции. Но надеется, что на ретро все такие моменты подсветит команда. И та же команда придумает как научить декомпозиции.