Комментарии 25
Ох, сколько же я помню user story, которые, в результате уговоров продакта, были взяты в спринт с несоблюдением пары пунктов DoR, и неизменно заканчивались sprint fail. Интересно, что каждый новый продакт упорно наступал на эти грабли, несмотря на предупреждения...
Грамотные продакты понимают, что при этом надо чем-то жертвовать. И вполне нормально относятся к сносу или упрощению менее горячих целей. Правда что-бы так работать, продакту обычно нужно пару лет непрекращающихся факапов и внезапно пришедшее понимание, что это не только из-за косоруких разрабов.
Да тут даже не в жертвах дело. От того, что в одной команде все приоритеты перенаправят на конкретную юзер стори, пункты DoR для нее не начнут вдруг магическим образом выполняться. Не пропадут зависимости от других команд, если они были, не появится дизайн UX/UI если он еще не был проработан, и т. п.
Так все таки сами практики бессмысленные или все таки неправильное использование практик является проблемой?
Подобные практики — не более чем инструменты со своей областью применения, но некоторые команды упорно подметают пол отвёртками, а потом жалуются, что отвёртки только вредят.
Story Points - это просто абстрактный способ помочь членам команды лучше понять требования.
Нет, они не для этого. Такое же отсутствие понимания Agile во всех остальных пунктах. Не статья, а одни манипуляции... 🤔
Практики - это отправная точка, имхо. Если они работают как в учебнике, прекрасно. Если нет (при их соблюдении), то нужно либо адаптировать практики либо перекраивать команду. Иногда и то и другое.
Я участвовал в нескольких скрамоподобных процессах и большая часть из них нормально работала. Для данного проекта и данной команды, хотя от феншуя они были если не далеки, то уж точно не близки.
Обьясните мне как вот это (типичное усредненное высказывание из любого дейли)
Вчера я работал над двенадцать сорок два, сегодня я продолжу работать над двенадцать сорок два, но в час мне нужно к дантисту. Так что посмотрим как далеко я продвинусь.
помогает другим участникам спринта принимать решения? Какая информация содержится в таком высказывании для других? Никто ведь по правде не знает уже, что там за 1242.
Единственное, что из этого можно предположить, это что результат мы узнаем вероятно только завтра. И ведь в данном примере человек мог бы ничего не говорить и результат мы бы узнали тоже завтра.
Или вот другое типичное высказывание из дейли:
Вчера я закончил работать над двенадцать восемнадцать, мне нужно ревью на пулл реквест.
Пулл реквесты и так все видны в системе управления кодом. Почему поиск партнера на ревью нужно сообщать всем? Найди себе подходящего партнера закрепи за ним ревью и все.
И вот мой вопрос, как поменять содержание сообщенийк так, чтобы они стали полезнее для самого человека и для окружающих.
Вы понимаете, содержание типичных высказываний в дейли настолько шаблонны, что давно появились боты для этого.
Не знаю, может я просто слишком рацинально мыслю поэтому мне неэффективная коммуникация очень бросается в глаза. Все-таки не только айтишники пользуются аджайлом и скрамом.
Так команда и должна работать над эффективностью коммуникации и это самое важное.
В статье как раз и говорится про синхронизацию: первый пример как раз является контрпримером синхронизации, а вот второй вполне себе хорош, если отсутствие ревью стало или может стать проблемой.
Нет. Первый пример отличный пример синхронизации, если кто-то до этого выступал по 1242, то есть команда в курсе. И текущий спикер просто уточнил позицию. Хотя если бы он сказал, что продолжит сегодня, но скорее всего результат будет завтра к обеду (в том числе по причине дантиста)
Вторая причина оправдания упоминания дантиста в том, что 1242 работают несколько человек и спикер имеет лучшую экспертизу, то есть он намекает, что вопросы надо задать до часу или после 15-16.
За второй согласен иногда ревью превращается в реальный ботлнек.
Именно энтузиасты, плавно превращающиеся в инквизиторов или просто те, кто аджайл используют всуе? ))
В Agile есть несколько хороших идей - но когда компания/отдел начинают его внедрять силой, да еще и с помощью нанятого "тренера", как правило с хорошо подвешенным языком и нулевым пониманием специфики работы - тогда пиши пропало...
Особенно доставляет, когда начальство всеми силами старается препятствовать проведению ретроспектив - "как бы чего не вышло". Или наоборот - на ретроспективах люди кидаются друг в друга какашками, забывая о том что сначала надо добиться соответствия планов и реальности, и только потом начинать улучшать velocity.
И вот мой вопрос, как поменять содержание сообщений так, чтобы они стали полезнее для самого человека и для окружающих.
Разбиваете задачу на подзадачи и перечисляете то, что сделали за день.
Программист 1: "Вчера я доделал уведомления для списка TODO, сегодня собираюсь сделать экспорт их списка в Excel. Были проблемы с тем, что сервис уведомлений брейкнули API"
Варианты реакции:
Программист 2: "Ой мне тоже надо сделать уведомления, кинь в меня примером"
Программист 3: "Я недавно поменял общую либу для экспорта, когда замерджу, скажу, чтобы ты сразу поюзал удобняшки"
Тестер: "Ага значит уведомления скоро передадут в тестирование"
Тим лид: "Что-то они часто брейкают, уже вторая жалоба, надо с ними выяснить этот вопрос"
В Вашем примере подразумевается, что результаты работы разработчиков взаимосвязаны.
Это работает, потому что спринт наполнен взаимосвязаными задачами, которые вместе добавляют новую функцию в приложение. Тогда работа может быть поделена например на фронт, апи и бекенд и естественным образом этим трем участникам нужно синхронизироваться.
То с чем доводилось сталкиваться мне, это когда в спринт берутся несколько функций плюс багов между собой не связаных, а просто выделеных по приоритету и уместившихся по сумме строипоинтов в емкость команды. Например: баг с подвисанием приложения, баг когда прогресс бар не отображается, возможность маркировки и комментирования данных в сводной таблице, функцию восстановления последнего открытого проекта после перезапуска приложения.
Т.е. достаточно разные области приложения, практически никак друг с другом не связаные.
Может такой подход к планированию спринта уже есть ошибка?
Вот что в скрам гайде что написано про цель спринта
The Sprint Goal is the single objective for the Sprint. Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.
The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.
С другой стороны, даже если у людей слабо связанные задачи, но один продукт, они могу друг другу помочь: кто-то лучше знает одно, кто-то другое
Например, джун не смог воспроизвести баг с подвисанием, но оно возпроизводится у клиента, более опытный разработчик может подсказать, как правильно собрать дамп и в нем покопаться и в какие логи смотреть.
Если интересоваться работой друг друга можно найти много возможностей
Расписание для этого - бессмысленно.
По-моему, расписание позволяет выработать привычку, сгрести несуперсрочные взаимодействия в один промежуток времени вместо хаотичных прерываний на протяжении дня. И еще некоторые люди сами про препятствия не говорят, а, если спросишь, говорят.
во-вторых. Есть такая вещь, как job security.
Не видел такого. Там, где я работал обычно задач было больше чем людей, помощь другим очень ценилась и отмечалась на годовом ревью.
Ну с какой стати, когда у тебя ассайнмент, срок деплоя,
оселменеджер спрашивающий каждые пол-часа "are we there yet?"
Я в такой атмосфере не работал
Программиста два посылаем в Гугл учится на программста
программиста три посылаем нахер со своими велосипедами. Экспорт в Эксель делается в три строки, юзать для этого либу - вредительство, писать для этого либу - растрата и саботаж.
Тестеру до непосредственной передачи задачи в тест не должно быть ни жарко, ни холодно, т.к. в мире айти что угодно может не произойти и "скоро" может означать от пяти минут до десят лет. Опять же ценности в таком общении ноль
Тимлид, который вместо поиска проблемы и вариантов ее решения выбирает поиск виноватого тоже молодец
Классика аджайла, короче. Зато процессы идут) Куда - неважно, лишь бы было что и кого обсудить
Никаких смещений там нет, в целом помогает понять, кто чем занят и какие есть блокеры
Можно уточнить, пожалуйста, если учитывать 4й пункт:
4. Внедрение определения Ready (готовности) в качестве stage gate в вашем процессе.
То как именно нужно использовать DoR (Done to Ready - определение готовности)?
Ошибка в слове velocity.
Оценка в SP по конечным результатам - вы это выдумали сейчас, потому что видимо даже близко не понимаете сути этого инструмента. Да, я работаю с множеством команд, которым SP не упали, и очень сочувствовую им, потому что когда раскатывают трансформацию на большую компанию, то никто тебя не спрашивает надо оно или нет. Будь гибким или умри. Но я видел и команды и даже группы команд, которые овладели этим инструментом и нашли в нем спасение от бесконечных хотелок бизнеса.
Три вопроса на дейли - серьезно? Вы этот тезис из помойки достали? Даже последний скрамгайд от этого отказался. Представьте себе, люди не идиоты и способны сами понять что им на ежедневной основе нужно быстро обсудить, чтобы не делать херню.
Утверждать что Team Velocity - это шляпа может только человек, который никогда не работал с продуктами над которыми работает одномоментно 500+ человек, сгруппированных в 50+команд и с суровыми зависимостями от 2-3 таких же продуктов.
Да, на уровне одной команды итак понятно, что прое...ли спринт значит прое...ли спринт, но на нормальнома масштабе, если ты не будешь отслеживать эту метрику, ты можешь прилипнуть очень серьезно.
Ну вообще-то гибкая разработка и скрам - это не синонимы. Это даже комментировать неприятно, но вообще-то гора платформенных или сервисных команд не может брать в работу всякое г...о, потому что это положит весь процесс. И "сложные условия" это не хотелки команды, а в том числе требования архитектора, промбеза и иже с ними.
Термин "самоорганизация" - не синоним термина "анархия". Это на самом деле про распределение ответственности. В классических организациях фунции планирования, организации и контроля лежали на менеджере. В гибких организациях эти функции распределены в команде. И чтобы совсем было ясно: "команда" не равно "рабочая группа"
Подведем итог: вся эта статья - махровая инфоцыганщина. Да, аджайл-диссидентство имеет смысл, но для того, чтобы заявляться с такой позицией нужно обладать серьезными компетенциями. Которых, видимо, сильно не хватает автору.
P.S.
DoR - расшифровывается, как Definition of ready. А переводится, как Критерии готовности.
Топ-5 бессмысленных Agile-практик, которые делают вашу команду несчастной