Comments 17
Ну, блин, куда ни глянь — везде одно и то же ?♂️
Вначале мы старались полностью соответствовать этому фреймворку — выполнять все необходимые ритуалы.
Если вы старались, то должны были узнать, что там нет "ритуалов", есть только "события".
Однако постепенно пришло осознание, что соблюдать их все затратно, это отъедает время, которое можно было бы уделить разработке продукта.
Нет, вы изначально не понимали зачем эти события, поэтому к вам пришло такое "осознание". Когда не понимаешь предназначения чего-либо, оно всегда кажется бессмысленным.
Есть такая штука как ёмкость.
Она показывает вес работ, который команда (или её член), в среднем, закрывает за спринт в сторипойнтах (далее — sp).
Нет такой "штуки", как "ёмкость", есть velocity. Этот термин обычно переводят как скорость и он используется для измерения объема работы, которую команда может выполнить за один спринт. Это показатель производительности команды.
Каждый член команды дает по ним свою оценку. Внимание, вопрос! Сколько весит пользовательская история?
Опять двадцать пять — в сторипоинтах оцениваются истории, а не задачи, которые нужно выполнить, чтобы реализовать эти истории. Ваш вопрос не имеет никакого смысла.
Но, на мой взгляд, этот подход имеет существенное ограничение. Всё потому, что каждый член команды будет выполнять свою часть работы в соответствии со своей специализацией. Как я, как системный аналитик, могу адекватно оценить работу фронтенд-разработчика? Я могу адекватно оценить задачи анализа, да и то не всегда, потому что в наших задачах есть высокая доля неопределённости.
Ну, теперь точно понятно — вы не старались полностью соответствовать этому фреймворку, иначе знали бы о таком понятии, как кроссфункциональная команда, почему она важна и как ее создавать.
скрам-планирование
Что это вообще такое?)
Большая часть данных, если не все, уже лежат у вас в таск-трекере: оценки, приоритеты и т.д. Остаётся только ёмкость. Но и её, с определенными допущениями, можно вычислить ретроспективно, либо задать директивно.
Насмешили — "вычислить" или "задать")
Вывод: Не надо линейного программирования в Scrum, надо его хотя бы раз изучить правильно)
Странно слышать обвинения от человека, не находящегося в контексте. Поверьте, это вас не красит.
Судя по комментарию, вы не понимаете отличие velocity от capacity, не понимаете, что такое бэклог и из чего он состоит, не поняли и даже не попытались понять, о чём написано в статье.
Вывод: Думайте прежде, чем что-то написать, и будте добрее)
Не понимаю причем тут доброта, я объективно указал на ваши ошибки, это во-первых. Во-вторых, я прекрасно понимаю о чем говорю, иначе не писал бы, и как раз прекрасно понял что вы написали в статье. А теперь если у вас есть что написать про сути моего комментария - добро пожаловать, а просто в чем-то обвинять меня - это вас не красит.
Если вы старались, то должны были узнать, что там нет "ритуалов", есть только "события".
Действительно, есть события. А ещё их называют церемонии. А ещё их называют ритуалы. А вы просто занимаетесь буквоедством.
Нет, вы изначально не понимали зачем эти события, поэтому к вам пришло такое "осознание". Когда не понимаешь предназначения чего-либо, оно всегда кажется бессмысленным.
Это ваша личная интерпретация. Однако если нет темы для обсуждения, например, на ретроспективе, то нет смысла её проводить каждый спринт.
я прекрасно понимаю о чем говорю, иначе не писал бы, и как раз прекрасно понял что вы написали в статье
Если вы действительно поняли, о чём написано в статье, то написали бы комментарии по сути предлагаемой модели, а не стали бы обвинять в несоответствии фреймворку. Для вашего сведения, в каждой компании своя имплементация скрам. И она зависит как от внутренней организации компании и внутренних ограничений, так и от зрелости самой команды.
Нет такой "штуки", как "ёмкость", есть velocity
Если вы не знакомы с понятием capacity, не стоит утверждать, что его нет. Надо уметь факт от плана отличать.
Опять двадцать пять — в сторипоинтах оцениваются истории
В сторипоинтах оцениваются элементы бэклога. История - это один из типов элементов. А ещё есть технические задачи, задачи на устранение ошибок, задачи на устранение техдолга и пр.
Ну, теперь точно понятно — вы не старались полностью соответствовать этому фреймворку, иначе знали бы о таком понятии, как кроссфункциональная команда, почему она важна и как ее создавать.
Кроссфункциональность, которая предполагает наличие в команде всех компетенций, необходимых для реализации продукта, не означает, что аналитик способен дать адекватную оценку задач разработчика.
Что это вообще такое?)
Покер планирование, скрам покер, как вам угодно
Del
Как надоели все эти «угадаю мелодию с 6 нот».
У вас или работа до ужаса типовая и тогда вам заранее известно сколько займет та или иная задача. Или же продукт на выходе будет Г полное.
Тут уж одно из двух. Мне тут к слову недавно именно про ваш банк присылали пост. Говорят у вас ИТ инфраструктура сыпется вплоть до того что в БД транзакции теряются и сервисы постоянно падают.
Не удивлен если честно. Слава богу что хоть самолеты по Аджаил не проектируют.
У вас или работа до ужаса типовая и тогда вам заранее известно сколько займет та или иная задача.
Правильно я понимаю, что в своей работе вы не используете никаких оценок? Вы не планируете объёмов и сроков их выполнения? Когда сделаете, тогда и хорошо?
Говорят у вас ИТ инфраструктура сыпется вплоть до того что в БД транзакции теряются и сервисы постоянно падают.
А вы всему верите, что говорят?
В моей работе качественный продукт важнее всякой имитации прогресса. Именно поэтому я лучше год потрачу на проектирование, зато буду иметь продукт который будет работать как швейцарские часы, чем буду писать тонны кода которые через пару лет придется переписывать/выкидывать.
А вы всему верите, что говорят?
Не всему. Вашей статье вот не поверил.
Прекрасно! Я с вами полностью согласен. Качество продукта - это главное. Но вот даст ли вам Заказчик год на проектирование? Будет ли он готов заплатить вам за ваш проект? И не изменятся ли требования к продукту за год?
В статье описано мнение (она и помечена категорией "Мнение"). Вы можете прислушаться либо пропустить мимо. Тут нечему верить.
Опыт показывает что некоторые проекты разрабатываемые по аджаилу просто невозможно до конца довести. Только до логического тупика.
Я таких видел десятки. Так что если важен продукт, а не процесс то часто единственный выход просто Аджаил выкинуть.
Да, соглашусь, в гикой разработке есть свои слабые стороны. И ваш тезис действительно имеет смысл. Спасибо за комментарий!
Обратное тоже справедливо, во многих проектах Аджаил работает. Причем проблема Аджаил-проекта может быть либо в том, что подход действительно не подходит, либо в том, что его нужно по-другому применять. Лично мне Аджайл комфортен (если убрать радикальные трактовки), поэтому, кажется, любые исследования на тему развития подхода можно только приветствовать.
Очередная попытка выдать хиромантию за науку. Вы нарисовали формул и подвели математическую базу, но как будто не видите того, что все базовые элементы и веса для расчёта вы берёте из головы.
Вы не можете знать, верно ли была дана оценка задачам, все ли взаимодействия и подводные камни вы учли. Вы не можете знать, заболеет ли ваш разработчик через неделю и не понадобится ли ему срочно везти кота к ветеринару.
Вы не можете знать, не придет ли завтра бизнес с диаметрально противоположными требованиями.
А если всё-таки можете, то вам не скрам нужен, а водопад.
Не хочу вас обидеть, но если для вас новость, что аналитик не может выполнять задачи разработчика, фронтэндер - бэкэндера, а для того чтобы QA было что тестировать, нужно это что-то разработать, возможно, стоит вернуться к основам.
Вы правы, нельзя быть полностю уверенным в оценке. И, конечно, есть риск пропустить какую-то зависимость. Однако все планы строятся именно на оценках и зависимостях. Независимо от того, скрам у вас или нет.
По поводу второго тезиса. Перечитайте, пожалуйста, внимательнее. Речь про оценку задачи одной компетенции носителем другой.
В нашей практике бэклог разделен на стадии и задачи анализа редко попадают в один спринт с реализацией, но мы и релизы выпускать можем только по итерациям, так что это не всегда применимо. Проблематика проектов очень разная и где то истории почти равны фичам, а где то сценарии ветвятся как хорошие джунгли и до проектирования фич проводится 90% объема работ.
Но в целом я за более глубокое планирование бэклога всегда. Если план есть только на один спринт я как методолог бью тревогу
Боль автора поста понимаю, у самого похожие проблемы были. Это хорошо, когда есть кроссфункциональная команда, но, за всю свою практику, я не видел таких команд. Видел как ПМ называл своих ребят мультистек, но ребята явно были не в вострге. Оценка чужого стека - это полная шляпа, мультистек разработчик - это либо гений, либо человек, который делает все, но все делает плохо, ни о каком качестве тут речи идти не может. И естественно возникает проблема в планировании и утилизации ресурсов. Мне кажется, скрам сюда тянуть не стоит, есть много других вреймворков, с итеративной разработкой. не нужно выдумывать велосипеды
Рассчитываем бэклог спринта не на глаз