Комментарии 137
Результаты работы по скраму напоминают миниатюру Райкина "Кто шил костюм", когда непонятно, кто же отвечает за продукт целиком. То ли программисты, которых ставят в условия работы на конвеере, то ли менеджер проекта, который пытается выполнять роль системного архитектора, зачастую не понимая даже азов программирования. Это личный печальный опыт, возможно, у кого-то он другой
Мифическое-социалистическое "за продукт отвечает каждый", в итоге чего продукт выглядит как улица в сельском райцентре.
Это результат работы по скраму, когда половина команды не следует инструкциям, прописанным в Скраме. То же самое получается, когда на дорогах общего пользования, половина участников начинает плевать на пдд и ездит как кому удобно. Как следствие — больше дтп, пробки, покалеченные пешеходы. Скрам — те же пдд, только для разработки. Если следуют все, то все работает как часы, с минимумом затыков. Если кто-то нарушает — страдают все. В наших краях скрупулезный менеджмент не приемлется, ценности продукта, компании редко ставятся выше личных предпочтений менеджмента или разработчиков, методологии переделываются под удобство коллектива. Нарушать правила в угоду сиюминутного удобства — норма.
Проблема в менеджменте и в культуре в целом, а не в методологиях.
Проблема в менеджменте и в культуре в целом, а не в методологиях.
Напоминает оправдания социалистов почему коммунизм нигде «не взлетает», идея-то отличная со всех сторон, почти идеальная! А вот с народом, как правило, не везёт…
Может потому что коммунизма нет и не было нигде? А вот социализм работает нормально.
И где у нас сейчас социализм нормально работает? На Кубе? Bо Вьетнаме или Лаоссе? Или в Китае где его вовсю мешают с капитализмом? :)
Китай неплохой пример, но я бы упомянул скандинавские страны, да и вообще Европу — места, где старый капитализм превращается в социализм. А вот капитализм действительно плохо работает — РФ самый лучший пример, чего уж там.
Капитализм, потихоньку превращающийся в социализм, это на мой взгляд плохой пример нормально работающего социализма. Как впрочем и любая смесь капитализма с социализмом.
Это даже если забыть что никакой социализм скандинавы не строят и строить не собираются. Они, как впрочем и куча дpугих стран в Европе, имеют социальную рыночную экономику или просто социальную экономику. Но это не социализм.
Это даже если забыть что никакой социализм скандинавы не строят и строить не собираются. Они, как впрочем и куча дpугих стран в Европе, имеют социальную рыночную экономику или просто социальную экономику. Но это не социализм.
Я не поклонник упоминаемых вещей, но «капитализм, потихоньку превращающийся в в социализм» — это как раз социализм нормального человека, в отличии от «отнять и поделить». Как и в примере про футбольную команду, нужно создавать общество которое сможет делится с теми кто не может заработать, а не разделение всего создаст общество что будет работать на общее благо.
Если конечно под социализмом понимать путь а не цель, или идеализированную цель, то так говорить конечно нельзя. Но ИМНО лучше достижимые 90%, чем недостижимые 100%.
Если конечно под социализмом понимать путь а не цель, или идеализированную цель, то так говорить конечно нельзя. Но ИМНО лучше достижимые 90%, чем недостижимые 100%.
У социализма есть определённые критерии, которые должны выполняться, для того чтобы это был социализм. Например государственный/общественный контроль средств производства.
То есть далеко не всё что является социальным, одновременно является и социализмом.
У скандинавов эти критерии не выполняются и никто не стремится их выполнять. Поэтому именно социализма у скандинавов нет и на данный момент даже не планируется. Но это не мешает им иметь социальное государство/общество.
Вы не совсем правильно поняли суть написанного.
Скрам — это набор правил и инструкций, для того, чтоб быстро заделиверить продукт соответствующий требованиям заказчика. Такой же, как набор ПДД, задача которого — безопасность всех участников движения при минимальных ограничениях свободы. Такой же, как любая политическая теория, задача которой сводится к обеспечению блага определенной группе людей.
Можно ездить без ПДД, как и разрабатывать ПО без каких-либо правил и ограничений, как и жить в первобытно общинном строе. Это просто и доступно в целом любому социуму, вне зависимости от уровня образования, культурных потребностей, материальных притязаний. Естественно, производительность любой такой системы будет на соответствующем уровне, и ограничиваться будет числом одновременных участников. Вы не напишите хорошее ПО в компании на 1000 человек где нет никакого регулирования, не обеспечите интенсивное автомобильное движение в большом мегаполисе, не поставив светофоры и не разграничив парковочные зоны, и не запустите ровер на Марс обществом, где нет сложной системы законов и развитых политической и экономической систем. Чем более комплексный результат хотите получить, тем больше сложных правил и ограничений нужно устанавливать, тем сильнее регулировать коллектив. Чем меньше культура и уровень образования коллектива соответствует выбранной методологии, своду пдд или законам политического устройства, тем сложнее будет внедрить все это в коллектив. Нельзя просто так взять и построить завод по производству сложной электроники там, где единственным законом было «право сильного», в все образование заключалось в том, как ловить рыбу и изготавливать луки и копья. Нужно поколениями менять систему образования, культуру.
Скрам — сложная система менеджмента, для которой нужен определенный уровень образованности и культуры компании/коллектива, чтоб участники вообще могли строго следовать прописанным правилам. Координация и предсказуемость требуют большого числа ограничений. Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
Скрам — это набор правил и инструкций, для того, чтоб быстро заделиверить продукт соответствующий требованиям заказчика. Такой же, как набор ПДД, задача которого — безопасность всех участников движения при минимальных ограничениях свободы. Такой же, как любая политическая теория, задача которой сводится к обеспечению блага определенной группе людей.
Можно ездить без ПДД, как и разрабатывать ПО без каких-либо правил и ограничений, как и жить в первобытно общинном строе. Это просто и доступно в целом любому социуму, вне зависимости от уровня образования, культурных потребностей, материальных притязаний. Естественно, производительность любой такой системы будет на соответствующем уровне, и ограничиваться будет числом одновременных участников. Вы не напишите хорошее ПО в компании на 1000 человек где нет никакого регулирования, не обеспечите интенсивное автомобильное движение в большом мегаполисе, не поставив светофоры и не разграничив парковочные зоны, и не запустите ровер на Марс обществом, где нет сложной системы законов и развитых политической и экономической систем. Чем более комплексный результат хотите получить, тем больше сложных правил и ограничений нужно устанавливать, тем сильнее регулировать коллектив. Чем меньше культура и уровень образования коллектива соответствует выбранной методологии, своду пдд или законам политического устройства, тем сложнее будет внедрить все это в коллектив. Нельзя просто так взять и построить завод по производству сложной электроники там, где единственным законом было «право сильного», в все образование заключалось в том, как ловить рыбу и изготавливать луки и копья. Нужно поколениями менять систему образования, культуру.
Скрам — сложная система менеджмента, для которой нужен определенный уровень образованности и культуры компании/коллектива, чтоб участники вообще могли строго следовать прописанным правилам. Координация и предсказуемость требуют большого числа ограничений. Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
Можно было вместо такого длинного текста сказать кратко — Скрам предназначен для организации работы самомотивированой команды. Где-то смотрел статистику что в принцые самомотивированных и саморганизованных людей процентов 15 от всех программистов а команд где из 5 программистов 5 самомотивированные еще меньше. Для всех остальных есть схема ТимЛид и его подчиненные. Тимлид принимает все решения и поэтому за все несет ответственность. Назначает задачи своим подчиненным и принимает от них результат выполнения. Все.
Просто многие забывают, что agile — это про гибкость. Все что есть в SCRUM можно менять до полной неузнаваемости, главное чтобы это было полезно/удобно/выгодно/хорошо. Нет никаких «жестких» непреодолимых рамок, потому что их существование нарушает основную концепцию agile.
Ну и, помним также, что первее — наши крутые ит-процессы или их дурацкие бизнес?
Ну и, помним также, что первее — наши крутые ит-процессы или их дурацкие бизнес?
"Сложные задачи отодвигаются на потом."
Как это возможно при правильном scram? Баклог отсортирован так что самые важные задачи находятся вверху списка. Так что как правило самые сложные задачи тоже будут сделаны первыми.
Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу.
К тому же важный != сложный. К тому же важность не всегда четко определена, в спринте может быть много задач с одинаковой важностью.
При этом разработчики всегда будут стараться брать побольше простых задач. Чтобы выглядеть молодцом на ежедневном митинге. Пока Вася уже неделю уныло твердит что делал одну и ту же задачу "Х", вызывая сочувственные взгляды коллег, Петя каждый митинг рапортует о пяти сделанных задачах и вызывает всеобщее восхищение начальства.
Ну во первых описываемая вами ситуация это не проблема скрама/аджайл, а проблема конкретных «коллег» и «начальства», которые не видят сложности задач и/или не понимают что сложные задачи требуют больше времени чем простые.
А во вторых что у вас вообще начальство делает на ежедневных митингах? Ну то есть если мы возьмём скрам, то всякие daily и standup'ы они как бы для команды, а не для посторонних…
А во вторых что у вас вообще начальство делает на ежедневных митингах? Ну то есть если мы возьмём скрам, то всякие daily и standup'ы они как бы для команды, а не для посторонних…
это не проблема скрама/аджайл, а проблема конкретных «коллег» и «начальства»
Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.
Хотя я лично считаю, что если идея раз за разом реализовывается неправильно и с одними и теми же граблями — проблема все-таки в идее.
Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.
Это не проблема реализации скрама, а проблема конкретных людей. Если вы возьмёте тех же коллег/начальника и будете с ними делать водопад, то вы получите ровно ту же самую проблему. То есть ваши разработчики всё равно будут пытаться каким-то образом получить самые простые задачи чтобы сделать их как можно больше и получить похвалу от начальника.
Хотя я лично считаю, что если идея раз за разом реализовывается неправильно и с одними и теми же граблями — проблема все-таки в идее.
То есть если куча людей раз за разом забивают гвозди микроскопом, то проблема именно в микроскопе и гвоздях? :)
Да и вообще мне интересно на чём строится вот это ваше высказывание? У вас есть какая-то глобальная статистика по удачным/неудачным попытка реализации скрама и причинам по которомы реализация не удалась?
То есть как бы поскольку лично я видел больше «удачных» реализаций скрама чем «неудачных», то я бы всё-таки сказал что дело совсем не в скраме.
Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.
Так почти во всех реализациях, где я участвовал, требования фреймворка грубо нарушались. Основное нарушение — менеджмент вмешивается в ход спринта от мелочей типа активного участия в дэйли-митингах до изменения скоупа спринта без его отмены.
«Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу»
Тогда это не СКРАМ.
Задачи должны быть оценены. Иначе не возможно спланировать спринт. Если у задач есть оценка то сложная задача будет допустим 3 дня, а легкая 0.5 дня. Так что ни кто не будет криво смотреть на Васю который делает свою задачу положенных 3 дня. А вот когда Вася потратит лишний день на эту задачу, то он должен будет объяснить почему, в чём проблема. Скрам мастер сможет сразу среагировать и помочь Васе. Пете тоже придётся выкладываться не меньше чем Васе, так как он тоже должен отчитываться каждый день.
Про какое начальство вы говорите? На стендап митингах должны быть программисты и скрам мастер. Начальству там делать нечего. Начальство может присутствовать на демо в конце спринта, где отчитывается команда за результаты спринта. Только тогда будет сплочённость команды и ответственность за общие результаты.
Тогда это не СКРАМ.
Задачи должны быть оценены. Иначе не возможно спланировать спринт. Если у задач есть оценка то сложная задача будет допустим 3 дня, а легкая 0.5 дня. Так что ни кто не будет криво смотреть на Васю который делает свою задачу положенных 3 дня. А вот когда Вася потратит лишний день на эту задачу, то он должен будет объяснить почему, в чём проблема. Скрам мастер сможет сразу среагировать и помочь Васе. Пете тоже придётся выкладываться не меньше чем Васе, так как он тоже должен отчитываться каждый день.
Про какое начальство вы говорите? На стендап митингах должны быть программисты и скрам мастер. Начальству там делать нечего. Начальство может присутствовать на демо в конце спринта, где отчитывается команда за результаты спринта. Только тогда будет сплочённость команды и ответственность за общие результаты.
«Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу»
Тогда это не СКРАМ.
С чего это вдруг? Задачи приоризируются стэкхолдером с точки зрения его хотелок. Потом они оцениваются командой с точки зрения технической выполнимости(бессмысленно пытаться устанавливать крышу пока даже нет фундамента) и при необходимости прироритеты изменяются.
После этого задачи набраются в спринт с учётом их приоритета. Но это не означает что задачи попадут в спринт обязательно так как они приоризированны. Например если у вас на первых местах по приоритету стоят две большие задачи и они обе вместе в спринт не влезают, то берётся первая и остаток «добивается» менее приоритетными задачами.
А уж кто там как и в каком порядке дeлает задачи в самом спринте это вообще нигде и никак не регламентированно.
они обе вместе в спринт не влезают
Если у вас две задачи в спринт не влезают то это явно проблема с описанием задач. Такие задачи нужно обязательно разбивать на более мелкие. У нас был лимит на задачу 3 дня. Но в практике все задачи были обычно не больше 2 дней.
Стокхолдер не дурак, он будет всегда просить самое важное. А самое важное, обычно самое сложное.
Кстати на счёт
технической выполнимости, очень многие «правильные» программисты перегибают палку на счёт невыполнимости. Начинают доказывать что нужно сначала сделать модуль Клиентов, НДС, Стоимости доставки и так далее что бы сделать страницу заказов. Но если продукт ещё в стадии разработки, то спокойно можно написать заглушек вместо готовых модулей. Некоторые кто привык работать стандартным методом много лет не могут поменять привычки и попробовать новые методы.
Если у вас две задачи в спринт не влезают то это явно проблема с описанием задач.
Не исключено. Но и не обязательно. Ситуации разные бывают.
А ещё например бывают ситуации с зависимостями от каких-то внешних факторов(в том числе и от заказчика) и они тоже могут блокировать высокоприоризированные задачи.
Стокхолдер не дурак, он будет всегда просить самое важное.
Просить он может. Но это не значит что всё, что стэкхолдер просит, реализуемо именно в том порядке в каком он это хочет.
А самое важное, обычно самое сложное.
Ну вот совсем не обязательно.
очень многие «правильные» программисты перегибают палку на счёт невыполнимости.
А многие не перегибают и всё учитывают верно. А многие считают задачи выполнимыми, а на самом деле выходит что нет. А многие…
Какое это имеет отношение к тому что в скраме во время спринта задачи можно выполнять в произвольном порядке?
бывают ситуации с зависимостями от каких-то внешних факторовТакое должно быть сведено к минимуму. У задачи должны быть описаны статусы. Статус «готова к спринту» означает что она свободна от всяких зависимостей, анализ сделан, все правила прописаны, и даже описано как её тестировать когда она будет готова. Если задача не отвечает этим критериям то её нельзя брать в спринт.
Agile это больше о здравом смысле. У нас в спринте всегда были задачи которые должны быть сделаны в определённом порядке. Это не было проблемой так как в каждом спринте было по 5 средних задач на программиста. Было легко руководствоваться здравым смыслом и давать одному программисту три зависимые задачи и пару независимых. Например один программист делает почти все задачи в модуле Клиента а другой в модуле поставщика. Мы всегда при планировании договаривались кто что будет делать а потом уже к концу спринта помогали если кто не успевал. А кто работал быстрее всех подбирал мелкие задачи.
Такое должно быть сведено к минимуму.
Не всё, что «должно быть сведено к минимуму», всегда удаётся свести к минимуму. Более того на самом деле онo и не «должно». Потому что например если заказчик не может/хочет по другому и готов за это платить, то это его дело и его деньги.
У задачи должны быть описаны статусы.
Нет, не должны. Они могут быть описаны. И это часто хорошая идея так поступать. Но никакого «должны» нет.
Если задача не отвечает этим критериям то её нельзя брать в спринт.
Ну так об этом и речь. Вот поставил вам ваш стэкхолдер у задачи самый высокий приоритет, а она «не отвечает критериям». И что вы будете делать: не возьмёте в спринт высокоприоритетную задачу или возьмёте в спринт задачу, которая «не отвечает критериям»?
У нас в спринте всегда были задачи которые должны быть сделаны в определённом порядке.
А у нас не всегда. И что, у нас теперь не аджайл из-за этого был?
Потому что например если заказчик не может/хочет по другому и готов за это платить, то это его дело и его деньги.
Конечно, пусть платит. Если стокхолдер не хочет сам открыть аккаунт в платежной системе для задачи «оплата товара», то добавьте новую задачу «открытие аккаунта» и делайте сами за его деньги. Но ни в коем случае нельзя брать в спринт задачу «оплата товара» если вы знаете что её невозможно начать делать.
Есть понятие статусы задачи. Эти статусы должны быть прописаны и все должны их знать наизусть. Допустим: В анализе, Готова к спринту, В работе, Готова к тестам, Закончена и так далее. Все эти статусы должны подробно описаны. У нас был аналитик который готовил задачи к спринту и представлял их на планировании спринта. Если задача была не готова к спринту, то мы её не принимали. Или принимали с уточнениями. Допустим для страницы заказа он не знал если можно принимать заказы из других стран. В таком случае, добавляли уточнение, страница должна принимать заказ только в нашей стране. А потом уже аналитик выяснял с клиентом если нужно добавить другие страны. Но это уже будет другая задача.
У нас были разные задачи и зависимые и не зависимые. Мы всегда следовали здравому смыслу а не желанию отдельных программистов навыбирать лёгких задач
Но ни в коем случае нельзя брать в спринт задачу «оплата товара» если вы знаете что её невозможно начать делать.
Хм, вы вообще читаете что я вам пишу или сами с собой спорите? Я вам как раз и пишу что даже если какая-то задача высоко приоризированна стэкхолдером, то её всё равно не всегда удаётся добавить в спринт. Например потому что «бывают ситуации с зависимостями от каких-то внешних факторов(в том числе и от заказчика)»…
Есть понятие статусы задачи.
Есть такое понятие.
Эти статусы должны быть прописаны и все должны их знать наизусть.
Нет, не должны. Ну или процитируйте мне те части agile manifest/scrum guide где что-то подобное написано.
Подскажите, а когда производить освобождение от зависимостей и анализ, если задача не в спринте?
У нас были аналитики, дизайнеры, админы, у которых были свои спринты, цель которых была подготовить задачи. Сделать анализ, уточнить с клиентом детали, создать все нужное для для выполнения задачи, песочницы, стили, макеты.
Понятно что по ходу спринта всё равно у программистов появляются вопросы но такого чтобы задача блокировалась в начале спринта, такого не было
Груминг, плэнинг и т. п.
Груминг — вообще не про таски
Плэнинг — про распределение тасок.
Я же спрашивал про аналитику. Выше посоветовали их включать в спринты соответствующих аналитиков и т.п. В принципе, мне кажется, это может делить и разработчик, временно выстапающий в ролик аналитика. Но тогда надо выделять анализ задачи как отдельный этап/тикет и отдельно на него закладывать время.
Вот только вопрос коммуникации с другими командами, которые могут заблокировать тикет никуда не девается. Максимум — переходит на другого человека.
Груминг — вообще не про таски
Зато про аналитику. Ну то есть мы как раз на грумингах подобными вещами и занимались. То есть не только ими, но и ими в том числе.
Были ещё "спайки" — по сути исследовательско-аналитические задачи на оценку больших фич, причём прежде всего оценка вопроса достижимы ли они имеющимися ресурсами в принципе.
Вася по идее может декомпозировать большой монолит до scrum-driven tasks, это несложно делается
Я для себя сформулировал так — Agile Manifesto = идея, философия. Скрам и Канбан — это товар. Товар который нужно продать и у которого целевая аудитория (топ) менеджеры. При этом сознательно товар ретушируется под ожидания, делая акцент на плюсах и игнорируя минусы. Скрам подается под соусом — люди не важны, если вы используете правильные процессы (смотрим аджайл манифест, как там).
Скрам подается под соусом — люди не важны, если вы используете правильные процессы (смотрим аджайл манифест, как там).
Ну вот конкретно в этом пункте у меня совсем другой опыт. То есть во первых «продаётся» скрам обычно как раз таки под соусом «люди важны». То есть всякое «Individuals and interactions over processes and tools» и подобные вещи.
А во вторых на моей памяти всегда как минимум упоминалось что «скрам с кем попало не построишь и нужны люди, способные и готовые принять эту методику». А часто не просто упоминалось а повторялось в каждом втором-третьем предложении :)
Вам несказанно повезло, без всякой иронии. Из множества случаев в моём опыте и среди моих знакомых это ни разу не звучало со стороны внедрения или менеджеров. Опять же из моего опыта, с правильными людьми не так важно какой методологии придерживаться
Ну мне то повезло. А вот тем кто по той или иной причине попал в категорию "кто попало" обычно везло не особо.
То есть на моей памяти все случаи внедрения agile/scrum сопровождались увольнениями или "по собственному"...
И да, с правильными людьми в общем-то методология и процессы вторичны. Но вот только где взять столько правильных людей… :)
с правильными людьми не так важно какой методологии придерживаться
Именно. Скрам или не скрам — зависит от того, как именно в конкретном продукте приходят задачи. Если это B2C и, например, сервисный продукт — то будут постоянно сыпаться мелкие независимые хотелки от разных стейкхолдеров, и разумно делать так, чтобы каждую неделю-две очередная порция из них выходила на продуктив. Если каждая задача требует участия нескольких разных специалистов, то удобнее канбан — с ним проще оценивать, достаточен или избыточен задел на каждом этапе цепочки. И так далее. Но команда, её готовность двигать вот это все — всегда решает.
У меня от скрама самые негативные впечатления. Особенно запомнилось, как начальство поехало на какие-то тренинги, им там несколько недель полоскали мозги, а они уже всем остальным — все оставшееся время. Обсуждение стратегий разработки по существу заменяется на обсуждение каких-то баллов и нелепых оценок, всяческого дробления задач. Ломаются традиционные роли тестировщиков и разработчиков. Чем скорее это безумие будет отправлено на помойку истории вслед за XP, тем лучше.
НЛО прилетело и опубликовало эту надпись здесь
Вечная священная война на тему того, виновата ли методология сама по себе или виноваты те, кто ее неправильно используют.
На самом деле, эта дилемма — ложная, потому что методология не имеет смысла без практической реализации (она тогда существует только на бумаге). Любая современная методология, которая обкатана до определенной степени и не содержит в себе откровенных внутренних противоречий, может быть применена с положительным результатом в определенных условиях. Но ровно также она может быть применена наиболее часто встречающимся способом — в форме карго-культа, бессмысленного набора ритуалов. Получается ли из этого, что любая методология — провоцирует карго-культ? И да, и нет. Да — потому что большинство действительно склонны воспринимать методологии, как магические инструменты (это, вероятно, психологическая особенность людей, которую нельзя просто зачеркнуть). Нет — потому что если решения, связанные с внедрением методологии, принимают (редкие) люди, которые не склонны к карго-культу, методологии не портят, а помогают.
Это как задаваться вопросом о вреде моноцикла (одноколесного велосипеда). Люди с хорошей координацией и балансом отлично учатся на них кататься и получают удовольствие. Люди с худшими способностями или те, кто не желает тренироваться, а сразу хочет делать трюки, разбивают себе лицо, ломают руки и так далее. Только моноцикл — редкость, а методологии разработки — модное веяние, потому негативный эффект от них выражен куда сильнее.
На самом деле, эта дилемма — ложная, потому что методология не имеет смысла без практической реализации (она тогда существует только на бумаге). Любая современная методология, которая обкатана до определенной степени и не содержит в себе откровенных внутренних противоречий, может быть применена с положительным результатом в определенных условиях. Но ровно также она может быть применена наиболее часто встречающимся способом — в форме карго-культа, бессмысленного набора ритуалов. Получается ли из этого, что любая методология — провоцирует карго-культ? И да, и нет. Да — потому что большинство действительно склонны воспринимать методологии, как магические инструменты (это, вероятно, психологическая особенность людей, которую нельзя просто зачеркнуть). Нет — потому что если решения, связанные с внедрением методологии, принимают (редкие) люди, которые не склонны к карго-культу, методологии не портят, а помогают.
Это как задаваться вопросом о вреде моноцикла (одноколесного велосипеда). Люди с хорошей координацией и балансом отлично учатся на них кататься и получают удовольствие. Люди с худшими способностями или те, кто не желает тренироваться, а сразу хочет делать трюки, разбивают себе лицо, ломают руки и так далее. Только моноцикл — редкость, а методологии разработки — модное веяние, потому негативный эффект от них выражен куда сильнее.
Управление проектами и командами — сложная работа, которой равно также надо учиться, как и, например, разработке. Скрам — всего лишь одна из методологий и даже совершенное владение ею не делает менеджера хорошим управленцем. Вот и все. К сожалению, сейчас скрам все еще преподносится как серебряная пуля, но уже есть подвижки к понимаю, что это не так.
Совершенно согласен. Скрам очень похож на фреймворк с низким порогом входа для людей без опыта программирования. Просто бери и делай по бумажке, как дядя стрелочки нарисовал или на видео руками помахал. А на практике люди без образования и опыта управления молотят этим скрамом всё что ни попадя, и любое отклонение команды от идеала приводит к стопору всех процессов.
Главная проблема скрама это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Я много работал по скраму и в паре мест это было чрезвычайно эффективно. Тут же ошибки даже в первом абзатце статьи, там где «идея». Предлагаю каждому кто хочет рассуждать на тему и что-то внедрять, сдать сначала A-CSM на 95%+.
Я много работал по скраму и в паре мест это было чрезвычайно эффективно. Тут же ошибки даже в первом абзатце статьи, там где «идея». Предлагаю каждому кто хочет рассуждать на тему и что-то внедрять, сдать сначала A-CSM на 95%+.
В местах где скрам был крайне эффективен — каким образом боролись со "срезанием углов"? Кто отвечал за качество кода? Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить? Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?
В местах где скрам был крайне эффективен — каким образом боролись со «срезанием углов»?
Ругали провинившихся на
Кто отвечал за качество кода?
Тот кто его написал и тот кто его отревьюил. Иногда кроме самих команд были ещё люди, которые в том или ном виде следили за общей архитектурой, «качеством» кода и тестов и всякими подобными вещами.
Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить?
Некритичные баги ждали нового спринта. Под саппорт/критичные баги обычно просто резервировалось немного времени. Если саппорта/багов было слишком много, то спринт обрывался.
Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?
Здесь сложнее. Иногда сами команды. Иногда какие-нибудь архитекты/сениоры/core team или что-то в этом роде. Иногда какой-нибудь jour fix из представителей всех команд.
Фильм «Цельнометалическая Оболочка» смотрели? Суть как там. За все всегда всю команду наказывают. Не успели что-то сделать. Всей команде срезали премию. На проде что-то легло. Всей команде выговор. Ну и увольнять всю команду разом. Внутри команда сама разберется кто есть кто. Понятно дело что если вся команда проголосовала что кого-то хочет исключит из своих рядом то его надо для начала перевести в другую команда и если он и там уже не приживется то в целом отпускать на свободу.
Главная проблема скрама это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Главная проблема хорошего менеджмента это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
Agile — принципы, ценности.
Scrum — менеджерский фреймверк для удовлетворения этих ценностей. Список правил, иструкция. Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды. Если кто-то игнорирует — сыпется все. Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно. Ценой ограничения свободы членов команды (см менеджмент, sdlc).
Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды.
Не согласен. Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет. Проблема в том, что одного его недостаточно.
Если кто-то игнорирует — сыпется все
А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?
Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно
Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама. Ну и про то, что «строгое следование инструкциям» называется «итальянской забастовкой» я вообще молчу.
Ничего сложно, сакрального, чудесного и т.п. в этом нет.
Сложное в скраме — самоорганизация команды и взаимное доверие команды и остальных заинтересованных лиц.
Только Скрам тут не при чем. Это всегда нужно и всегда сложно независимо от методологии.
Других методологий, кроме аджайловых, я не припоминаю, где самоорганизованная команда — предусловие для внедрения.
Я пытаюсь сказать, что чтобы создать самоорганизованную команду с высоким уровнем доверия как внутри нее, так и извне к ней самой, методологий мало. Собственно, методологии и не описывают как это делать.
Это да, но я про то, что без этого скрам вообще не запустить нормально. Для него это маст хэв. Сначала добейтесь самоорганизации команды, а уж потом запускайте скрам. Если он ещё будет нужен. Ну или запуск скрама ставьте как эксперимент, как проверку команды на зрелость и готовьтесь издержки списать на убытки.
А с другой стороны есть методологии нормально работающие при самоорганизации на уровне "каждому разработчику погонщика с кнутом".
Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет.
Это вам они просты и понятны, а а кому-то (многим) не очень. Там и правда нет ничего сакрального, это просто хорошо прописанные инструкции.
А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?
А если игнорируют, но понимают зачем и почему и, внезапно, все сыпется, тогда что?
Если без шуток, то это другой уровень осознанности, когда на первом месте values & goals. Если ценность, нужная конкретному продукту — очень быстрое деливери, быстрее чем у конкурентов, а какие-то из установленных правил этому мешают, православно будет процессы подкорректировать под конкретные цели. Четкие цели, правильные ценности — это то, чего не хватает многим коллективам для хорошей продуктивности.
Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама
Ну так «Управление проектом» — это вообще гораздо больше, чем прсто следование инструкциям. Речь шла о Скраме — там есть набор правил, которым нужно следовать. Если вы выбрали Скрам, работайте по Скраму. Если вы сели за штурвал самолета, то пользуйтесь инструкцией по управлению самолетом, а не самосвалом.
Удивлен таким количеством негатива по поводу скрама и аджайл методологии. В моем личном опыте переход к любому аджайл подходу обычно приводил к позитивным изменениям в команде, даже в очень трудной и нездоровой (хотя не решал ее проблемы, конечно же).
Но мне вот интересно, а какие подходы люди применяют кроме них? По какой методологии делают проекты? Неужели waterfall еще жив, когда аналитики планируют релиз несколько месяцев, а потом команда делает заранее изготовленные задачки? И что еще есть, у меня какие-то пробелы в этом месте.
Но мне вот интересно, а какие подходы люди применяют кроме них? По какой методологии делают проекты? Неужели waterfall еще жив, когда аналитики планируют релиз несколько месяцев, а потом команда делает заранее изготовленные задачки? И что еще есть, у меня какие-то пробелы в этом месте.
Хочу вам задать такой же вопрос, как и в предыдущем комментарии.
В вашем личном опыте:
- Каким образом боролись со "срезанием углов"?
- Кто отвечал за качество кода?
- Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить?
- Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?
Мне действительно любопытен опыт людей, которые успешно применяли именно textbook scrum.
Говорить буду про мой текущий проект:
1. Никто особенно с этим не борется, потому что такого не замечали. Программисты все крутые, все хотят делать хорошо, нет оценки работы программиста по количеству тикетов. Так же у нас есть правило двух аппрувов на каждый PR, соответственно, если срежешь угол, тебе вежливо на это укажут и предложат помощь правильно все сделать. Тут еще и особенность Ruby-коммьюнити, пока идеально не сделаешь архитектуру изменения, аппрува не получишь.
2. Не совсем понимаю этот вопрос. По-моему, всегда за качество кода отвечает программист, который его пишет. Не знаю, как на это ответить. Я вот код написал, и мне будет стыдно если ребята увидят, что я там где нить накостылял. Если надо делать костыль (типа слишком сложно получается, или надо что то сначала переделать, но не до того сейчас), собираем колл с заинтересованными людьми и решаем, готовы ли вложится в большой рефакторинг или костыль пока сгодится. Опять же, все люди адекватные и обычно всегда находится удовлетворяющий всех подход.
3. У нас спринт длился неделю (мы сейчас на какое-то подобие канбана перешли), и если появлялись баги, которые надо срочно починить, то их ставили поверх всех тасков, чтобы желающие могли взять. У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке. Это вроде никак не мешало, тестирования, как отдельного шага у нас нет, все покрывается тестами, которые тоже проходят ревью, деплоится изменение сразу после всех аппрувов и прогонки тестов на circle ci.
4. Настоящего технического долга (когда архитектурные проблемы требуют переделки системы) я не припомню, чтобы как-то особо накапливалось. Пару раз вначале было такое — какой-то человек говорил — блин, надо тут переделать все. Начинал долбить тех лида, собирал людей обсудить, все смотрели и говорили, да, тут было бы неплохо все подчистить. В итоге создавали эпик и тех лид пробивал его с командой менеджмента, начинали добавлять таски в спринты.
Сейчас основная проблема — надо поддерживать все джемы, все системы в обновленном состоянии, и не всегда это просто сделать. Для этого мы в итоге мы поменяли процесс, теперь разработчики могут завести таску с описанием в специальный беклог в джире, откуда на встрече по приоритезации менеджеры достают задачки, обсуждают их импакт и добавляют какое-то количество в спринт. Ну и мы провели серию воркшопов, обсуждали все животрепещущие темы для разработки и создали роадмэп, по которому большие технические темы выделены в эпики, которые периодически добавляются в скоуп.
Вообще, на мой взгляд, textbook scrum — довольно утопичная идея, и если подходить к нему как к священной корове, да еще если руководство все свои старые замашки в него принесет, очень может стать токсично работать в коллективе.
Выше правильно сказали, что единственная задача Scrum — создать быструю обратную связь к команде, чтобы она могла выстраивать процессы под свои запросы и стиль работы. И конечно же, люди. Люди должны быть адекватными, особенно руководство. Если начальник бегает с табличками количесва закрываемых тикетов, хорошего не жди :)
Мне с этим вот повезло. В текущем, самом моем лучшем проекте, спрашивается только грубый эстимейт в неделях на эпик и он не проверяется потом, когда сделаете, тогда сделаете. Иногда интересуются, не нужна ли помощь, если команда эпика сильно уж запозднилась. Нет никаких особых дедлайнов, главное — do the right thing. Бывали случаи, когда понимали, что фичу делать сложно и, главное, она не принесет какой-то уж большой пользы, заворачивали на полпути. Никакой оценки программиста нет, все итак все друг про друга знают. Ну и тех лид (он сейчас уже поднялся до руководителя всего проекта), очень крутой и адекватный, не давит не отсвечивает и требует от всех только одного — чтобы в каждый момент времени человек делал правильную вещь, которая сейчас наиболее важна.
1. Никто особенно с этим не борется, потому что такого не замечали. Программисты все крутые, все хотят делать хорошо, нет оценки работы программиста по количеству тикетов. Так же у нас есть правило двух аппрувов на каждый PR, соответственно, если срежешь угол, тебе вежливо на это укажут и предложат помощь правильно все сделать. Тут еще и особенность Ruby-коммьюнити, пока идеально не сделаешь архитектуру изменения, аппрува не получишь.
2. Не совсем понимаю этот вопрос. По-моему, всегда за качество кода отвечает программист, который его пишет. Не знаю, как на это ответить. Я вот код написал, и мне будет стыдно если ребята увидят, что я там где нить накостылял. Если надо делать костыль (типа слишком сложно получается, или надо что то сначала переделать, но не до того сейчас), собираем колл с заинтересованными людьми и решаем, готовы ли вложится в большой рефакторинг или костыль пока сгодится. Опять же, все люди адекватные и обычно всегда находится удовлетворяющий всех подход.
3. У нас спринт длился неделю (мы сейчас на какое-то подобие канбана перешли), и если появлялись баги, которые надо срочно починить, то их ставили поверх всех тасков, чтобы желающие могли взять. У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке. Это вроде никак не мешало, тестирования, как отдельного шага у нас нет, все покрывается тестами, которые тоже проходят ревью, деплоится изменение сразу после всех аппрувов и прогонки тестов на circle ci.
4. Настоящего технического долга (когда архитектурные проблемы требуют переделки системы) я не припомню, чтобы как-то особо накапливалось. Пару раз вначале было такое — какой-то человек говорил — блин, надо тут переделать все. Начинал долбить тех лида, собирал людей обсудить, все смотрели и говорили, да, тут было бы неплохо все подчистить. В итоге создавали эпик и тех лид пробивал его с командой менеджмента, начинали добавлять таски в спринты.
Сейчас основная проблема — надо поддерживать все джемы, все системы в обновленном состоянии, и не всегда это просто сделать. Для этого мы в итоге мы поменяли процесс, теперь разработчики могут завести таску с описанием в специальный беклог в джире, откуда на встрече по приоритезации менеджеры достают задачки, обсуждают их импакт и добавляют какое-то количество в спринт. Ну и мы провели серию воркшопов, обсуждали все животрепещущие темы для разработки и создали роадмэп, по которому большие технические темы выделены в эпики, которые периодически добавляются в скоуп.
Вообще, на мой взгляд, textbook scrum — довольно утопичная идея, и если подходить к нему как к священной корове, да еще если руководство все свои старые замашки в него принесет, очень может стать токсично работать в коллективе.
Выше правильно сказали, что единственная задача Scrum — создать быструю обратную связь к команде, чтобы она могла выстраивать процессы под свои запросы и стиль работы. И конечно же, люди. Люди должны быть адекватными, особенно руководство. Если начальник бегает с табличками количесва закрываемых тикетов, хорошего не жди :)
Мне с этим вот повезло. В текущем, самом моем лучшем проекте, спрашивается только грубый эстимейт в неделях на эпик и он не проверяется потом, когда сделаете, тогда сделаете. Иногда интересуются, не нужна ли помощь, если команда эпика сильно уж запозднилась. Нет никаких особых дедлайнов, главное — do the right thing. Бывали случаи, когда понимали, что фичу делать сложно и, главное, она не принесет какой-то уж большой пользы, заворачивали на полпути. Никакой оценки программиста нет, все итак все друг про друга знают. Ну и тех лид (он сейчас уже поднялся до руководителя всего проекта), очень крутой и адекватный, не давит не отсвечивает и требует от всех только одного — чтобы в каждый момент времени человек делал правильную вещь, которая сейчас наиболее важна.
У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке.
А разве предсказуемость (в виду маленьких итераций) это не одна из фишек скрама (для заказчика)? А тут вы говорите, что у вас нету такой цели. Звучит весьма странно
На мой взгляд, маленькие итерации, прежде всего — это быстрая обратная связь, а не предсказуемость, возможность заметить отличие воображаемого идеального состояния проекта от его реальных показателей. Тут планировали сделать эту фичу за неделю, а чувак пыхтит уже две недели и явно пока еще не прорвался, что-то тут не так, давайте перепланируем и или отменим пару других запланированных эпиков и ему кинем парней на помощь или в принципе все норм, справится сам, скажем аналитикам, что этот A/B эксперимент будет запущен позднее.
Это позволяет управлять скоупом и ожиданиями продуктовой команды. А предсказуемость обычно задается как раз опытом самих разработчиков и их желанием быть профессиональными. Поскольку особо формальных требований и показателей нет, люди стараются сами определить скоуп (обычно на эпик выделяется микро-команда, выбирается разработчик, ответственный за эпик), договорится со всеми участника процесса и пытаться всех держать в курсе хода проекта и поднимать красный флаг, если где-то что-то поменялось.
Мне кажется, предсказуемость тут больше в постоянных пересмотрах и рефлексии на событиях, которые поддерживаются на уровне ритуалов (ретро и просто люди иногда темы поднимают). На моей памяти за эти почти 4 года в команде, процесс у нас поменялся с десяток раз.
Например, сначала было еженедельное планирование, когда оба офиса собирались все вместе онлайн через большой экран и обсждали состояние эпиков, сколько осталось, что новое добавляется, обычно эпик оунер рассказывал по каждому эпику. Потом в какй-то момент вылезло наружу, что народу что-то не нравится, а именно, что выходит, что мы просто отчитываемся перед менеджментом, никакое это не планирование, менеджмент может и почитать в джире и сам спланировать, а нам время не маза тратить.
Коллега-программист предложил эксперимент — а давайте вообще выкинем этот митинг и посмотрим, как нам без него. Попрессовали продакт команду, договорились с ними, что эпик оунер будет просто писатьв специальный слэк канал отчет по специальной форме — типа что сделали, что будем делать, сколько всего осталось делать. А митинг отменим нафиг.
Ну после трех недель собрались обсудить вместо планирования — как перемена. И программисты и менежеры согласились, что не хватает форума, где можно послушать, что поменялось, и задать вопросы. Договорились, что выкладывать репорты будем все равно, но рано, до 9:30, а на статус-митинге — переименовали его из планирования, в 10:00 на созвон заходят только эпик оунеры и те у кого есть вопросы, по очереди всем их задают. Выходит довольно быстро, кстати, на 7-10 эпиков и набора текущих задач без эпиков сейчас полчаса уходит, по старой процедуре — час. И главное, люди признали, что необходимость писать репорт заставляет обдумать, что происходит с эпиком и помогает собраться.
Пару месяцев уже так живем, вроде нормально
Это позволяет управлять скоупом и ожиданиями продуктовой команды. А предсказуемость обычно задается как раз опытом самих разработчиков и их желанием быть профессиональными. Поскольку особо формальных требований и показателей нет, люди стараются сами определить скоуп (обычно на эпик выделяется микро-команда, выбирается разработчик, ответственный за эпик), договорится со всеми участника процесса и пытаться всех держать в курсе хода проекта и поднимать красный флаг, если где-то что-то поменялось.
Мне кажется, предсказуемость тут больше в постоянных пересмотрах и рефлексии на событиях, которые поддерживаются на уровне ритуалов (ретро и просто люди иногда темы поднимают). На моей памяти за эти почти 4 года в команде, процесс у нас поменялся с десяток раз.
Например, сначала было еженедельное планирование, когда оба офиса собирались все вместе онлайн через большой экран и обсждали состояние эпиков, сколько осталось, что новое добавляется, обычно эпик оунер рассказывал по каждому эпику. Потом в какй-то момент вылезло наружу, что народу что-то не нравится, а именно, что выходит, что мы просто отчитываемся перед менеджментом, никакое это не планирование, менеджмент может и почитать в джире и сам спланировать, а нам время не маза тратить.
Коллега-программист предложил эксперимент — а давайте вообще выкинем этот митинг и посмотрим, как нам без него. Попрессовали продакт команду, договорились с ними, что эпик оунер будет просто писатьв специальный слэк канал отчет по специальной форме — типа что сделали, что будем делать, сколько всего осталось делать. А митинг отменим нафиг.
Ну после трех недель собрались обсудить вместо планирования — как перемена. И программисты и менежеры согласились, что не хватает форума, где можно послушать, что поменялось, и задать вопросы. Договорились, что выкладывать репорты будем все равно, но рано, до 9:30, а на статус-митинге — переименовали его из планирования, в 10:00 на созвон заходят только эпик оунеры и те у кого есть вопросы, по очереди всем их задают. Выходит довольно быстро, кстати, на 7-10 эпиков и набора текущих задач без эпиков сейчас полчаса уходит, по старой процедуре — час. И главное, люди признали, что необходимость писать репорт заставляет обдумать, что происходит с эпиком и помогает собраться.
Пару месяцев уже так живем, вроде нормально
Это одна из главных проблем со скрамом и ошибок управленцев — думать что скрам даст предсказуемость сроков. Он даете скорость обратной связи. Тобишь скрам не про «Мы сделаем это за 2 недели и точно сделаем». Начнем с того что в принцыпе в любой методологии неправильные сроки это обычное дело. Скрам про то что вместо «Мы думали что сделаем за год а сделали за 4» — «Мы думали что сделаем за 1 неделю а сделали за 4 недели»
Ну там механизм для оценки сроков в принципе есть, но в реальных условиях он работает довольно плохо. Чтобы оценить велосити нужно провести 2-3 спринта. Поидее этого достаточно чтобы понять производительность команды и разделитьимеющийся скоп на велосити, но есть одно большое «но». Но за 2-3 спринта(обычно это примерно 1,5 месяца) — с командой что-нибудь происходит — кто-то заболел, ушел в отпуск, уволился, кого-то наняли — и оценивать нужно заново и из-за этого оценка становится перманентной и становится очень сложно её зафиксировать на какой-нибудь продолжительный срок.
А и не надо на продолжительный срок фиксировать. Предполагается, что велосити изменяется в норме в сторону увеличения за счёт устранения помех по результатам ретро, при заболел/отпуск/уволился/наняли — в сторону уменьшения проседает.
Мне нравится подход, когда берётся скользящее среднее за последние пару месяцев для грубой оценки что внести в бэклог спринта.
Как и не надо давать оценки когда имеющийся скоп будет закончен. Поскольку предполагаетс
Баги влетающие в середине спринта, треть задач спринта остаются неисполненными… а это точно можно называть скрамом?
Я не знаю. Я знаю точно, что это аджайл процесс, когда команда сама себя и свои процессы перестраивает. Началось все с типичного scrum, а сейчас это что-то канбаноподобное — у нас спринтов больше нет, это, как мне кажется, кстати, влияние работы из дома в течении 4-х месяцев.
Я еще раз повторюсь, что я думаю, что как раз четко следовать скраму не обязательно, были тут разговоры из серии «это не настоящий скрам» — это не про то, я думаю, имелось в виду просто соблюдение некоторых базовых принципов, сама форма не так уж важна, какова длина спринта или какие встречи проходят в течении спринта.
Просто скрам дает некоторую рамку, некий шаблон, с которого можно начать. А главная идея этого шаблона — быстрая обратная связь и возможность изменения ритуалов и процессов команды.
А дальше все зависит от команды и их доверия к друг другу, могут устроить карго-культ, а могут и создать cohesive коллектив, который не нужно будет особенно микроменеджить. People management никто не отменял, собственно, мне кажется, одна из важнейших черт аджайла — это опора на людей, которые смелы и которые связываются друг с другом сами, порождая инновации и качество.
Я еще раз повторюсь, что я думаю, что как раз четко следовать скраму не обязательно, были тут разговоры из серии «это не настоящий скрам» — это не про то, я думаю, имелось в виду просто соблюдение некоторых базовых принципов, сама форма не так уж важна, какова длина спринта или какие встречи проходят в течении спринта.
Просто скрам дает некоторую рамку, некий шаблон, с которого можно начать. А главная идея этого шаблона — быстрая обратная связь и возможность изменения ритуалов и процессов команды.
А дальше все зависит от команды и их доверия к друг другу, могут устроить карго-культ, а могут и создать cohesive коллектив, который не нужно будет особенно микроменеджить. People management никто не отменял, собственно, мне кажется, одна из важнейших черт аджайла — это опора на людей, которые смелы и которые связываются друг с другом сами, порождая инновации и качество.
splatt похоже тебя сертифицированные скрам-мастера не понимают о чем ты спрашиваешь. думают что это само-собой как-то делается. или добавим 2 ревьювера на один PR и этого достаточно.
лично мне приходилось отвечать за данные вопросы, но опять же по личной инициативе.
лично мне приходилось отвечать за данные вопросы, но опять же по личной инициативе.
Из аджайла кроме скрама есть еще канбан.
Я, конечно же, имел в виду «что, кроме аджайла». Я вот только ватерфолл знаю
В основе аджайл и ватерфол лежит на мой взгляд один и тот же цикл проектного управления, просто в аджайле он повторяется очень много раз, а в ватерфол 1 раз за весь проект. Соотв. всё что кроме аджайла и ватерфолл может быть посредине между этими крайностями, например, квартальный проект разбитый на 3 месячных этапа, на каждом из месячных этапов будет ватерфолл.
Вы не туда смотрите. Грубо гoворя водопад исходит из того что можно получить полноценное ТЗ ещё до старта проекта. А аджайл нужен когда полноценное ТЗ до начала проекта не получить и оно создаётся/дополняется в ходе проекта.
Чего это вдруг? Например, если я делаю интернет-магазин и заказываю у некого подрядчика сначала витрину, прописываю всё ТЗ и он уходит на месяц его пилить и приносят результат. Пока он пилит — я прописываю ТЗ на корзину и страницу заказов. И потом еще так же модуль кросс-сейлз и рекомендаций. Это что? Аджайл? Ватерфол?
Ну если опять же совсем грубо, то если «ТЗ на корзину и страницу заказов» зависит от того как будет сделана «витрина» или от какой-то информации, полученной во время того как витрина делается, то вам нужен аджайл.
Если вы в теории сразу можете написать оба ТЗ(но не делаете это например из-за нехватки времени), то аджайл вам в общем-то не нужен и вам хватит водопада.
Если вы в теории сразу можете написать оба ТЗ(но не делаете это например из-за нехватки времени), то аджайл вам в общем-то не нужен и вам хватит водопада.
Интересно, основываясь на каких определениях аджайла и водопада вы делаете такие утверждения? Потому что на мой взгляд я описал достаточно типовую ситуацию и примерно равноудалённую от чистого водопада и чистого аджайла.
Интересно, основываясь на каких определениях аджайла и водопада вы делаете такие утверждения?
Я делаю такие утверждения основываясь на истории возникновения аджайла и банальной логикe. Если у вас есть полноценное и окончательное ТЗ, то аджайл вам просто не нужен. И в такой ситуации аджайл это скорее всего просто ненужный оверхэд и лишние задержки и/или расходы.
Потому что на мой взгляд я описал достаточно типовую ситуацию и примерно равноудалённую от чистого водопада и чистого аджайла.
В каком месте она «удалённая»?
Если у вы с самого начала в состоянии написать ТЗ сразу на весь проект целиком(витрина, корзина, кросс-сейлз, рекомендации), то это самый обыкновенный водопад.
Если вы не в состоянии этого сделать и информацию, необходимую для полноценного ТЗ, вы каким-либо образом получаете во время выполнения проектa, то тут уже требуется возможность реагировать на изменения. И следовательно вам водопад не подходит и нужна альтернатива. Например тот самый аджайл.
Т.е. вы основываетесь на каком-то своём видении аджайла, а не на конкретном определении. Какой смысл тогда обсуждать, что является аджайлом, если вы это слово можете по своему понимать?
А вы где-то в определении аджайла вообще видите что-то о том где его можно применять? И что тогда, получается его нигде вообще нельзя применять?
Естественно вы можете использовать аджайл где угодно. И водопад вы можете использовать где угодно. И гвозди микроскопом вам никто не может запретить забивать. Вопрос в том где логично и рационально использовать одно, а где другое. И если у вас в вашем «типе» проекта от аджайла нет никаких плюсов и только оверхэд, то зачем его использовать? Просто потому что это сейчас модно?
Естественно вы можете использовать аджайл где угодно. И водопад вы можете использовать где угодно. И гвозди микроскопом вам никто не может запретить забивать. Вопрос в том где логично и рационально использовать одно, а где другое. И если у вас в вашем «типе» проекта от аджайла нет никаких плюсов и только оверхэд, то зачем его использовать? Просто потому что это сейчас модно?
В каком определении? Есть, например, «The Manifesto for Agile Software Development». И написано там совсем не «аджайл нужен когда полноценное ТЗ до начала проекта не получить».
Ну да, там написано:
Эта формулировка по вашему принципиально отличается от «когда полноценное ТЗ до начала проекта не получить»?
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Эта формулировка по вашему принципиально отличается от «когда полноценное ТЗ до начала проекта не получить»?
Во-первых это всего лишь 1 из 12 принципов.
Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.
На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.
На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
Во-первых это всего лишь 1 из 12 принципов.
И что? То что он один из двенадцати не значит что его можно игнорировать когда вы создаёте/выбираете аджайл-методику. То есть ваша методика должна этому соответствовать.
И если вам это не надо, то зачем вам тогда нужен аджайл?
И на втором месте его тоже не просто так поставили.
Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.
Эээ, и в чём по вашему эта разница заключается? Если вы можете до начала проекта предоставить полноценное и окончательное ТЗ, то это значит никаких изменений требований уже не будет. Ни на поздних стадиях, ни на ранних. Просто не будет и всё.
А если у вас в какой-то момент всплывают эти самые «изменения требований», то это значит что ваше ТЗ не было полноценным и окончательным.
На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
А это вообще о чём и к чему? Если у кого-то окончательное и полноценное ТЗ выглядит дословно как «транспортное средство с колёсами», то вы ему можете и самолёт предлагать и велосипед. А если он имел ввиду что-то другое, то надо ТЗ было грамотно составлять. Или не надо было заявлять что оно окончательное и полноценное.
И что? То что он один из двенадцати не значит что его можно игнорировать когда вы создаёте/выбираете аджайл-методику.
Выбирая аджайл-методику надо смотреть не один из 12 принципов, а всю их совокупность.
вы ему можете и самолёт предлагать и велосипед
Не обязательно аджайл в каждое место, где не могут сразу составить окончательное ТЗ. Как не обязательно самолёт в каждое место, где нужны колёса. Может там ни места под ВПП нет, ни денег на обучение пилотов.
Я к тому, что выбирая аджайл-методику надо смотреть не один из 12 принципов, а всю их совокупность.
Если у вас уже один из 12 принципов создаёт ненужный оверхэд, то зачем смотреть на остальные 11?
Я и говорю, что не обязательно аджайл в каждое место, где не могут сразу составить окончательное ТЗ.
Вы сравнили конкретно аджайл и водопад. И на мой взгляд это сравнение было некорректно и если мы берём именно эти две методики, то разница в первую очередь именно в первом-втором пунктах аджайл манифеста. Причём в основном во втором.
Остальные пункты по хорошему точно так же могут быть применимы и к водопаду.
Не понимаю, почему именно взгляд с рекомендуемоей Вами стороны должен быть единственно верным. Слон с разных сторон по разному выглядит и врядли правильно говорить, что нужно на слона смотреть только сбоку или только сверху.
Я не знаю является ли он единственно верным и вообще как в данном случае определять критерии этой самой «верности взгляда». Но он как минимум рациональный. Но как я уже писал выше, в общем-то вам никто не может запретить в любой ситуации использовать аджайл или водопад или ещё что-то.
Нужно различать "можно применить" скрам/канбан/водопад и "лучше всего применить".
Если изменения ожидаются, то скрам хороший кандидат, что не делает его автоматически плохим, если не ожидаются.
Нецелесообразно на основе только лишь «изменения ожидаются» делать выбор в пользу скрама. Более того, если «поток изменений валится без остановки» и в нём есть как крупные, так и мелкие задачи, то как раз скрам может быть сильно хуже канбана, т.к. канбан позволяет переигрывать что угодно до непосредственно взятия задачи в работу, а скрам говорит, что вот спринт начался — не трогай его.
Нужно различать «можно применить» скрам/канбан/водопад и «лучше всего применить».
Хм, а есть вот прямо ситуации когда вот прямо нельзя применить аджайл или водопад? Мне что-то такие в голову не приходят.
Если изменения ожидаются, то скрам хороший кандидат, что не делает его автоматически плохим, если не ожидаются.
Вообще-то делает. Потому что тогда действительно тратится куча времени на ненужные митинги и денег на «лишних людей».
Например зачем вам нужны рефайнменты, плэннинги, грумминги каждый спринт если это всё можно сделать в более короткой форме до старта проекта? Зачем вам ревью каждый спринт если можно один раз показать конечный результат клиенту? Зачем вам ПО, который будет постоянно и интенсивно общаться с клиентом, если можно взять обычного менеджeра, который будет с ним общаться только на старте/финише проекта? Зачем оплачивать скрам-мастера в конце-концов?
Ну, аджайл нельзя применить, если в начальных требованиях есть пункты противоречащие его принципам. Например, если заказчик говорит "Мне главное, чтобы документация была не подкопаешься, и хоть какой-то продукт, пускай и практически не работающий"
Например, для повышения привлекательности проекта для определенного типа разработчиков или для определенного типа инвесторов.
Совершенно стандартная итеративная разработка. А, может, спиральная. Их много разных и одними Водопад/Скрам/Канбан список не ограничивается.
Водопад, по первоисточникам, вроде как не настаивает на одном цикле. Просто циклы в нём могут длиться месяцами, а то и годами.
Не буду говорить за кого-то, скажу за себя.
Проблемы в как таковом Scrum'е нет. Хотя, сейчас все больше и больше аргументированно агитируют за Канбан, как фреймворк, который максимально сокращает релизный цикл.
Проблема в том, что этот Скрам преподносится, как серебряная пуля. Как будто внедрив Скрам внезапно команды преобразятся и начнут деливерить.
И многие менеджеры этому верят. И потом приходит к команде такой менеджер, который нифига не умеет, не знает, с командой контакта найти не может, и, несмотря на наличие daily, не понимает чем команда реально занята и говорит, что Скрам нас всех спасет.
Мне повезло (и это реально везение) иметь опыт работы с реально эффективными PM'ами, которые и наберут группу людей, и сделают эту группу командой, и будут с заказчиком эффективно коммуницировать, и команду слушать. И, что характерно, Скрам им не нужен. Просто потому, что ритуалы Скрама — лишь малая часть их работы.
Проблемы в как таковом Scrum'е нет. Хотя, сейчас все больше и больше аргументированно агитируют за Канбан, как фреймворк, который максимально сокращает релизный цикл.
Проблема в том, что этот Скрам преподносится, как серебряная пуля. Как будто внедрив Скрам внезапно команды преобразятся и начнут деливерить.
И многие менеджеры этому верят. И потом приходит к команде такой менеджер, который нифига не умеет, не знает, с командой контакта найти не может, и, несмотря на наличие daily, не понимает чем команда реально занята и говорит, что Скрам нас всех спасет.
Мне повезло (и это реально везение) иметь опыт работы с реально эффективными PM'ами, которые и наберут группу людей, и сделают эту группу командой, и будут с заказчиком эффективно коммуницировать, и команду слушать. И, что характерно, Скрам им не нужен. Просто потому, что ритуалы Скрама — лишь малая часть их работы.
НЛО прилетело и опубликовало эту надпись здесь
обсуждение скрама сродни обсуждению рецепта плова — каждый знает как правильно, а у остальных рисовая каша с мясом.
Ну мне кажется что это не такая частая проблема — все же полностью скрам применяется не полностью, остаётся место для здравого смысла.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну если выгнать гения из бункера и все таки направить его в правильном направлении, то скорость вырастет как следствие :)
Скорость чего? Скорость написания кода может и упасть, если человека выгнать из комфортных для него условий.
Возможно скорость написания кода этим «гением» действительно упадет. Так как ему придётся заниматься не чем тем ему нравится, а тем, что нужно работодателю. Но мы же с вами не в детском саду. На работе нужно Работу работать. И давайте не будем забывать что в постановке вопроса она была около нулевой для работодателя.
Как я понимаю, в постановке вопроса он месяц работал над тем, что было нужно бизнесу, а по истечению месяца уже оказалось не очень. А скрам предлагается как способ сократить этот срок до недели-двух.
Скрам, как и любой правильно поставленный метод управления и контроля, в этом случае повышает коммуникацию и позволяет скорректировать деятельность работника в нужном работодателю направлении. При правильной организации этих коммуникаций косвенно снижается время разработки продукта, например в виду того, что кода выкидывается меньше.
В правильно настроенном waterfall такая ситуация тоже невозможна — когда разработчик месяц фигарит что то понятное ему одному и это потом выкидывается.
На мой взгляд проблема не в скраме, а в людях, которые полностью упускают из виду другие аспекты разработки, кроме как регулярное и прогнозируемое закрытие тикетов на мелкие задачи.
На мой взгляд проблема не в людях. Люди — они просто стремятся делать то, что приносит им наибольшую личную выгоду. То есть — поступают именно так, как принято среди людей из современного общества.
Это работа менеджмента — сделать так, чтобы наибольшую личную выгоду сотрудникам приносили (или, хотя бы, казалось что приносят — тоже вариант) те действия, которые приносят выгоду предприятию.
Это работа менеджмента — сделать так, чтобы наибольшую личную выгоду сотрудникам приносили (или, хотя бы, казалось что приносят — тоже вариант) те действия, которые приносят выгоду предприятию.
Мне нравятся ответы: если СКРАМ не работает, то это не СКРАМ :)))
На мой взгляд такие ответы очень хорошо характеризуют СКРАМ. Это говорит о том как реальные люди интерпертируют эту методологию. Это значит, что методология не очень прозрачна, не имеет внятных ответов на наиболее сложные моменты методологии. Т.е. не решает те проблемы которые должна решать.
Методология достаточно прозрачна, но реальные люди очень часто не хотят её имплементировать полностью. Например, менеджмент не просто присутствует на дэйли-митингах, но и активно в них участвует. Или при изменении скоупа спринта не отменяют спринт и начинают новый, а продолжают старый. Цели спринта не формулируют. Ну или формулируют просто как копи-паст всех задач.
Проблема Scrum в мотивации в долгосрочной перспективе.
Команда наемных программистов в итоге просто делает все медленно, так как в скорости заинтересован лишь владелец/клиент (про качество скажут пару раз — теперь это забота разработки — кто уже это вспомнит через год-два?..). И многие даже не заметят этого, если не будут иметь аудит или консалтинг. Не заметят, пока бюджет не будет превышен или продукт не будет очень плохим (про качество владелец/клиент уже вспомнит, когда получит отток пользователей и придет «разбираться»).
Можно тут сказать про премию и нематериальные поощрения — инженер, который проработал с этим 10 лет, просто будет улыбаться и очень убедительные доводы приводить. Уходить по часам — ведь он и так другую работу найдет, если что. И будет скрам-мастер всякую дичь предлагать, будут совещаться… Банкротство.
Именно поэтому я придумал более совершенный фреймворк, чем Scrum, Kanban, Scrumban, SAFe, LeSS, DaD… Намного проще, намного приятнее. Без подмены понятий. Обкатываю сейчас. Пока полет отличный. Если смогу убедиться, что все в рамках моих ожиданий, то поделюсь с миром и мир вздохнет с облегчением.
Команда наемных программистов в итоге просто делает все медленно, так как в скорости заинтересован лишь владелец/клиент (про качество скажут пару раз — теперь это забота разработки — кто уже это вспомнит через год-два?..). И многие даже не заметят этого, если не будут иметь аудит или консалтинг. Не заметят, пока бюджет не будет превышен или продукт не будет очень плохим (про качество владелец/клиент уже вспомнит, когда получит отток пользователей и придет «разбираться»).
Можно тут сказать про премию и нематериальные поощрения — инженер, который проработал с этим 10 лет, просто будет улыбаться и очень убедительные доводы приводить. Уходить по часам — ведь он и так другую работу найдет, если что. И будет скрам-мастер всякую дичь предлагать, будут совещаться… Банкротство.
Именно поэтому я придумал более совершенный фреймворк, чем Scrum, Kanban, Scrumban, SAFe, LeSS, DaD… Намного проще, намного приятнее. Без подмены понятий. Обкатываю сейчас. Пока полет отличный. Если смогу убедиться, что все в рамках моих ожиданий, то поделюсь с миром и мир вздохнет с облегчением.
Ну да, философию скрама можно выразить в максиме «а-а-а-а, херачим-херачим-херачим!», с таким подходом сложновато поддерживать огонь в глазах.
Именно поэтому я придумал более продвинутый фреймворк, который дает средний стабильный результат как в краткосрочной, так и в долгосрочной перспективе. Обкатываю.
Это откуда такая философия?
Следует из названия Scrum и его принципов. Товарищ все верно написал.
Scrum изначально сделан для авральной ситуации, когда стейкхолдеров много, когда стейкхолдеры не могут или не хотят договариваться, нет понимания ограничений (capacity), нужно быстро делать изменения, качество приносится в жертву частым релизам (именно так — достаточно почитать Scrum: The Art of Doing Twice the Work in Half the Time — к слову, в книге нет ни слова про то, как продукт поддерживался после разработки, а это очень хитрый и важный момент).
Scrum изначально сделан для авральной ситуации, когда стейкхолдеров много, когда стейкхолдеры не могут или не хотят договариваться, нет понимания ограничений (capacity), нужно быстро делать изменения, качество приносится в жертву частым релизам (именно так — достаточно почитать Scrum: The Art of Doing Twice the Work in Half the Time — к слову, в книге нет ни слова про то, как продукт поддерживался после разработки, а это очень хитрый и важный момент).
Что, опять? Скрам — это инструмент, а не священный грааль, типа, применил и бац, производительность 120%, все счастливы, а код идеальный. Если молоток дать дураку, что будет? Чтобы все это работало, нужны люди, которые могут правильно это использовать либо адаптировать с изменениями для текущей команды, проекта, задач.
Методик управления проектами и разработкой много. В каждом конкретном случае нужно выбирать ту, которая максимально подходит для достижения цели, а не, как дурачок: " с завтрашнего дня мы работает по SCRUM!", потому что, кто то сказал, что сразу будет успех.
Методик управления проектами и разработкой много. В каждом конкретном случае нужно выбирать ту, которая максимально подходит для достижения цели, а не, как дурачок: " с завтрашнего дня мы работает по SCRUM!", потому что, кто то сказал, что сразу будет успех.
НЛО прилетело и опубликовало эту надпись здесь
А что такое скрам?
Защитники скрама видят причину неприятностей в плохом менеджменте. Вот что говорит пользователь Llewellyn, подводя итоги: «Менеджмент, по сути, игнорирует разработчиков. Существуют фиксированные дедлайны, которые нужно выдержать, достигнув заранее заданных результатов. Работой занимается не команда, сосредоточенная на достижении одной и той же цели, а группа людей, в которой каждый беспокоится лишь о себе. ...».
На мой взгляд, это и есть основная проблема скрама. Только источник проблемы — не менеджмент, а проблема тут — объективная. Потому что, если подойти к вопросу чисто материально, то работой ведь объективно занимается как раз не команда, объединенная общим материальным интересом, а группа людей, каждый из которых имеет свой интерес.
Команда была бы, если бы разработчики были объединены во что-то вроде самостоятельной артели — которая подрядилась сделать разработку для предприятия за оговоренную плату, которая коллективно отвечает за результат, и которая сама определяет кому из своих членов сколько платить, кого надо принять, а кого — и уволить. Вот у такой команды был бы общий интерес, который бы объединял ее.
А в современных реалиях разработки уровень оплаты каждого разработчика (и будет ли он вообще работать) определяется на индивидуальной основе, менеджментом фирмы (по договоренности с самим разработчиком, естественно). Поэтому общего материального интереса у группы разработчиков нет. А отсюда проистекают неизбежные трудности эффективного использования методик, рассчитанных на управление разработчиками как коллективом, в том числе — и скрамом: сложно побудить людей (к тому же — образованных, а потому неглупых), что они должны действовать вопреки своим материальным интересам.
у скрама есть 2 проблемы:
1. постоянные дедлайны.
как результат — постоянный стресс в разработке. менеджеры предпочитают игнорировать этот момент, как несущественный. как по мне, многие выгорания в среде разработчиков происходят, по этой причине.
2. сертифицированные скрам-мастера. встречаются достаточно агрессивные поборники скрама, слепо следующие канонам учения. при этом слабо понимающие почему скрам предписывает что-то делать. и даже не догадываются, что еще много чего в скраме просто не описано. постоянный пушшинг разработчиков. давай, давай, давай. манипуляции.
по первому пункту я бы советовал разработчикам работать над снижением личной ответственности и лучше планировать задачи на спринт. например, веделять неделю на бизнес задачи, неделю — на ревью и исправление реализованой части.
второй пункт исправить не возможно.
чего мне в скраме не хватает, так это Tech Owner-ра. который мог бы корректировать разработку с технической стороны. кто-то пытается это делать, но как правило на уровне Team Lead/Tech Lead/Architect.
1. постоянные дедлайны.
как результат — постоянный стресс в разработке. менеджеры предпочитают игнорировать этот момент, как несущественный. как по мне, многие выгорания в среде разработчиков происходят, по этой причине.
2. сертифицированные скрам-мастера. встречаются достаточно агрессивные поборники скрама, слепо следующие канонам учения. при этом слабо понимающие почему скрам предписывает что-то делать. и даже не догадываются, что еще много чего в скраме просто не описано. постоянный пушшинг разработчиков. давай, давай, давай. манипуляции.
по первому пункту я бы советовал разработчикам работать над снижением личной ответственности и лучше планировать задачи на спринт. например, веделять неделю на бизнес задачи, неделю — на ревью и исправление реализованой части.
второй пункт исправить не возможно.
чего мне в скраме не хватает, так это Tech Owner-ра. который мог бы корректировать разработку с технической стороны. кто-то пытается это делать, но как правило на уровне Team Lead/Tech Lead/Architect.
я бы советовал разработчикам работать над снижением личной ответственности
Скрам больше про коллективную отвественность.
Tech Owner-ра. который мог бы корректировать разработку с технической стороны
Можно попробовать решить через DoD. Нет апрува от Tech Owner — задача не сделана.
коллективная ответственность складывается из личной ответственности членов команды. и не нужно забывать, что в компаниях отсутствуют бонусы за колективный вклад в работу. так что на словал менеджеры декларируют командную работу, а по факту — работает группа разработчиков. с постоянной текучкой, по другому и не получиться.
задача уже давно могла пройти DoD. а при наличии какой-нибудь новой задачи может потребоваться пересмотреть ее решение. в таком случае PO не поможет. нужна техническая экспертиза, и решение каким образом реализация новой задачи должна повлиять на текущую имплементацию.
например, задачу можно сделать за 1 неделю, но тех лид советует потратить 1-2 недели на рефакторинг существующего кода, а потом приступить к реализации задачи. PO как правило выбирают первый вариант.
задача уже давно могла пройти DoD. а при наличии какой-нибудь новой задачи может потребоваться пересмотреть ее решение. в таком случае PO не поможет. нужна техническая экспертиза, и решение каким образом реализация новой задачи должна повлиять на текущую имплементацию.
например, задачу можно сделать за 1 неделю, но тех лид советует потратить 1-2 недели на рефакторинг существующего кода, а потом приступить к реализации задачи. PO как правило выбирают первый вариант.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют?