company_banner

Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют?

Автор оригинала: Medi Madelen Gwosdz
  • Перевод
Недавно наше внимание привлёк один вопрос, заданный на stackexchange.com. Этот вопрос был направлен на то, чтобы разобраться с влиянием скрама на работу программистов. Автор вопроса, пользователь Qiulang, поднимает довольно смелую тему: «Скрам превращает хороших разработчиков в программистов средней руки. Возможно ли это?».

Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?



Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.

Является ли скрам причиной появления плохих практик разработки, или он лишь служит оправданием для этой проблемы?


Много споров вызвали рассуждения о воздействии скрама на команды и отдельных разработчиков, и об ограничениях, которые этот фреймворк налагает на тех, кто его использует. В то время как многие винят скрам в неудачах команд, другие полагают, что это — ошибка атрибуции, и что корни проблем в командах разработчиков уходят гораздо глубже.

Защитники скрама видят причину неприятностей в плохом менеджменте. Вот что говорит пользователь Llewellyn, подводя итоги: «Менеджмент, по сути, игнорирует разработчиков. Существуют фиксированные дедлайны, которые нужно выдержать, достигнув заранее заданных результатов. Работой занимается не команда, сосредоточенная на достижении одной и той же цели, а группа людей, в которой каждый беспокоится лишь о себе. Перспективное планирование и нестандартное мышление не приветствуются. В таких условиях программист, в итоге, поддаётся обстоятельствам и находит спасение в простом выполнении назначаемых ему задач. Мне доводилось работать в таких условиях. Но не надо винить в этом скрам».

Пользователь DJClayworth выразил настроение многих комментариев, сказав, что программисты, которые думают, что на них оказывается давление, будут работать плохо при применении любой методологии управления разработкой.

Противоположное мнение по этому вопросу лучше всего выразил пользователь Martin Maat, который обратил внимание аудитории на то, что уже сам факт того, что так много людей чувствуют необходимость высказаться по этому вопросу, говорит о том расстройстве, которое у них вызывает скрам.

Каковы распространённые неприятности, сопровождающие применение скрама?


В комментариях всплыли сведения о некоторых распространённых «подводных камнях» скрама, которые появляются либо из-за того, что этот фреймворк применяют неправильно, либо из-за того, что они, по сути, являются врожденными проблемами скрама. Вот почти десяток проблем такого рода, которые привлекли наше внимание.

▍1. Ежедневные совещания предназначены для менеджеров


Первое критическое замечание в адрес скрама связано с тем, что в ходе ежедневных встреч (стендапов) возникают нежелательные тенденции. Один из аргументов в пользу этой идеи заключается в том, что стендапы могут деградировать до состояния мероприятий, участники которых только и делают, что говорят о своей продуктивности. Особенно — если на таких мероприятиях присутствуют менеджеры. Поэтому пользователь Matthew Gaiser (он уже писал для нас, но на его комментарий мы наткнулись случайно) назвал стендапы мероприятиями, которые направлены на информирование менеджеров о текущей ситуации (update management). Он полагает, что доклады разработчиков на таких мероприятиях лишь побуждают менеджеров к наблюдению за тем, над чем ведётся работа, но это не приносит никакой пользы. Это ещё в большей степени справедливо для распределённых команд, когда каждый из членов команды работает в собственном режиме.

▍2. Главную роль играет выполнение задач


Ещё одна идея, возникшая в комментариях, заключается в том, что любая методология разработки, делящая большие задачи на задачи более мелкие, и направленная на наблюдение за ходом выполнения этих задач, ведёт, умышленно или нет, к появлению новых подходов к оценке работы. Если просто начать применять какие-то метрики, это повлияет на поведение людей, деятельность которых оценивают в соответствии с этими метриками.

Многие комментаторы говорят, что это означает, что разработчики могут «срезать углы» для того чтобы завершить то, что нужно было сделать в текущем спринте. Проблема, на которую указывает пользователь Gaiser и другие пользователи, заключается в том, что отдельный тикет, над которым ведётся работа, и который, во время спринта, переводится в разряд «готовых», это — «чёрный ящик». Что бы ни было внутри этого «чёрного ящика», это на результат оценки скорости работы не повлияет. Пользователь Gaiser пишет, что некачественная реализация, которая прошла QA-отдел, и отлично протестированная и спроектированная реализация, ничем не отличаются друг от друга. В результате оказывается, что учёт количества закрытых тикетов — это недостоверный показатель производительности труда.

▍3. Крайне продуктивные разработчики, которые не работают как команда


В ещё одной ветке рассуждали о противоречии между отличными программистами-одиночками и отличными командами. Когда все следуют методологии скрам, некоторые разработчики могут оказаться чрезвычайно продуктивными, но тогда о «команде» можно забыть. Пользователь Gaiser говорит, что, без правильных стимулов, самоорганизация — это недостижимая цель: «Члены команды будут решать задачи так, как им удобно, или так, как им предписано. Если это не способствует формированию команды, многое окажется не сделанным, и члены команды просто, в беспорядке, будут двигаться вперёд».

Он же продолжает: «Более того, если позволить каждому разработчику выбирать собственные методы для решения задач, это означает усложнение отладки кода».

▍4. Сложные задачи отодвигаются на потом


Gaiser, рассуждая в том же русле, продолжает критику иллюзии продуктивности. Он говорит о том, что при применении скрама основное внимание уделяется тому, чтобы перевести тикет в состояние «Готово». Глубокое обдумывание задачи при этом не выглядит особенно продуктивным. Поэтому разработчики могут стремиться к тому, чтобы брать лёгкие задачи и избегать задач более сложных. Вот, опять, слова пользователя Gaiser: «Скрам подталкивает разработчиков к тому, чтобы они брали бы лёгкие задачи, на решение которых уходит немного времени, что позволяет разработчикам показывать стабильно высокую скорость работы». В результате оказывается, что ежедневный выбор задач и ежедневные отчёты о работе подталкивают к выбору задач, на решение которых нужен один день.

▍5. Возможности продукта оказываются важнее качества кода


Всё тот же Gaiser полагает, что применение фреймворка скрам ведёт к падению качества продуктов: «То, насколько хорош разработчик, обычно определяется по его способности разрабатывать надёжный код. Скрам, если только владелец продукта не разбирается в программировании и не проверяет код, серьёзно обесценивает эту характеристику проектов». Он делает тут ударение на том, что «готовность» тикета часто определяется не после проверки качества кода, а лишь после того, как реализована соответствующая возможность.

▍6. Отсутствие времени на обсуждение рабочих вопросов с коллегами


Если скорость разработки — это единственный показатель эффективности команды, это значит, что у членов команды больше нет времени на обсуждение друг с другом каких-то вопросов, на то, чтобы узнавать мнение других, или на то, чтобы проверять свои идеи, кому-то о них рассказывая. А ведь это — именно то, что делает команду командой. Вот, снова, слова пользователя Gaiser: «Отличные разработчики часто советуются с другими разработчиками и ищут альтернативу своим мнениям. Но подобные занятия отнимают время, необходимое на закрытие тикетов, а это снижает скорость разработки».

▍7. Недавно выявленным ошибкам приходится ждать своей очереди


Ещё одна плохая модель поведения, вызываемая применением скрама, заключается в том, что «ошибки находят после спринта и считают их новыми задачами». Это может подталкивать разработчиков к выпуску некачественного кода, так как в текущий спринт нельзя включить дополнительные задачи.

▍8. Архитектура, управляемая тикетами


На системе тикетов основано не только то, какие задачи выбирают себе разработчики. Пользователь Gaiser говорит ещё о том, что применение скрама, непреднамеренно, приводит к созданию запутанной архитектуры проектов, так как разработчики работают над тикетами в порядке их появления и независимо друг от друга. В результате «архитектура быстро становится отражением тикетов».

▍9. Методология управления разработкой, которая влияет абсолютно на всё


Читая дискуссию, можно обратить внимание на комментарии, авторы которых отмечают, что корень всех проблем заключается в недостаточно строгом соблюдении правил скрама. Однако, вероятно, самым сильным заявлением пользователя Gaiser, направленным против скрама, является то, что этот фреймворк подминает под себя всё остальное. Это может разрушить сильную команду. «[Скрам] искажает и ломает любые другие механизмы управления разработкой, этот фреймворк становится всеобъемлющим явлением, в котором ничто, кроме выполнения ритуалов, не делается единообразно, а выполнение этих ритуалов создаёт иллюзию успеха».

Мы обсудили довольно большой список проблем, которые, возможно, вызваны применением скрама, а, возможно, лишь стали заметнее благодаря применению этого фреймворка. Но в исследуемой нами дискуссии можно найти так же много идей, касающихся того, как разработчикам жить в мире и согласии, следуя правилам скрама.

Как добиться максимальной отдачи от скрама?


Многие ответы на замечания пользователя Gaiser, получившие множество положительных оценок, касались того, что то, о чём он говорит, это — не скрам. Вот что написал по этому поводу пользователь Stephen Byrne: «Думаю, что это — хороший ответ, содержащий некоторые ценные идеи, но я должен согласиться со многими другими комментаторами в том, что то, что тут описано, это, определённо, не скрам, хотя и рассматривается под видом скрама». Но многие либо открыто ненавидели скрам, либо соглашались с пользователем Gaiser в том, что, если при использовании скрама что-то идёт не так, это значит, что этот фреймворк просто неправильно применяется.

Как правильно пользоваться скрамом?

▍1. Ежедневные совещания — это не то же самое, что взятие новых тикетов каждый день


Многие говорили о том, что ежедневные совещания принуждают разработчиков к ежедневному закрытию тикетов. Но, как отметил DJClayworth, без приоритизации задач тоже обходиться нельзя. И если приоритеты не расставляются естественным образом, значит, эту задачу должен взять на себя скрам-мастер: «Нужно приоритизировать задачи в пределах спринтов, более масштабным задачам нужно отдавать более высокий приоритет, поэтому кто-то должен взять сложные задачи в первый день спринта. В любом случае, если ко второму дню никто не взял большую и сложную задачу, скрам-мастер должен заявить примерно следующее: «Вижу, никто не взял задачу по сжатию базы данных. А это — большая задача. Если мы собираемся завершить спринт, работу над этой задачей надо начать прямо сейчас.»».

▍2. Стоит прекратить оценивать результаты отдельных разработчиков и прекратить вычислять показатели, относящиеся к отдельным тикетам


Все задачи, решаемые в спринте, нужно разбивать на маленькие части. Это бесспорно. Но фреймворк скрам не говорит о том, что разработчики должны быть одержимы показателями, указывающими на некие результаты. Скрам не предлагает стравливать разработчиков друг с другом. Пользователь Gaiser предлагает совсем отказаться от учёта баллов отдельных программистов. Он указывает и на то, что многим менеджерам может понадобиться заново изучить правила скрама: «Сообщите менеджерам, что момент, когда они хвалят разработчиков, или дают им повышение, основываясь на количестве закрытых тикетов, становится тем моментом, когда они радикальным образом меняют поведение команды».

Пользователь DJClayworth соглашается с тем, что целенаправленное игнорирование метрик, связанных с отдельными тикетами, должно входить в задачи хорошего скрам-мастера: «Внимание должно быть приковано к тому, чтобы команда добивалась бы своих целей именно как команда. Скрам-мастер должен придерживаться именно такой линии поведения и избегать любых дискуссий или подсчётов показателей, основанных на том, сколько пользовательских историй продвинул каждый конкретный член команды».

▍3. К большим целям надо идти маленькими шагами, но при таком подходе не надо забывать об этих целях


Вот ещё одна идея, касающаяся разбиения больших задач на небольшие фрагменты: «Если работа ведётся над маленьким фрагментом головоломки, это не значит, что нужно забыть обо всей этой головоломке».

Пользователь Llewellyn особо отмечает то, что применение скрама не может служить оправданием полного игнорированию принципов разработки качественного программного обеспечения: «Вы должны хорошо представлять себе то, куда движется проект. Это знание можно использовать для планирования архитектуры проекта, занимаясь планированием даже в рамках текущего спринта».

Скрам не освобождает программистов от необходимости делать своё дело, вкладывая в него все свои знания и весь свой опыт. Поэтому призыв Llewellyn относится к программистам, которые есть среди читателей комментариев: «Вы были на совещании, вы можете заглянуть в бэклог, вы знаете о том, каким является общее видение проекта в организации. Вы стремитесь к тому, чтобы избежать необходимости траты больших отрезков времени на что-то из отдалённого будущего. Но нет ничего плохого в том, чтобы заложить базу для расширяемой, модульной системы, которая и подойдёт для решения текущих задач, и позволит без проблем, в будущем, создать уже запланированные дополнительные возможности».

▍4. Надо определиться с тем, что значит «Готово»


Одна из тем, поднятых в обсуждаемой нами дискуссии, касалась критериев готовности (Definition of Done, DoD), и того, как определение этих критериев помогает отдельным программистам придерживаться определённых стандартов качества и быть в курсе того, чего от них ожидают. Самый острый вопрос тут заключался в том, кто и когда вырабатывает эти критерии. В том, что касается «когда», обычно речь шла или о как можно более быстрой выработке критериев, или о том, что они должны вырабатываться в ходе планирования спринта.

Ответ на вопрос о том, кто вырабатывает DoD, был написан пользователем SpoonerNZ в виде ответа на другой вопрос на сайте Software Engineering. «Критерии готовности создаются командой, но этот процесс может потребовать присутствия скрам-мастера. Нужно это для того чтобы задать ограничения, касающиеся качества, в том случае, если у команды нет чётких стандартов разработки. Например, команда может не захотеть связываться с код-ревью или с модульными тестами, что приведёт к тому, что всё это будет добавлено в DoD по инициативе скрам-мастера с целью обеспечения высокого качества разработки. В идеальной ситуации команда, поняв сильные стороны того, что ей предлагают, с радостью это примет, но реальный мир не всегда идеален».

Кто должен работать, придерживаясь DoD? Естественная (и сложная) цель — это сделать так, чтобы положения, изложенные в DoD, применялись бы в одной команде, и чтобы их поддерживали бы все члены этой команды. Но есть веские причины распространить влияние DoD на несколько команд. Или даже на всю организацию. Вот что пишет об этом пользователь Alan Larimer: «Отсутствие общепризнанного определения DoD для продукта негативно сказывается на качестве и прозрачности результатов работы. Организационный уровень DoD должен быть минимальным, техническим, и иногда исходящим от организации, что может обеспечить универсальное применение критериев готовности. Организация может предложить стандарты написания кода. Организация может потребовать автоматизированного создания сборок, давая ресурсы для создания и поддержки сборок для каждого продукта. Любая часть DoD, создана ли она организацией, или отдельным разработчиком, должна приносить в критерии готовности что-то ценное».

▍5. Менеджеры должны играть роль молчаливых наблюдателей


Хотя то, что вынесено в заголовок этого раздела, уже закреплено в официальном руководстве по скрам, анализ дискуссии показывает, что это правило, что печально, часто нарушается на ежедневных совещаниях, на которых присутствуют менеджеры. Из-за этого программисты чувствуют необходимость объяснять то, почему работы по тикетам занимают у них больше времени, чем запланировано. Если же на совещании присутствуют одни лишь программисты, в таких объяснениях нет особой нужды. Вот что сказано об этом в руководстве по скраму: «Ежедневный Скрам — это внутренняя встреча команды разработки. Если на ней присутствует кто-то ещё, скрам-мастер следит, чтобы они не мешали встрече».

▍6. Люди должны быть важнее процессов


Если вам нужно руководство, касающееся применения правил скрам, то прочтите слова, написанные пользователем Frank Hopkins, напоминающие об одном классическом принципе: «Люди важнее процессов». Сюда он добавил следующее: «Хорошая команда должна определять свои процессы, жёстко заданные процессы не способствуют формированию хорошей команды».

Ещё один пользователь, meriton, указал на то, что применение скрам зависит от отдельных программистов: «В скраме не предусмотрено то, что разработчики трудятся независимо друг от друга. Скрам предусматривает то, что команда разработки самоорганизуется, то есть — что команда принимает решения о том, как взаимодействуют её члены».

Пользователь nvoigt отмечает, что команды в скраме самоорганизуются из-за того, что они приходят в проект с уже определённой миссией: «В основе фреймворка скрам лежит тот факт, что вы — это команда. В команде неважно, закрыт ли тикет вчера конкретным программистом. Тот, кто трудится в команде, понимает цель (то есть DoD) и стремится достичь её вместе с остальными членами команды».

▍7. Создавайте команды для работы по принципам скрама, но не ожидайте, что применение скрама приведёт к созданию команды


Пользователь nvoigt применил спортивную метафору: «Представьте себе, что 11 человек получили печатное руководство по футболу. Им сказали, что им нужно ежедневно, примерно в 10 утра, практиковаться в конференц-зале №5, затрачивая на это по 15 минут. Думаете, в результате получится хорошая футбольная команда? А что если эти 11 человек были хорошими, профессиональными футболистами? Всё равно команда не получилась бы? Да, не получилась бы. Просто футбольные команды так не создают. Как и любой командный спорт, скрам нуждается в том, чтобы те, кто применяет этот фреймворк, были бы командой. Если это — просто группа людей, каждый из которых всего лишь хочет заработать себе очки, показывая, как много баллов пользовательской истории он закрыл, или как много целей достиг, то эта группа всегда проиграет команде, члены которой играют вместе, а не рядом друг с другом, или против друг друга».

Итоги


Пользователь nvoigt готов признать, что скрам «не подходит для абсолютно всех людей или команд». И, как показал интерес сообщества к вопросу, который мы тут обсуждаем, применение набора правил, к выработке которого может подтолкнуть скрам, способно привести к построению такой рабочей среды, которая далека от той, которую хотелось бы построить.

Итог этого материала нам хотелось бы подвести словами пользователя Seth R. Он говорит, что от ритуалов agile-методологий не нужно ждать чудес. Слишком многого хотят те, кто стремится с их помощью, как по волшебству, исправить недостатки команды разработчиков. Вот как он видит ситуацию: «Всё это завязано на ускорении обратной связи. В результате у команды появляется возможность заниматься самопроверкой и принимать решения относительно того, как ей работать для достижения лучших результатов. Скрам не поможет вам создать более качественный продукт, но если вы серьёзно отнесётесь к самопроверке, это может помочь вам построить команду, которая будет лучше прежней. А это, в свою очередь, ведёт к разработке более качественного продукта».

Многие сравнивают этот фреймворк с демократией. Поэтому, может быть, скрам — это худшая форма управления процессом разработки, если не считать всех остальных?

Или, может быть это, как говорится в официальном руководстве, фреймворк, который прост для понимания, но труден для совершенного овладения им.

Как вы ответили бы на вопрос из заголовка этой статьи?

RUVDS.com
RUVDS – хостинг VDS/VPS серверов

Комментарии 137

    +18

    Результаты работы по скраму напоминают миниатюру Райкина "Кто шил костюм", когда непонятно, кто же отвечает за продукт целиком. То ли программисты, которых ставят в условия работы на конвеере, то ли менеджер проекта, который пытается выполнять роль системного архитектора, зачастую не понимая даже азов программирования. Это личный печальный опыт, возможно, у кого-то он другой

      +4

      Мифическое-социалистическое "за продукт отвечает каждый", в итоге чего продукт выглядит как улица в сельском райцентре.

        0
        Тут вспомнил картинку из постера к сериалу «Давай еще, Тед» где они всей командой одновременно жмут красную кнопку.
        –2
        Это результат работы по скраму, когда половина команды не следует инструкциям, прописанным в Скраме. То же самое получается, когда на дорогах общего пользования, половина участников начинает плевать на пдд и ездит как кому удобно. Как следствие — больше дтп, пробки, покалеченные пешеходы. Скрам — те же пдд, только для разработки. Если следуют все, то все работает как часы, с минимумом затыков. Если кто-то нарушает — страдают все. В наших краях скрупулезный менеджмент не приемлется, ценности продукта, компании редко ставятся выше личных предпочтений менеджмента или разработчиков, методологии переделываются под удобство коллектива. Нарушать правила в угоду сиюминутного удобства — норма.
        Проблема в менеджменте и в культуре в целом, а не в методологиях.
          +8
          Напоминает оправдания социалистов почему коммунизм нигде «не взлетает», идея-то отличная со всех сторон, почти идеальная! А вот с народом, как правило, не везёт…
            0
            Может потому что коммунизма нет и не было нигде? А вот социализм работает нормально.
              +4
              И где у нас сейчас социализм нормально работает? На Кубе? Bо Вьетнаме или Лаоссе? Или в Китае где его вовсю мешают с капитализмом? :)

                –4
                Китай неплохой пример, но я бы упомянул скандинавские страны, да и вообще Европу — места, где старый капитализм превращается в социализм. А вот капитализм действительно плохо работает — РФ самый лучший пример, чего уж там.
                  +5
                  Капитализм, потихоньку превращающийся в социализм, это на мой взгляд плохой пример нормально работающего социализма. Как впрочем и любая смесь капитализма с социализмом.

                  Это даже если забыть что никакой социализм скандинавы не строят и строить не собираются. Они, как впрочем и куча дpугих стран в Европе, имеют социальную рыночную экономику или просто социальную экономику. Но это не социализм.

                    0
                    Я не поклонник упоминаемых вещей, но «капитализм, потихоньку превращающийся в в социализм» — это как раз социализм нормального человека, в отличии от «отнять и поделить». Как и в примере про футбольную команду, нужно создавать общество которое сможет делится с теми кто не может заработать, а не разделение всего создаст общество что будет работать на общее благо.
                    Если конечно под социализмом понимать путь а не цель, или идеализированную цель, то так говорить конечно нельзя. Но ИМНО лучше достижимые 90%, чем недостижимые 100%.
                      +4

                      У социализма есть определённые критерии, которые должны выполняться, для того чтобы это был социализм. Например государственный/общественный контроль средств производства.


                      То есть далеко не всё что является социальным, одновременно является и социализмом.


                      У скандинавов эти критерии не выполняются и никто не стремится их выполнять. Поэтому именно социализма у скандинавов нет и на данный момент даже не планируется. Но это не мешает им иметь социальное государство/общество.

              0
              Вы не совсем правильно поняли суть написанного.
              Скрам — это набор правил и инструкций, для того, чтоб быстро заделиверить продукт соответствующий требованиям заказчика. Такой же, как набор ПДД, задача которого — безопасность всех участников движения при минимальных ограничениях свободы. Такой же, как любая политическая теория, задача которой сводится к обеспечению блага определенной группе людей.
              Можно ездить без ПДД, как и разрабатывать ПО без каких-либо правил и ограничений, как и жить в первобытно общинном строе. Это просто и доступно в целом любому социуму, вне зависимости от уровня образования, культурных потребностей, материальных притязаний. Естественно, производительность любой такой системы будет на соответствующем уровне, и ограничиваться будет числом одновременных участников. Вы не напишите хорошее ПО в компании на 1000 человек где нет никакого регулирования, не обеспечите интенсивное автомобильное движение в большом мегаполисе, не поставив светофоры и не разграничив парковочные зоны, и не запустите ровер на Марс обществом, где нет сложной системы законов и развитых политической и экономической систем. Чем более комплексный результат хотите получить, тем больше сложных правил и ограничений нужно устанавливать, тем сильнее регулировать коллектив. Чем меньше культура и уровень образования коллектива соответствует выбранной методологии, своду пдд или законам политического устройства, тем сложнее будет внедрить все это в коллектив. Нельзя просто так взять и построить завод по производству сложной электроники там, где единственным законом было «право сильного», в все образование заключалось в том, как ловить рыбу и изготавливать луки и копья. Нужно поколениями менять систему образования, культуру.

              Скрам — сложная система менеджмента, для которой нужен определенный уровень образованности и культуры компании/коллектива, чтоб участники вообще могли строго следовать прописанным правилам. Координация и предсказуемость требуют большого числа ограничений. Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.
                0
                Если коллектив токсичен, уровень менеджмента примерно соответствует «я начальник — ты дурак, делай как сказали», исполнители читают требования после того, как закрывают задачи, никто не умеет собирать и описывать эти самые требования, то смысла от этой сложной системы никакого. Проще и быстрее работать так, как коллектив работал до этого.

                Можно было вместо такого длинного текста сказать кратко — Скрам предназначен для организации работы самомотивированой команды. Где-то смотрел статистику что в принцые самомотивированных и саморганизованных людей процентов 15 от всех программистов а команд где из 5 программистов 5 самомотивированные еще меньше. Для всех остальных есть схема ТимЛид и его подчиненные. Тимлид принимает все решения и поэтому за все несет ответственность. Назначает задачи своим подчиненным и принимает от них результат выполнения. Все.
                  0

                  Просто мотивированной. Скрам не содержит требования самомотивации, только самоорганизации.

          –2
          Просто многие забывают, что agile — это про гибкость. Все что есть в SCRUM можно менять до полной неузнаваемости, главное чтобы это было полезно/удобно/выгодно/хорошо. Нет никаких «жестких» непреодолимых рамок, потому что их существование нарушает основную концепцию agile.

          Ну и, помним также, что первее — наши крутые ит-процессы или их дурацкие бизнес?
            +13
            Agile это про гибкость. SCRUM это конкретная методология и у неё есть жёсткие рамки. Вам никто не запрещает поменять что-то в SCRUM. Но если вы при этом нарушите правила SCRUM'a, то это всё ещё будет Agile, но SCRUM'ом это уже не будет.
            +3

            "Сложные задачи отодвигаются на потом."
            Как это возможно при правильном scram? Баклог отсортирован так что самые важные задачи находятся вверху списка. Так что как правило самые сложные задачи тоже будут сделаны первыми.

              +4

              Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу.
              К тому же важный != сложный. К тому же важность не всегда четко определена, в спринте может быть много задач с одинаковой важностью.


              При этом разработчики всегда будут стараться брать побольше простых задач. Чтобы выглядеть молодцом на ежедневном митинге. Пока Вася уже неделю уныло твердит что делал одну и ту же задачу "Х", вызывая сочувственные взгляды коллег, Петя каждый митинг рапортует о пяти сделанных задачах и вызывает всеобщее восхищение начальства.

                +1
                Ну во первых описываемая вами ситуация это не проблема скрама/аджайл, а проблема конкретных «коллег» и «начальства», которые не видят сложности задач и/или не понимают что сложные задачи требуют больше времени чем простые.

                А во вторых что у вас вообще начальство делает на ежедневных митингах? Ну то есть если мы возьмём скрам, то всякие daily и standup'ы они как бы для команды, а не для посторонних…
                  +5
                  это не проблема скрама/аджайл, а проблема конкретных «коллег» и «начальства»

                  Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.


                  Хотя я лично считаю, что если идея раз за разом реализовывается неправильно и с одними и теми же граблями — проблема все-таки в идее.

                    +2
                    Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.

                    Это не проблема реализации скрама, а проблема конкретных людей. Если вы возьмёте тех же коллег/начальника и будете с ними делать водопад, то вы получите ровно ту же самую проблему. То есть ваши разработчики всё равно будут пытаться каким-то образом получить самые простые задачи чтобы сделать их как можно больше и получить похвалу от начальника.

                    Хотя я лично считаю, что если идея раз за разом реализовывается неправильно и с одними и теми же граблями — проблема все-таки в идее.

                    То есть если куча людей раз за разом забивают гвозди микроскопом, то проблема именно в микроскопе и гвоздях? :)

                    Да и вообще мне интересно на чём строится вот это ваше высказывание? У вас есть какая-то глобальная статистика по удачным/неудачным попытка реализации скрама и причинам по которомы реализация не удалась?

                    То есть как бы поскольку лично я видел больше «удачных» реализаций скрама чем «неудачных», то я бы всё-таки сказал что дело совсем не в скраме.
                      +1
                      Ну так во всех обсуждениях скрама все всегда упирается именно в этот аргумент. Что это не проблема идеи, а проблема реализации.

                      Так почти во всех реализациях, где я участвовал, требования фреймворка грубо нарушались. Основное нарушение — менеджмент вмешивается в ход спринта от мелочей типа активного участия в дэйли-митингах до изменения скоупа спринта без его отмены.

                    0
                    «Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу»
                    Тогда это не СКРАМ.
                    Задачи должны быть оценены. Иначе не возможно спланировать спринт. Если у задач есть оценка то сложная задача будет допустим 3 дня, а легкая 0.5 дня. Так что ни кто не будет криво смотреть на Васю который делает свою задачу положенных 3 дня. А вот когда Вася потратит лишний день на эту задачу, то он должен будет объяснить почему, в чём проблема. Скрам мастер сможет сразу среагировать и помочь Васе. Пете тоже придётся выкладываться не меньше чем Васе, так как он тоже должен отчитываться каждый день.
                    Про какое начальство вы говорите? На стендап митингах должны быть программисты и скрам мастер. Начальству там делать нечего. Начальство может присутствовать на демо в конце спринта, где отчитывается команда за результаты спринта. Только тогда будет сплочённость команды и ответственность за общие результаты.
                      +1
                      «Ну как правило нет строго распоряжения брать всегда только самую верхнюю задачу»
                      Тогда это не СКРАМ.

                      С чего это вдруг? Задачи приоризируются стэкхолдером с точки зрения его хотелок. Потом они оцениваются командой с точки зрения технической выполнимости(бессмысленно пытаться устанавливать крышу пока даже нет фундамента) и при необходимости прироритеты изменяются.
                      После этого задачи набраются в спринт с учётом их приоритета. Но это не означает что задачи попадут в спринт обязательно так как они приоризированны. Например если у вас на первых местах по приоритету стоят две большие задачи и они обе вместе в спринт не влезают, то берётся первая и остаток «добивается» менее приоритетными задачами.

                      А уж кто там как и в каком порядке дeлает задачи в самом спринте это вообще нигде и никак не регламентированно.
                        0
                        они обе вместе в спринт не влезают

                        Если у вас две задачи в спринт не влезают то это явно проблема с описанием задач. Такие задачи нужно обязательно разбивать на более мелкие. У нас был лимит на задачу 3 дня. Но в практике все задачи были обычно не больше 2 дней.
                        Стокхолдер не дурак, он будет всегда просить самое важное. А самое важное, обычно самое сложное.
                        Кстати на счёт
                        технической выполнимости
                        , очень многие «правильные» программисты перегибают палку на счёт невыполнимости. Начинают доказывать что нужно сначала сделать модуль Клиентов, НДС, Стоимости доставки и так далее что бы сделать страницу заказов. Но если продукт ещё в стадии разработки, то спокойно можно написать заглушек вместо готовых модулей. Некоторые кто привык работать стандартным методом много лет не могут поменять привычки и попробовать новые методы.
                          +1
                          Если у вас две задачи в спринт не влезают то это явно проблема с описанием задач.

                          Не исключено. Но и не обязательно. Ситуации разные бывают.

                          А ещё например бывают ситуации с зависимостями от каких-то внешних факторов(в том числе и от заказчика) и они тоже могут блокировать высокоприоризированные задачи.
                          Стокхолдер не дурак, он будет всегда просить самое важное.

                          Просить он может. Но это не значит что всё, что стэкхолдер просит, реализуемо именно в том порядке в каком он это хочет.

                          А самое важное, обычно самое сложное.

                          Ну вот совсем не обязательно.

                          очень многие «правильные» программисты перегибают палку на счёт невыполнимости.

                          А многие не перегибают и всё учитывают верно. А многие считают задачи выполнимыми, а на самом деле выходит что нет. А многие…
                          Какое это имеет отношение к тому что в скраме во время спринта задачи можно выполнять в произвольном порядке?
                            0
                            бывают ситуации с зависимостями от каких-то внешних факторов
                            Такое должно быть сведено к минимуму. У задачи должны быть описаны статусы. Статус «готова к спринту» означает что она свободна от всяких зависимостей, анализ сделан, все правила прописаны, и даже описано как её тестировать когда она будет готова. Если задача не отвечает этим критериям то её нельзя брать в спринт.
                            Agile это больше о здравом смысле. У нас в спринте всегда были задачи которые должны быть сделаны в определённом порядке. Это не было проблемой так как в каждом спринте было по 5 средних задач на программиста. Было легко руководствоваться здравым смыслом и давать одному программисту три зависимые задачи и пару независимых. Например один программист делает почти все задачи в модуле Клиента а другой в модуле поставщика. Мы всегда при планировании договаривались кто что будет делать а потом уже к концу спринта помогали если кто не успевал. А кто работал быстрее всех подбирал мелкие задачи.
                              0
                              Такое должно быть сведено к минимуму.

                              Не всё, что «должно быть сведено к минимуму», всегда удаётся свести к минимуму. Более того на самом деле онo и не «должно». Потому что например если заказчик не может/хочет по другому и готов за это платить, то это его дело и его деньги.

                              У задачи должны быть описаны статусы.

                              Нет, не должны. Они могут быть описаны. И это часто хорошая идея так поступать. Но никакого «должны» нет.

                              Если задача не отвечает этим критериям то её нельзя брать в спринт.

                              Ну так об этом и речь. Вот поставил вам ваш стэкхолдер у задачи самый высокий приоритет, а она «не отвечает критериям». И что вы будете делать: не возьмёте в спринт высокоприоритетную задачу или возьмёте в спринт задачу, которая «не отвечает критериям»?

                              У нас в спринте всегда были задачи которые должны быть сделаны в определённом порядке.

                              А у нас не всегда. И что, у нас теперь не аджайл из-за этого был?
                                0
                                Потому что например если заказчик не может/хочет по другому и готов за это платить, то это его дело и его деньги.

                                Конечно, пусть платит. Если стокхолдер не хочет сам открыть аккаунт в платежной системе для задачи «оплата товара», то добавьте новую задачу «открытие аккаунта» и делайте сами за его деньги. Но ни в коем случае нельзя брать в спринт задачу «оплата товара» если вы знаете что её невозможно начать делать.
                                Есть понятие статусы задачи. Эти статусы должны быть прописаны и все должны их знать наизусть. Допустим: В анализе, Готова к спринту, В работе, Готова к тестам, Закончена и так далее. Все эти статусы должны подробно описаны. У нас был аналитик который готовил задачи к спринту и представлял их на планировании спринта. Если задача была не готова к спринту, то мы её не принимали. Или принимали с уточнениями. Допустим для страницы заказа он не знал если можно принимать заказы из других стран. В таком случае, добавляли уточнение, страница должна принимать заказ только в нашей стране. А потом уже аналитик выяснял с клиентом если нужно добавить другие страны. Но это уже будет другая задача.

                                У нас были разные задачи и зависимые и не зависимые. Мы всегда следовали здравому смыслу а не желанию отдельных программистов навыбирать лёгких задач
                                  0
                                  Но ни в коем случае нельзя брать в спринт задачу «оплата товара» если вы знаете что её невозможно начать делать.

                                  Хм, вы вообще читаете что я вам пишу или сами с собой спорите? Я вам как раз и пишу что даже если какая-то задача высоко приоризированна стэкхолдером, то её всё равно не всегда удаётся добавить в спринт. Например потому что «бывают ситуации с зависимостями от каких-то внешних факторов(в том числе и от заказчика)»…

                                  Есть понятие статусы задачи.

                                  Есть такое понятие.

                                  Эти статусы должны быть прописаны и все должны их знать наизусть.

                                  Нет, не должны. Ну или процитируйте мне те части agile manifest/scrum guide где что-то подобное написано.

                                0

                                Подскажите, а когда производить освобождение от зависимостей и анализ, если задача не в спринте?

                                  0

                                  У нас были аналитики, дизайнеры, админы, у которых были свои спринты, цель которых была подготовить задачи. Сделать анализ, уточнить с клиентом детали, создать все нужное для для выполнения задачи, песочницы, стили, макеты.
                                  Понятно что по ходу спринта всё равно у программистов появляются вопросы но такого чтобы задача блокировалась в начале спринта, такого не было

                                    0

                                    Груминг, плэнинг и т. п.

                                      0

                                      Груминг — вообще не про таски
                                      Плэнинг — про распределение тасок.


                                      Я же спрашивал про аналитику. Выше посоветовали их включать в спринты соответствующих аналитиков и т.п. В принципе, мне кажется, это может делить и разработчик, временно выстапающий в ролик аналитика. Но тогда надо выделять анализ задачи как отдельный этап/тикет и отдельно на него закладывать время.
                                      Вот только вопрос коммуникации с другими командами, которые могут заблокировать тикет никуда не девается. Максимум — переходит на другого человека.

                                        +1
                                        Груминг — вообще не про таски

                                        Зато про аналитику. Ну то есть мы как раз на грумингах подобными вещами и занимались. То есть не только ими, но и ими в том числе.
                                          0

                                          Были ещё "спайки" — по сути исследовательско-аналитические задачи на оценку больших фич, причём прежде всего оценка вопроса достижимы ли они имеющимися ресурсами в принципе.

                            0
                            Вася по идее может декомпозировать большой монолит до scrum-driven tasks, это несложно делается
                          +6
                          Я для себя сформулировал так — Agile Manifesto = идея, философия. Скрам и Канбан — это товар. Товар который нужно продать и у которого целевая аудитория (топ) менеджеры. При этом сознательно товар ретушируется под ожидания, делая акцент на плюсах и игнорируя минусы. Скрам подается под соусом — люди не важны, если вы используете правильные процессы (смотрим аджайл манифест, как там).
                            +4
                            Скрам подается под соусом — люди не важны, если вы используете правильные процессы (смотрим аджайл манифест, как там).

                            Ну вот конкретно в этом пункте у меня совсем другой опыт. То есть во первых «продаётся» скрам обычно как раз таки под соусом «люди важны». То есть всякое «Individuals and interactions over processes and tools» и подобные вещи.
                            А во вторых на моей памяти всегда как минимум упоминалось что «скрам с кем попало не построишь и нужны люди, способные и готовые принять эту методику». А часто не просто упоминалось а повторялось в каждом втором-третьем предложении :)
                              +1

                              Вам несказанно повезло, без всякой иронии. Из множества случаев в моём опыте и среди моих знакомых это ни разу не звучало со стороны внедрения или менеджеров. Опять же из моего опыта, с правильными людьми не так важно какой методологии придерживаться

                                0

                                Ну мне то повезло. А вот тем кто по той или иной причине попал в категорию "кто попало" обычно везло не особо.


                                То есть на моей памяти все случаи внедрения agile/scrum сопровождались увольнениями или "по собственному"...


                                И да, с правильными людьми в общем-то методология и процессы вторичны. Но вот только где взять столько правильных людей… :)

                                  0
                                  с правильными людьми не так важно какой методологии придерживаться

                                  Именно. Скрам или не скрам — зависит от того, как именно в конкретном продукте приходят задачи. Если это B2C и, например, сервисный продукт — то будут постоянно сыпаться мелкие независимые хотелки от разных стейкхолдеров, и разумно делать так, чтобы каждую неделю-две очередная порция из них выходила на продуктив. Если каждая задача требует участия нескольких разных специалистов, то удобнее канбан — с ним проще оценивать, достаточен или избыточен задел на каждом этапе цепочки. И так далее. Но команда, её готовность двигать вот это все — всегда решает.
                              +8
                              У меня от скрама самые негативные впечатления. Особенно запомнилось, как начальство поехало на какие-то тренинги, им там несколько недель полоскали мозги, а они уже всем остальным — все оставшееся время. Обсуждение стратегий разработки по существу заменяется на обсуждение каких-то баллов и нелепых оценок, всяческого дробления задач. Ломаются традиционные роли тестировщиков и разработчиков. Чем скорее это безумие будет отправлено на помойку истории вслед за XP, тем лучше.
                                0
                                вслед за XP

                                А вот за хорошую ОС обидно было.
                                  +2
                                  В данном случае под XP имеется ввиду eXtreme Programming методология.
                                    0
                                    Окей, видимо, не очень я знаком с методологиями. Пишу код, закрываю задачи и ладно.
                                    +2
                                    Речь шла об eXtreme Programming.
                                      0
                                      Тоже подумал, что Хрюшу обидели. Эпичная ОС была
                                    +2
                                    Я уже писал в комментариях к аналогичной статье, по моему опыту скрам хорош на ограниченном интервале времени. Когда нужно выйти из состояния вечного аврала и привнести какую-то предсказуемость и ритмичность. И пока люди понимают эту цели и готовы так работать, скрам реально работает. Но на длительном интервале времени люди устают от уравниловки, что формально они просто винтики с двумя функциями «проголосовать, оценить сложность», «выполнить задачу сверху бэклога».
                                      +8
                                      Вечная священная война на тему того, виновата ли методология сама по себе или виноваты те, кто ее неправильно используют.
                                      На самом деле, эта дилемма — ложная, потому что методология не имеет смысла без практической реализации (она тогда существует только на бумаге). Любая современная методология, которая обкатана до определенной степени и не содержит в себе откровенных внутренних противоречий, может быть применена с положительным результатом в определенных условиях. Но ровно также она может быть применена наиболее часто встречающимся способом — в форме карго-культа, бессмысленного набора ритуалов. Получается ли из этого, что любая методология — провоцирует карго-культ? И да, и нет. Да — потому что большинство действительно склонны воспринимать методологии, как магические инструменты (это, вероятно, психологическая особенность людей, которую нельзя просто зачеркнуть). Нет — потому что если решения, связанные с внедрением методологии, принимают (редкие) люди, которые не склонны к карго-культу, методологии не портят, а помогают.
                                      Это как задаваться вопросом о вреде моноцикла (одноколесного велосипеда). Люди с хорошей координацией и балансом отлично учатся на них кататься и получают удовольствие. Люди с худшими способностями или те, кто не желает тренироваться, а сразу хочет делать трюки, разбивают себе лицо, ломают руки и так далее. Только моноцикл — редкость, а методологии разработки — модное веяние, потому негативный эффект от них выражен куда сильнее.
                                        +5

                                        Управление проектами и командами — сложная работа, которой равно также надо учиться, как и, например, разработке. Скрам — всего лишь одна из методологий и даже совершенное владение ею не делает менеджера хорошим управленцем. Вот и все. К сожалению, сейчас скрам все еще преподносится как серебряная пуля, но уже есть подвижки к понимаю, что это не так.

                                          0
                                          Совершенно согласен. Скрам очень похож на фреймворк с низким порогом входа для людей без опыта программирования. Просто бери и делай по бумажке, как дядя стрелочки нарисовал или на видео руками помахал. А на практике люди без образования и опыта управления молотят этим скрамом всё что ни попадя, и любое отклонение команды от идеала приводит к стопору всех процессов.
                                          +6
                                          Главная проблема скрама это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.
                                          Я много работал по скраму и в паре мест это было чрезвычайно эффективно. Тут же ошибки даже в первом абзатце статьи, там где «идея». Предлагаю каждому кто хочет рассуждать на тему и что-то внедрять, сдать сначала A-CSM на 95%+.
                                            +4

                                            В местах где скрам был крайне эффективен — каким образом боролись со "срезанием углов"? Кто отвечал за качество кода? Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить? Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?

                                              +1
                                              В местах где скрам был крайне эффективен — каким образом боролись со «срезанием углов»?

                                              Ругали провинившихся на партсобрании ретро. А если не помогало, то тогда уже проблема выносилась за пределы команды и обсуждалась с начальством.

                                              Кто отвечал за качество кода?

                                              Тот кто его написал и тот кто его отревьюил. Иногда кроме самих команд были ещё люди, которые в том или ном виде следили за общей архитектурой, «качеством» кода и тестов и всякими подобными вещами.

                                              Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить?

                                              Некритичные баги ждали нового спринта. Под саппорт/критичные баги обычно просто резервировалось немного времени. Если саппорта/багов было слишком много, то спринт обрывался.

                                              Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?

                                              Здесь сложнее. Иногда сами команды. Иногда какие-нибудь архитекты/сениоры/core team или что-то в этом роде. Иногда какой-нибудь jour fix из представителей всех команд.
                                                0
                                                Фильм «Цельнометалическая Оболочка» смотрели? Суть как там. За все всегда всю команду наказывают. Не успели что-то сделать. Всей команде срезали премию. На проде что-то легло. Всей команде выговор. Ну и увольнять всю команду разом. Внутри команда сама разберется кто есть кто. Понятно дело что если вся команда проголосовала что кого-то хочет исключит из своих рядом то его надо для начала перевести в другую команда и если он и там уже не приживется то в целом отпускать на свободу.
                                                +2
                                                Главная проблема скрама это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.

                                                Главная проблема хорошего менеджмента это то что он слишком сложный для большинства менеджеров. И слишком непривычный для остальных. Из-за этого берут 30% фреймворка, игнорируют всё что не нравится, потом внедряют через одно место и через полгода жалуются.

                                                Agile — принципы, ценности.
                                                Scrum — менеджерский фреймверк для удовлетворения этих ценностей. Список правил, иструкция. Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды. Если кто-то игнорирует — сыпется все. Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно. Ценой ограничения свободы членов команды (см менеджмент, sdlc).
                                                  0
                                                  Скрам — это серьезный менеджмент, который требует исполнительности и точности на всех уровнях команды.

                                                  Не согласен. Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет. Проблема в том, что одного его недостаточно.

                                                  Если кто-то игнорирует — сыпется все

                                                  А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?

                                                  Если команда строго следует инструкции — она делает продукт соотвествующий требованиям заказчика быстро и качественно

                                                  Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама. Ну и про то, что «строгое следование инструкциям» называется «итальянской забастовкой» я вообще молчу.
                                                    0
                                                    Ничего сложно, сакрального, чудесного и т.п. в этом нет.

                                                    Сложное в скраме — самоорганизация команды и взаимное доверие команды и остальных заинтересованных лиц.

                                                      0
                                                      Только Скрам тут не при чем. Это всегда нужно и всегда сложно независимо от методологии.
                                                        0

                                                        Других методологий, кроме аджайловых, я не припоминаю, где самоорганизованная команда — предусловие для внедрения.

                                                          0
                                                          Я пытаюсь сказать, что чтобы создать самоорганизованную команду с высоким уровнем доверия как внутри нее, так и извне к ней самой, методологий мало. Собственно, методологии и не описывают как это делать.
                                                            0

                                                            Это да, но я про то, что без этого скрам вообще не запустить нормально. Для него это маст хэв. Сначала добейтесь самоорганизации команды, а уж потом запускайте скрам. Если он ещё будет нужен. Ну или запуск скрама ставьте как эксперимент, как проверку команды на зрелость и готовьтесь издержки списать на убытки.


                                                            А с другой стороны есть методологии нормально работающие при самоорганизации на уровне "каждому разработчику погонщика с кнутом".

                                                      0
                                                      Ритуалы Скрам — просты и понятны. Ничего сложно, сакрального, чудесного и т.п. в этом нет.

                                                      Это вам они просты и понятны, а а кому-то (многим) не очень. Там и правда нет ничего сакрального, это просто хорошо прописанные инструкции.

                                                      А если игнорирует, но понимая зачем и почему и, внезапно, все не сыпется, тогда что?

                                                      А если игнорируют, но понимают зачем и почему и, внезапно, все сыпется, тогда что?

                                                      Если без шуток, то это другой уровень осознанности, когда на первом месте values & goals. Если ценность, нужная конкретному продукту — очень быстрое деливери, быстрее чем у конкурентов, а какие-то из установленных правил этому мешают, православно будет процессы подкорректировать под конкретные цели. Четкие цели, правильные ценности — это то, чего не хватает многим коллективам для хорошей продуктивности.
                                                      Это не так. Просто потому, что «управление проектом» — куда как больше и сложнее, чем следование ритуалам скрама

                                                      Ну так «Управление проектом» — это вообще гораздо больше, чем прсто следование инструкциям. Речь шла о Скраме — там есть набор правил, которым нужно следовать. Если вы выбрали Скрам, работайте по Скраму. Если вы сели за штурвал самолета, то пользуйтесь инструкцией по управлению самолетом, а не самосвалом.
                                                        0

                                                        А если решили Скрам подкооректировать, выходя за его рамки, а потом оказалось всё плохо, то нечего Скрам обвинять.

                                                  0
                                                  Удивлен таким количеством негатива по поводу скрама и аджайл методологии. В моем личном опыте переход к любому аджайл подходу обычно приводил к позитивным изменениям в команде, даже в очень трудной и нездоровой (хотя не решал ее проблемы, конечно же).

                                                  Но мне вот интересно, а какие подходы люди применяют кроме них? По какой методологии делают проекты? Неужели waterfall еще жив, когда аналитики планируют релиз несколько месяцев, а потом команда делает заранее изготовленные задачки? И что еще есть, у меня какие-то пробелы в этом месте.
                                                    +3

                                                    Хочу вам задать такой же вопрос, как и в предыдущем комментарии.
                                                    В вашем личном опыте:


                                                    1. Каким образом боролись со "срезанием углов"?
                                                    2. Кто отвечал за качество кода?
                                                    3. Что происходило когда после выпуска новой фичи обнаруживали баги — меняли задачи посередине спринта, или ждали 2 недели что бы исправить?
                                                    4. Как трэкался technical debt и кто решал когда стоило сделать technical investment (и оценить его)?

                                                    Мне действительно любопытен опыт людей, которые успешно применяли именно textbook scrum.

                                                      +2
                                                      Говорить буду про мой текущий проект:

                                                      1. Никто особенно с этим не борется, потому что такого не замечали. Программисты все крутые, все хотят делать хорошо, нет оценки работы программиста по количеству тикетов. Так же у нас есть правило двух аппрувов на каждый PR, соответственно, если срежешь угол, тебе вежливо на это укажут и предложат помощь правильно все сделать. Тут еще и особенность Ruby-коммьюнити, пока идеально не сделаешь архитектуру изменения, аппрува не получишь.

                                                      2. Не совсем понимаю этот вопрос. По-моему, всегда за качество кода отвечает программист, который его пишет. Не знаю, как на это ответить. Я вот код написал, и мне будет стыдно если ребята увидят, что я там где нить накостылял. Если надо делать костыль (типа слишком сложно получается, или надо что то сначала переделать, но не до того сейчас), собираем колл с заинтересованными людьми и решаем, готовы ли вложится в большой рефакторинг или костыль пока сгодится. Опять же, все люди адекватные и обычно всегда находится удовлетворяющий всех подход.

                                                      3. У нас спринт длился неделю (мы сейчас на какое-то подобие канбана перешли), и если появлялись баги, которые надо срочно починить, то их ставили поверх всех тасков, чтобы желающие могли взять. У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке. Это вроде никак не мешало, тестирования, как отдельного шага у нас нет, все покрывается тестами, которые тоже проходят ревью, деплоится изменение сразу после всех аппрувов и прогонки тестов на circle ci.

                                                      4. Настоящего технического долга (когда архитектурные проблемы требуют переделки системы) я не припомню, чтобы как-то особо накапливалось. Пару раз вначале было такое — какой-то человек говорил — блин, надо тут переделать все. Начинал долбить тех лида, собирал людей обсудить, все смотрели и говорили, да, тут было бы неплохо все подчистить. В итоге создавали эпик и тех лид пробивал его с командой менеджмента, начинали добавлять таски в спринты.

                                                      Сейчас основная проблема — надо поддерживать все джемы, все системы в обновленном состоянии, и не всегда это просто сделать. Для этого мы в итоге мы поменяли процесс, теперь разработчики могут завести таску с описанием в специальный беклог в джире, откуда на встрече по приоритезации менеджеры достают задачки, обсуждают их импакт и добавляют какое-то количество в спринт. Ну и мы провели серию воркшопов, обсуждали все животрепещущие темы для разработки и создали роадмэп, по которому большие технические темы выделены в эпики, которые периодически добавляются в скоуп.

                                                      Вообще, на мой взгляд, textbook scrum — довольно утопичная идея, и если подходить к нему как к священной корове, да еще если руководство все свои старые замашки в него принесет, очень может стать токсично работать в коллективе.

                                                      Выше правильно сказали, что единственная задача Scrum — создать быструю обратную связь к команде, чтобы она могла выстраивать процессы под свои запросы и стиль работы. И конечно же, люди. Люди должны быть адекватными, особенно руководство. Если начальник бегает с табличками количесва закрываемых тикетов, хорошего не жди :)

                                                      Мне с этим вот повезло. В текущем, самом моем лучшем проекте, спрашивается только грубый эстимейт в неделях на эпик и он не проверяется потом, когда сделаете, тогда сделаете. Иногда интересуются, не нужна ли помощь, если команда эпика сильно уж запозднилась. Нет никаких особых дедлайнов, главное — do the right thing. Бывали случаи, когда понимали, что фичу делать сложно и, главное, она не принесет какой-то уж большой пользы, заворачивали на полпути. Никакой оценки программиста нет, все итак все друг про друга знают. Ну и тех лид (он сейчас уже поднялся до руководителя всего проекта), очень крутой и адекватный, не давит не отсвечивает и требует от всех только одного — чтобы в каждый момент времени человек делал правильную вещь, которая сейчас наиболее важна.
                                                        0
                                                        У нас никто особо не ставил цели заканчивать все задачи в течении спринта, треть задач постоянно оставалась в стеке.

                                                        А разве предсказуемость (в виду маленьких итераций) это не одна из фишек скрама (для заказчика)? А тут вы говорите, что у вас нету такой цели. Звучит весьма странно

                                                          +1
                                                          На мой взгляд, маленькие итерации, прежде всего — это быстрая обратная связь, а не предсказуемость, возможность заметить отличие воображаемого идеального состояния проекта от его реальных показателей. Тут планировали сделать эту фичу за неделю, а чувак пыхтит уже две недели и явно пока еще не прорвался, что-то тут не так, давайте перепланируем и или отменим пару других запланированных эпиков и ему кинем парней на помощь или в принципе все норм, справится сам, скажем аналитикам, что этот A/B эксперимент будет запущен позднее.

                                                          Это позволяет управлять скоупом и ожиданиями продуктовой команды. А предсказуемость обычно задается как раз опытом самих разработчиков и их желанием быть профессиональными. Поскольку особо формальных требований и показателей нет, люди стараются сами определить скоуп (обычно на эпик выделяется микро-команда, выбирается разработчик, ответственный за эпик), договорится со всеми участника процесса и пытаться всех держать в курсе хода проекта и поднимать красный флаг, если где-то что-то поменялось.

                                                          Мне кажется, предсказуемость тут больше в постоянных пересмотрах и рефлексии на событиях, которые поддерживаются на уровне ритуалов (ретро и просто люди иногда темы поднимают). На моей памяти за эти почти 4 года в команде, процесс у нас поменялся с десяток раз.

                                                          Например, сначала было еженедельное планирование, когда оба офиса собирались все вместе онлайн через большой экран и обсждали состояние эпиков, сколько осталось, что новое добавляется, обычно эпик оунер рассказывал по каждому эпику. Потом в какй-то момент вылезло наружу, что народу что-то не нравится, а именно, что выходит, что мы просто отчитываемся перед менеджментом, никакое это не планирование, менеджмент может и почитать в джире и сам спланировать, а нам время не маза тратить.

                                                          Коллега-программист предложил эксперимент — а давайте вообще выкинем этот митинг и посмотрим, как нам без него. Попрессовали продакт команду, договорились с ними, что эпик оунер будет просто писатьв специальный слэк канал отчет по специальной форме — типа что сделали, что будем делать, сколько всего осталось делать. А митинг отменим нафиг.

                                                          Ну после трех недель собрались обсудить вместо планирования — как перемена. И программисты и менежеры согласились, что не хватает форума, где можно послушать, что поменялось, и задать вопросы. Договорились, что выкладывать репорты будем все равно, но рано, до 9:30, а на статус-митинге — переименовали его из планирования, в 10:00 на созвон заходят только эпик оунеры и те у кого есть вопросы, по очереди всем их задают. Выходит довольно быстро, кстати, на 7-10 эпиков и набора текущих задач без эпиков сейчас полчаса уходит, по старой процедуре — час. И главное, люди признали, что необходимость писать репорт заставляет обдумать, что происходит с эпиком и помогает собраться.

                                                          Пару месяцев уже так живем, вроде нормально
                                                            +1
                                                            Это одна из главных проблем со скрамом и ошибок управленцев — думать что скрам даст предсказуемость сроков. Он даете скорость обратной связи. Тобишь скрам не про «Мы сделаем это за 2 недели и точно сделаем». Начнем с того что в принцыпе в любой методологии неправильные сроки это обычное дело. Скрам про то что вместо «Мы думали что сделаем за год а сделали за 4» — «Мы думали что сделаем за 1 неделю а сделали за 4 недели»
                                                              0
                                                              Ну там механизм для оценки сроков в принципе есть, но в реальных условиях он работает довольно плохо. Чтобы оценить велосити нужно провести 2-3 спринта. Поидее этого достаточно чтобы понять производительность команды и разделитьимеющийся скоп на велосити, но есть одно большое «но». Но за 2-3 спринта(обычно это примерно 1,5 месяца) — с командой что-нибудь происходит — кто-то заболел, ушел в отпуск, уволился, кого-то наняли — и оценивать нужно заново и из-за этого оценка становится перманентной и становится очень сложно её зафиксировать на какой-нибудь продолжительный срок.
                                                                0

                                                                А и не надо на продолжительный срок фиксировать. Предполагается, что велосити изменяется в норме в сторону увеличения за счёт устранения помех по результатам ретро, при заболел/отпуск/уволился/наняли — в сторону уменьшения проседает.


                                                                Мне нравится подход, когда берётся скользящее среднее за последние пару месяцев для грубой оценки что внести в бэклог спринта.


                                                                Как и не надо давать оценки когда имеющийся скоп будет закончен. Поскольку предполагаетс

                                                            0
                                                            Баги влетающие в середине спринта, треть задач спринта остаются неисполненными… а это точно можно называть скрамом?
                                                              0
                                                              Я не знаю. Я знаю точно, что это аджайл процесс, когда команда сама себя и свои процессы перестраивает. Началось все с типичного scrum, а сейчас это что-то канбаноподобное — у нас спринтов больше нет, это, как мне кажется, кстати, влияние работы из дома в течении 4-х месяцев.

                                                              Я еще раз повторюсь, что я думаю, что как раз четко следовать скраму не обязательно, были тут разговоры из серии «это не настоящий скрам» — это не про то, я думаю, имелось в виду просто соблюдение некоторых базовых принципов, сама форма не так уж важна, какова длина спринта или какие встречи проходят в течении спринта.

                                                              Просто скрам дает некоторую рамку, некий шаблон, с которого можно начать. А главная идея этого шаблона — быстрая обратная связь и возможность изменения ритуалов и процессов команды.

                                                              А дальше все зависит от команды и их доверия к друг другу, могут устроить карго-культ, а могут и создать cohesive коллектив, который не нужно будет особенно микроменеджить. People management никто не отменял, собственно, мне кажется, одна из важнейших черт аджайла — это опора на людей, которые смелы и которые связываются друг с другом сами, порождая инновации и качество.
                                                            0
                                                            splatt похоже тебя сертифицированные скрам-мастера не понимают о чем ты спрашиваешь. думают что это само-собой как-то делается. или добавим 2 ревьювера на один PR и этого достаточно.
                                                            лично мне приходилось отвечать за данные вопросы, но опять же по личной инициативе.
                                                            +1
                                                            Из аджайла кроме скрама есть еще канбан.
                                                              0
                                                              Я, конечно же, имел в виду «что, кроме аджайла». Я вот только ватерфолл знаю
                                                                +1
                                                                В основе аджайл и ватерфол лежит на мой взгляд один и тот же цикл проектного управления, просто в аджайле он повторяется очень много раз, а в ватерфол 1 раз за весь проект. Соотв. всё что кроме аджайла и ватерфолл может быть посредине между этими крайностями, например, квартальный проект разбитый на 3 месячных этапа, на каждом из месячных этапов будет ватерфолл.
                                                                  0
                                                                  Вы не туда смотрите. Грубо гoворя водопад исходит из того что можно получить полноценное ТЗ ещё до старта проекта. А аджайл нужен когда полноценное ТЗ до начала проекта не получить и оно создаётся/дополняется в ходе проекта.
                                                                    0
                                                                    Чего это вдруг? Например, если я делаю интернет-магазин и заказываю у некого подрядчика сначала витрину, прописываю всё ТЗ и он уходит на месяц его пилить и приносят результат. Пока он пилит — я прописываю ТЗ на корзину и страницу заказов. И потом еще так же модуль кросс-сейлз и рекомендаций. Это что? Аджайл? Ватерфол?
                                                                      0
                                                                      Ну если опять же совсем грубо, то если «ТЗ на корзину и страницу заказов» зависит от того как будет сделана «витрина» или от какой-то информации, полученной во время того как витрина делается, то вам нужен аджайл.

                                                                      Если вы в теории сразу можете написать оба ТЗ(но не делаете это например из-за нехватки времени), то аджайл вам в общем-то не нужен и вам хватит водопада.
                                                                        0
                                                                        Интересно, основываясь на каких определениях аджайла и водопада вы делаете такие утверждения? Потому что на мой взгляд я описал достаточно типовую ситуацию и примерно равноудалённую от чистого водопада и чистого аджайла.
                                                                          0
                                                                          Интересно, основываясь на каких определениях аджайла и водопада вы делаете такие утверждения?

                                                                          Я делаю такие утверждения основываясь на истории возникновения аджайла и банальной логикe. Если у вас есть полноценное и окончательное ТЗ, то аджайл вам просто не нужен. И в такой ситуации аджайл это скорее всего просто ненужный оверхэд и лишние задержки и/или расходы.

                                                                          Потому что на мой взгляд я описал достаточно типовую ситуацию и примерно равноудалённую от чистого водопада и чистого аджайла.

                                                                          В каком месте она «удалённая»?

                                                                          Если у вы с самого начала в состоянии написать ТЗ сразу на весь проект целиком(витрина, корзина, кросс-сейлз, рекомендации), то это самый обыкновенный водопад.

                                                                          Если вы не в состоянии этого сделать и информацию, необходимую для полноценного ТЗ, вы каким-либо образом получаете во время выполнения проектa, то тут уже требуется возможность реагировать на изменения. И следовательно вам водопад не подходит и нужна альтернатива. Например тот самый аджайл.
                                                                            0
                                                                            Т.е. вы основываетесь на каком-то своём видении аджайла, а не на конкретном определении. Какой смысл тогда обсуждать, что является аджайлом, если вы это слово можете по своему понимать?
                                                                              0
                                                                              А вы где-то в определении аджайла вообще видите что-то о том где его можно применять? И что тогда, получается его нигде вообще нельзя применять?

                                                                              Естественно вы можете использовать аджайл где угодно. И водопад вы можете использовать где угодно. И гвозди микроскопом вам никто не может запретить забивать. Вопрос в том где логично и рационально использовать одно, а где другое. И если у вас в вашем «типе» проекта от аджайла нет никаких плюсов и только оверхэд, то зачем его использовать? Просто потому что это сейчас модно?

                                                                                0
                                                                                В каком определении? Есть, например, «The Manifesto for Agile Software Development». И написано там совсем не «аджайл нужен когда полноценное ТЗ до начала проекта не получить».
                                                                                  0
                                                                                  Ну да, там написано:

                                                                                  Welcome changing requirements, even late in
                                                                                  development
                                                                                  . Agile processes harness change for
                                                                                  the customer's competitive advantage.


                                                                                  Эта формулировка по вашему принципиально отличается от «когда полноценное ТЗ до начала проекта не получить»?
                                                                                    0
                                                                                    Во-первых это всего лишь 1 из 12 принципов.

                                                                                    Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.

                                                                                    На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.
                                                                                      0
                                                                                      Во-первых это всего лишь 1 из 12 принципов.

                                                                                      И что? То что он один из двенадцати не значит что его можно игнорировать когда вы создаёте/выбираете аджайл-методику. То есть ваша методика должна этому соответствовать.
                                                                                      И если вам это не надо, то зачем вам тогда нужен аджайл?
                                                                                      И на втором месте его тоже не просто так поставили.

                                                                                      Во-вторых между «полноценное ТЗ до начала проекта не получить» и «изменение требований приветствуется, даже на поздних стадиях разработки» есть разница.

                                                                                      Эээ, и в чём по вашему эта разница заключается? Если вы можете до начала проекта предоставить полноценное и окончательное ТЗ, то это значит никаких изменений требований уже не будет. Ни на поздних стадиях, ни на ранних. Просто не будет и всё.

                                                                                      А если у вас в какой-то момент всплывают эти самые «изменения требований», то это значит что ваше ТЗ не было полноценным и окончательным.

                                                                                      На мой взгляд, это всё равно что на запрос транспортного средства с колёсами предлагать самолёт, ведь у него же есть колёса.

                                                                                      А это вообще о чём и к чему? Если у кого-то окончательное и полноценное ТЗ выглядит дословно как «транспортное средство с колёсами», то вы ему можете и самолёт предлагать и велосипед. А если он имел ввиду что-то другое, то надо ТЗ было грамотно составлять. Или не надо было заявлять что оно окончательное и полноценное.
                                                                                        0
                                                                                        И что? То что он один из двенадцати не значит что его можно игнорировать когда вы создаёте/выбираете аджайл-методику.

                                                                                        Выбирая аджайл-методику надо смотреть не один из 12 принципов, а всю их совокупность.

                                                                                        вы ему можете и самолёт предлагать и велосипед

                                                                                        Не обязательно аджайл в каждое место, где не могут сразу составить окончательное ТЗ. Как не обязательно самолёт в каждое место, где нужны колёса. Может там ни места под ВПП нет, ни денег на обучение пилотов.
                                                                                          0
                                                                                          Я к тому, что выбирая аджайл-методику надо смотреть не один из 12 принципов, а всю их совокупность.

                                                                                          Если у вас уже один из 12 принципов создаёт ненужный оверхэд, то зачем смотреть на остальные 11?

                                                                                          Я и говорю, что не обязательно аджайл в каждое место, где не могут сразу составить окончательное ТЗ.

                                                                                          Вы сравнили конкретно аджайл и водопад. И на мой взгляд это сравнение было некорректно и если мы берём именно эти две методики, то разница в первую очередь именно в первом-втором пунктах аджайл манифеста. Причём в основном во втором.

                                                                                          Остальные пункты по хорошему точно так же могут быть применимы и к водопаду.
                                                                                            0
                                                                                            Не понимаю, почему именно взгляд с рекомендуемоей Вами стороны должен быть единственно верным. Слон с разных сторон по разному выглядит и врядли правильно говорить, что нужно на слона смотреть только сбоку или только сверху.
                                                                                              0
                                                                                              Я не знаю является ли он единственно верным и вообще как в данном случае определять критерии этой самой «верности взгляда». Но он как минимум рациональный. Но как я уже писал выше, в общем-то вам никто не может запретить в любой ситуации использовать аджайл или водопад или ещё что-то.
                                                                                                0

                                                                                                Нужно различать "можно применить" скрам/канбан/водопад и "лучше всего применить".


                                                                                                Если изменения ожидаются, то скрам хороший кандидат, что не делает его автоматически плохим, если не ожидаются.

                                                                                                  0
                                                                                                  Нецелесообразно на основе только лишь «изменения ожидаются» делать выбор в пользу скрама. Более того, если «поток изменений валится без остановки» и в нём есть как крупные, так и мелкие задачи, то как раз скрам может быть сильно хуже канбана, т.к. канбан позволяет переигрывать что угодно до непосредственно взятия задачи в работу, а скрам говорит, что вот спринт начался — не трогай его.
                                                                                                    0

                                                                                                    На основании "изменения ожидаются" можно сделать вывод, что аджайл хорошо подойдёт, какой конкретно аджайл — надо дальше рыть.

                                                                                                    0
                                                                                                    Нужно различать «можно применить» скрам/канбан/водопад и «лучше всего применить».

                                                                                                    Хм, а есть вот прямо ситуации когда вот прямо нельзя применить аджайл или водопад? Мне что-то такие в голову не приходят.

                                                                                                    Если изменения ожидаются, то скрам хороший кандидат, что не делает его автоматически плохим, если не ожидаются.

                                                                                                    Вообще-то делает. Потому что тогда действительно тратится куча времени на ненужные митинги и денег на «лишних людей».

                                                                                                    Например зачем вам нужны рефайнменты, плэннинги, грумминги каждый спринт если это всё можно сделать в более короткой форме до старта проекта? Зачем вам ревью каждый спринт если можно один раз показать конечный результат клиенту? Зачем вам ПО, который будет постоянно и интенсивно общаться с клиентом, если можно взять обычного менеджeра, который будет с ним общаться только на старте/финише проекта? Зачем оплачивать скрам-мастера в конце-концов?
                                                                                                      0

                                                                                                      Ну, аджайл нельзя применить, если в начальных требованиях есть пункты противоречащие его принципам. Например, если заказчик говорит "Мне главное, чтобы документация была не подкопаешься, и хоть какой-то продукт, пускай и практически не работающий"


                                                                                                      Например, для повышения привлекательности проекта для определенного типа разработчиков или для определенного типа инвесторов.

                                                                          +2
                                                                          Совершенно стандартная итеративная разработка. А, может, спиральная. Их много разных и одними Водопад/Скрам/Канбан список не ограничивается.
                                                                            0
                                                                            Так я этим примером и подчеркивал, что управление проектами не исчерпывается водопадом и аджайлом )
                                                                        0

                                                                        Водопад, по первоисточникам, вроде как не настаивает на одном цикле. Просто циклы в нём могут длиться месяцами, а то и годами.

                                                                    +1
                                                                    Не буду говорить за кого-то, скажу за себя.

                                                                    Проблемы в как таковом Scrum'е нет. Хотя, сейчас все больше и больше аргументированно агитируют за Канбан, как фреймворк, который максимально сокращает релизный цикл.

                                                                    Проблема в том, что этот Скрам преподносится, как серебряная пуля. Как будто внедрив Скрам внезапно команды преобразятся и начнут деливерить.

                                                                    И многие менеджеры этому верят. И потом приходит к команде такой менеджер, который нифига не умеет, не знает, с командой контакта найти не может, и, несмотря на наличие daily, не понимает чем команда реально занята и говорит, что Скрам нас всех спасет.

                                                                    Мне повезло (и это реально везение) иметь опыт работы с реально эффективными PM'ами, которые и наберут группу людей, и сделают эту группу командой, и будут с заказчиком эффективно коммуницировать, и команду слушать. И, что характерно, Скрам им не нужен. Просто потому, что ритуалы Скрама — лишь малая часть их работы.
                                                                  • НЛО прилетело и опубликовало эту надпись здесь
                                                                      +2

                                                                      обсуждение скрама сродни обсуждению рецепта плова — каждый знает как правильно, а у остальных рисовая каша с мясом.

                                                                        0

                                                                        Ну мне кажется что это не такая частая проблема — все же полностью скрам применяется не полностью, остаётся место для здравого смысла.

                                                                          +1
                                                                          Так, небольшое наблюдение: как начали массово в мире и в России внедрять скрамы и прочие аджайл штуки в айти, так начал замечать что сильно снизилось качество приложений и услуг, которыми пользовался и пользуюсь сейчас. Как пример ВК разросся из места общения в рекламную помойку, банковские приложения стали прожорливыми и тормозными, вообще софт стал прожорливым и тормозным. Может совпадение с массовым внедрением реактов и электронов, но что-то мне подсказывает что скрам тоже на это всё как то повлиял.

                                                                          Напишите если тоже что-то такое заметили.
                                                                            +3
                                                                            А мне всегда казалось что всё это началось после того как в США президентом чернокожий стал…

                                                                            </sarcasm off>Просто ИТ всё больше и больше становится «массовым явлением». Всё ниже порог вхождения, всё больше объёмы и следовательно и качество в среднем будет падать
                                                                            +1
                                                                            Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта.

                                                                            Ложный тезис (ну, отчасти), отсюда все проблемы. Скрам (и весь ажаль) — он не про скорость, он главный образом про предсказуемость всего этого бардака под названием «разработка ПО». Предсказуемость для того, кто платит деньги. Чтобы очередной гений, который плачет о том, что ему, винтику в капиталистической машине, не дают творить, не потратил в своем бункере месяц на то, что потом сразу придется выкинуть.
                                                                            Предсказуемость и регулярная обратная связь — то, для чего нужны все эти методологии. Если менеджеры приносят срам/кабан/другой ажаль с целью «ускориться», то это неправильные менеджеры.
                                                                              0

                                                                              Ну если выгнать гения из бункера и все таки направить его в правильном направлении, то скорость вырастет как следствие :)

                                                                                0

                                                                                Скорость чего? Скорость написания кода может и упасть, если человека выгнать из комфортных для него условий.

                                                                                  –1

                                                                                  Возможно скорость написания кода этим «гением» действительно упадет. Так как ему придётся заниматься не чем тем ему нравится, а тем, что нужно работодателю. Но мы же с вами не в детском саду. На работе нужно Работу работать. И давайте не будем забывать что в постановке вопроса она была около нулевой для работодателя.

                                                                                    0

                                                                                    Как я понимаю, в постановке вопроса он месяц работал над тем, что было нужно бизнесу, а по истечению месяца уже оказалось не очень. А скрам предлагается как способ сократить этот срок до недели-двух.

                                                                                      0

                                                                                      Скрам, как и любой правильно поставленный метод управления и контроля, в этом случае повышает коммуникацию и позволяет скорректировать деятельность работника в нужном работодателю направлении. При правильной организации этих коммуникаций косвенно снижается время разработки продукта, например в виду того, что кода выкидывается меньше.


                                                                                      В правильно настроенном waterfall такая ситуация тоже невозможна — когда разработчик месяц фигарит что то понятное ему одному и это потом выкидывается.

                                                                              0
                                                                              На мой взгляд проблема не в скраме, а в людях, которые полностью упускают из виду другие аспекты разработки, кроме как регулярное и прогнозируемое закрытие тикетов на мелкие задачи.
                                                                                +1
                                                                                На мой взгляд проблема не в людях. Люди — они просто стремятся делать то, что приносит им наибольшую личную выгоду. То есть — поступают именно так, как принято среди людей из современного общества.
                                                                                Это работа менеджмента — сделать так, чтобы наибольшую личную выгоду сотрудникам приносили (или, хотя бы, казалось что приносят — тоже вариант) те действия, которые приносят выгоду предприятию.
                                                                                  0
                                                                                  У вас внезапно люди противопоставляются менеджменту, там разве не люди? Я вообще в первую очередь про людей из менеджмента писал это.
                                                                                    0
                                                                                    Я так понял, что вы писали не про менеджмент, а про разработчиков.
                                                                                    Люди коннечно — и там, и там, но вот материальные интересы у этих разных групп людей явно разные.
                                                                                +2

                                                                                Мне нравятся ответы: если СКРАМ не работает, то это не СКРАМ :)))
                                                                                На мой взгляд такие ответы очень хорошо характеризуют СКРАМ. Это говорит о том как реальные люди интерпертируют эту методологию. Это значит, что методология не очень прозрачна, не имеет внятных ответов на наиболее сложные моменты методологии. Т.е. не решает те проблемы которые должна решать.

                                                                                  +1

                                                                                  Методология достаточно прозрачна, но реальные люди очень часто не хотят её имплементировать полностью. Например, менеджмент не просто присутствует на дэйли-митингах, но и активно в них участвует. Или при изменении скоупа спринта не отменяют спринт и начинают новый, а продолжают старый. Цели спринта не формулируют. Ну или формулируют просто как копи-паст всех задач.

                                                                                  0
                                                                                  Проблема Scrum в мотивации в долгосрочной перспективе.

                                                                                  Команда наемных программистов в итоге просто делает все медленно, так как в скорости заинтересован лишь владелец/клиент (про качество скажут пару раз — теперь это забота разработки — кто уже это вспомнит через год-два?..). И многие даже не заметят этого, если не будут иметь аудит или консалтинг. Не заметят, пока бюджет не будет превышен или продукт не будет очень плохим (про качество владелец/клиент уже вспомнит, когда получит отток пользователей и придет «разбираться»).

                                                                                  Можно тут сказать про премию и нематериальные поощрения — инженер, который проработал с этим 10 лет, просто будет улыбаться и очень убедительные доводы приводить. Уходить по часам — ведь он и так другую работу найдет, если что. И будет скрам-мастер всякую дичь предлагать, будут совещаться… Банкротство.

                                                                                  Именно поэтому я придумал более совершенный фреймворк, чем Scrum, Kanban, Scrumban, SAFe, LeSS, DaD… Намного проще, намного приятнее. Без подмены понятий. Обкатываю сейчас. Пока полет отличный. Если смогу убедиться, что все в рамках моих ожиданий, то поделюсь с миром и мир вздохнет с облегчением.
                                                                                    +1
                                                                                    Ну да, философию скрама можно выразить в максиме «а-а-а-а, херачим-херачим-херачим!», с таким подходом сложновато поддерживать огонь в глазах.
                                                                                      0
                                                                                      Именно поэтому я придумал более продвинутый фреймворк, который дает средний стабильный результат как в краткосрочной, так и в долгосрочной перспективе. Обкатываю.
                                                                                        0

                                                                                        Это откуда такая философия?

                                                                                          0
                                                                                          Следует из названия Scrum и его принципов. Товарищ все верно написал.
                                                                                          Scrum изначально сделан для авральной ситуации, когда стейкхолдеров много, когда стейкхолдеры не могут или не хотят договариваться, нет понимания ограничений (capacity), нужно быстро делать изменения, качество приносится в жертву частым релизам (именно так — достаточно почитать Scrum: The Art of Doing Twice the Work in Half the Time — к слову, в книге нет ни слова про то, как продукт поддерживался после разработки, а это очень хитрый и важный момент).
                                                                                      +1
                                                                                      Что, опять? Скрам — это инструмент, а не священный грааль, типа, применил и бац, производительность 120%, все счастливы, а код идеальный. Если молоток дать дураку, что будет? Чтобы все это работало, нужны люди, которые могут правильно это использовать либо адаптировать с изменениями для текущей команды, проекта, задач.
                                                                                      Методик управления проектами и разработкой много. В каждом конкретном случае нужно выбирать ту, которая максимально подходит для достижения цели, а не, как дурачок: " с завтрашнего дня мы работает по SCRUM!", потому что, кто то сказал, что сразу будет успех.
                                                                                        0
                                                                                        Хочу добавить важный аспект к пункту «1. Ежедневные совещания».

                                                                                        Разработчики должны отчитываться только перед людьми, которые заинтересованы в их отчете непосредственно. Это может быть тех лид, который понимает суть того что они сделали, или продукт оунер, задачу которого разработчик сделал. Среднестатистический менеджер не заинтересован в том что делают программисты, он заинтересован в том, чтобы у него расхды не привышали бюджет. В следствии этого, ему не интересно, что говорят программисты, т.к. его интересует больше всего «через сколько сделаешь?». Отсутствие искреннего интереса демотивирует. Разработчики чувствуют, что их мотивация падает, но обычно не понимают причину.
                                                                                          0

                                                                                          Так по скраму ежедневный митинг — это внутреннее мероприятие команды разработки без всяких менеджеров, максимум "я тут посижу послушаю".

                                                                                          0
                                                                                          А что такое скрам?
                                                                                            +1
                                                                                            Защитники скрама видят причину неприятностей в плохом менеджменте. Вот что говорит пользователь Llewellyn, подводя итоги: «Менеджмент, по сути, игнорирует разработчиков. Существуют фиксированные дедлайны, которые нужно выдержать, достигнув заранее заданных результатов. Работой занимается не команда, сосредоточенная на достижении одной и той же цели, а группа людей, в которой каждый беспокоится лишь о себе. ...».

                                                                                            На мой взгляд, это и есть основная проблема скрама. Только источник проблемы — не менеджмент, а проблема тут — объективная. Потому что, если подойти к вопросу чисто материально, то работой ведь объективно занимается как раз не команда, объединенная общим материальным интересом, а группа людей, каждый из которых имеет свой интерес.
                                                                                            Команда была бы, если бы разработчики были объединены во что-то вроде самостоятельной артели — которая подрядилась сделать разработку для предприятия за оговоренную плату, которая коллективно отвечает за результат, и которая сама определяет кому из своих членов сколько платить, кого надо принять, а кого — и уволить. Вот у такой команды был бы общий интерес, который бы объединял ее.
                                                                                            А в современных реалиях разработки уровень оплаты каждого разработчика (и будет ли он вообще работать) определяется на индивидуальной основе, менеджментом фирмы (по договоренности с самим разработчиком, естественно). Поэтому общего материального интереса у группы разработчиков нет. А отсюда проистекают неизбежные трудности эффективного использования методик, рассчитанных на управление разработчиками как коллективом, в том числе — и скрамом: сложно побудить людей (к тому же — образованных, а потому неглупых), что они должны действовать вопреки своим материальным интересам.
                                                                                              0
                                                                                              у скрама есть 2 проблемы:
                                                                                              1. постоянные дедлайны.
                                                                                              как результат — постоянный стресс в разработке. менеджеры предпочитают игнорировать этот момент, как несущественный. как по мне, многие выгорания в среде разработчиков происходят, по этой причине.
                                                                                              2. сертифицированные скрам-мастера. встречаются достаточно агрессивные поборники скрама, слепо следующие канонам учения. при этом слабо понимающие почему скрам предписывает что-то делать. и даже не догадываются, что еще много чего в скраме просто не описано. постоянный пушшинг разработчиков. давай, давай, давай. манипуляции.

                                                                                              по первому пункту я бы советовал разработчикам работать над снижением личной ответственности и лучше планировать задачи на спринт. например, веделять неделю на бизнес задачи, неделю — на ревью и исправление реализованой части.
                                                                                              второй пункт исправить не возможно.

                                                                                              чего мне в скраме не хватает, так это Tech Owner-ра. который мог бы корректировать разработку с технической стороны. кто-то пытается это делать, но как правило на уровне Team Lead/Tech Lead/Architect.
                                                                                                0
                                                                                                я бы советовал разработчикам работать над снижением личной ответственности

                                                                                                Скрам больше про коллективную отвественность.


                                                                                                Tech Owner-ра. который мог бы корректировать разработку с технической стороны

                                                                                                Можно попробовать решить через DoD. Нет апрува от Tech Owner — задача не сделана.

                                                                                                  0
                                                                                                  коллективная ответственность складывается из личной ответственности членов команды. и не нужно забывать, что в компаниях отсутствуют бонусы за колективный вклад в работу. так что на словал менеджеры декларируют командную работу, а по факту — работает группа разработчиков. с постоянной текучкой, по другому и не получиться.

                                                                                                  задача уже давно могла пройти DoD. а при наличии какой-нибудь новой задачи может потребоваться пересмотреть ее решение. в таком случае PO не поможет. нужна техническая экспертиза, и решение каким образом реализация новой задачи должна повлиять на текущую имплементацию.
                                                                                                  например, задачу можно сделать за 1 неделю, но тех лид советует потратить 1-2 недели на рефакторинг существующего кода, а потом приступить к реализации задачи. PO как правило выбирают первый вариант.
                                                                                                    0

                                                                                                    Тогда на уровне definition of ready. Техлид должен подтвердить, что система готова к имплементации второй задачи.

                                                                                                      0
                                                                                                      второй задачи на тот момент может еще и не быть.
                                                                                                        0

                                                                                                        Я про этап постановки второй задачи. Приходит она, техлид анализирует и видит, что рефакторинг нужен перед ней. Создаёт задачу на рефакторинг и добавляет её в blocked by второй

                                                                                                          0
                                                                                                          в идеале да, так и должно быть.
                                                                                                          либо все уйдет в тех долг, который не известно, кто и когда будет разгребать.

                                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                              Самое читаемое