«Образцовый» Scrum-проект: клиент доволен, разработчик — нет

Как обнулить достоинства Scrum для клиента — объясняет директор по развитию Grotem на примере разработки сервиса регистрации онлайн-касс.

В закладки
Grotem работает по Scrum с 2015 года

Этот кейс — для компаний, которые заказывают ИТ-разработку, и для разработчиков, которые только присматриваются к Scrum (есть такие?). Я расшифрую обязательные термины Scrum и объясню:

  1. Что происходит у разработчика после старта проекта.
  2. Что требуется от заказчика.
  3. Почему не всё окей, когда вроде всё окей.

Если вы каждый день говорите «нам пора на дейли» — вам будет скучно читать. Хотя кто знает.

Что такое Scrum и почему он

Обычно начинают так: «Scrum — это фреймворк…». Мы предпочитаем говорить, что это способ создать продукт на основе доверия. Именно благодаря доверию случается высокая скорость разработки, увлечённость команды и актуальность продукта на выходе.

В отличие от Scrum, классический подход к разработке Waterfall (каскадная модель) основан на недоверии. Недоверие рождает бюрократию.

Десятки согласований, обоснований, килограммы бумаги и строгие письма в почте: «Просим придерживаться первоначального ТЗ, мы его полгода писали», «Бухгалтерия не одобрила ваше предложение по изменениям, требуется детально прописать, на что именно будет потрачен каждый час». Долго, нервно, некомфортно.

Часто заказчик не готов работать по Scrum. Тогда исполнитель идёт на хитрость: снаружи менеджеры строят декорации, похожие на Waterfall, а внутри команда работает по принципам Scrum. Зачем? Потому что сейчас бессмысленно делать большинство проектов по классике: слишком быстро всё меняется, слишком много неопределённости.

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

Запомнить: доверие в Scrum невозможно без открытости и предсказуемости. Заказчик и исполнитель вовремя говорят о проблемах и изменениях на проекте.

Кто клиент и какой проект

Клиент — производитель онлайн-касс «АТОЛ». Проект — бесплатный сервис быстрой регистрации касс. Мы были знакомы: за год до этого интегрировали своё «кассовое» приложение с кассами «АТОЛа».

«АТОЛ» был первой кассой, с которой мы интегрировали наше приложение для курьеров и торговых представителей

Главная ценность сервиса — одно окно. Предприниматель покупает кассу у партнёра «АТОЛа», партнёр тут же её регистрирует. Предпринимателю нужно знать только ИНН и захватить флешку с электронной подписью. Не надо связываться с ФНС, забивать массу букв и цифр, рискуя ошибиться и потерять фискальный накопитель стоимостью 7000 рублей.

В декабре 2017 года владелец продукта со стороны «АТОЛа» (product owner) представил список функций, которые должны быть в сервисе, с кратким описанием. На языке Scrum это называется бэклогом продукта. Потом мы вместе обсудили бизнес-цели и пришли к схеме решения.

В схему вовлечена налоговая, операторы фискальных данных (ОФД) и сервис Dadata.ru, предоставляющий безошибочные данные предпринимателя для регистрации кассы.

Сервис быстрой регистрации (СБР) для партнеров «АТОЛа». ОФД — обязательное звено: по закону 54-ФЗ все данные об операциях на кассе передаются через ОФД

Заказчик решил презентовать сервис с базовыми функциями 15 марта, на конференции партнеров «АТОЛа». К этому сроку нужно было сделать интеграцию с одним ОФД — Яндекс.ОФД. Первый спринт стартовал 10 января.

Запомнить: заказчик не обязан разбираться в тонкостях Scrum. Исполнитель помогает составить бэклог, уточняет критерии готовности продукта. Главное, что требуется от владельца продукта в начале, — расставить задачи в порядке приоритета.

Спринты и хотелки

Спринт — это срок, за который команда разработчиков закрывает несколько «хотелок» на основе бэклога продукта. Например, две недели.

Хотелки формулирует владелец продукта: «Как пользователь сервиса я хочу, чтобы адрес моего интернет-магазина при регистрации подтягивался автоматически». В Scrum эти хотелки называются user stories.

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

Состав спринта

Владелец продукта подтверждает состав спринта и обязательно определяет его цель. Это упрощает понимание, всё ли сделали на спринте. Бывает, что не все задачи решены, но цель достигнута. И наоборот: все задачи решили, а цели не достигли. Критерии приемки спринта обсуждаются всей командой с владельцем продукта.

Владелец продукта утверждает состав спринта и формулирует его цель в Telegram

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

Первые два спринта пристрелочные. Надо понять, какой объем задач реально делать за две недели и планировать так, чтобы команда не сидела без работы и не ночевала в офисе.

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

Диаграмма сгорания задач (burndown chart). Серая линия — запланированные задачи, красная — выполненные. В идеале линии сходятся на оси X

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

Если цель спринта достигнута, он считается успешным. Бывает, заказчик говорит: «Давайте этот спринт признаем успешным, там совсем немного осталось доделать, тем более причина не в вас, а в чужом API». Такие предложения принимать нельзя, а владельцу продукта их лучше не озвучивать.

Результативность спринтов. Второй спринт у нас редко успешный — берём слишком много задач. Всего на проекте было три неуспешных спринта из двенадцати

Идея не в том, чтобы получать хорошие оценки, как в школе, а в том, чтобы каждые две недели выдавать версию сервиса с новыми функциями. Не все запланированные функции работают? Окей, спринт неуспешный, и команда не получит пиццу. Не страшно, если 50% спринтов неуспешны. Страшно, когда мухлюют.

Запомнить: заказчику важно научиться формулировать user stories, поставив себя на место пользователя, и определять цель спринта.

Как оцениваются спринты

Оценка спринтов — самое сложное. В Scrum задачи рассчитываются не в часах, а в относительных единицах. Обычно их называют story points (для простоты — стори-поинты). Стори-поинты включают в себя риски, сложность и внешние факторы: потерю связи с сервером ФНС, проблемы с ОФД и так далее.

Некоторые команды вместо стори-поинтов используют разные размеры футболок (S, M, XL) или породы собак. Одна задача «весит» как такса, другая, посложнее, — доберман, третья — сенбернар. Это весело, когда делаешь внутренний продукт и сам себе заказчик. Когда заказчик внешний, его бухгалтерия вряд ли такое оценит.

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

Покер планирования. Участники команды «вскрылись» и не пришли к консенсусу — будут переигрывать

В каждом спринте у нас 35-40 стори-поинтов. Если задача «весом» пять стори-поинтов не доделана, заказчик экономит сразу на пять стори-поинтах — засчитывается только стопроцентная готовность.

Запомнить: в Scrum команда быстро реагирует на проблемы при решении задачи. Не надо ждать подтверждения на оплату дополнительных часов, чтобы их решить. Всё уже заложено в стори-поинтах.

Команда Scrum

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

На время проекта команде выделяется отдельная комната. Здесь все равны и каждый отвечает за продукт, а не только за свою часть работы. Учитывайте это, не спрашивайте: «Кто у вас главный?»

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

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

Правда ли, что в Scrum много болтовни

Да. Грубо говоря, один из десяти спринтов уходит на общение, девять — на разработку.

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

Илья

участник команды, первый раз работает по всем правилам Scrum

Новички в Scrum удивляются: как можно четыре-пять часов тратить на разбор двухнедельного спринта. На самом деле такое собрание в конце каждого спринта (ретроспектива) очень важно. Ретроспектива помогает команде стать командой, здесь открыто говорят, что чья-то Metallica в наушниках мешает работать и что кому-то пора перестать опаздывать.

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

Желательно, чтобы на первых двух ретроспективах был владелец продукта (у нас — с помощью Zoom). Это помогает построить доверительные отношения и лучше понять, как работает команда.

Скрам-мастер записал всё, что обсудили на ретроспективе. Чтобы ретроспективы были бодрее и продуктивнее, мы используем метод шести шляп. Пицца на столе означает, что спринт был успешный

Кроме ретроспективы есть ежедневные 15-минутные встречи (Scrum daily, они же дейли, они же митинги). Каждый говорит, что сделал вчера, что сделает сегодня и какие есть сложности.

— У меня не получается с передачей данных ФНС. Максим, помогай.

— Хорошо, в 16:00 займусь.

Здесь участие владельца продукта не требуется.

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

Владелец продукта всегда участвует в планировании спринта, груминге и обзоре

Перед ретроспективой, в тот же день, заказчик участвует в обзоре спринта (он же ревью, он же демо). Фактически это приёмка, именно здесь решается, считать спринт успешным или нет.

Запомнить: заказчик всегда на связи с командой. Нужно иметь замену на случай отпуска владельца продукта или увольнения. Владельцем продукта может быть не штатный сотрудник компании-заказчика.

Почему мы недовольны результатом

Вот что написал клиент в ответ на просьбу оценить наш общий Scrum-опыт:

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

Мы недовольны, потому что сервиса нет на рынке. Формально он готов, но доступа у клиентов «АТОЛа» к нему нет.

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

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

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

Главный вывод для разработчика: не забывайте напоминать клиенту о продвижении продукта и сборе отзывов уже через месяц-два. Иначе какой смысл в Scrum, если продуктом даже через год никто не пользуется.

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

Написать
{ "author_name": "Максим Опилкин", "author_type": "self", "tags": [], "comments": 90, "likes": 55, "favorites": 105, "is_advertisement": false, "subsite_label": "life", "id": 51307, "is_wide": false, "is_ugc": true, "date": "Tue, 20 Nov 2018 13:20:35 +0300" }
{ "id": 51307, "author_id": 83845, "diff_limit": 1000, "urls": {"diff":"\/comments\/51307\/get","add":"\/comments\/51307\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/51307"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 199123, "possessions": [] }

90 комментариев 90 комм.

Популярные

По порядку

Написать комментарий...
8

А где Заказчик?

Ответить
2

закладки искал

Ответить
5

Вот же оно! "Создать продукт на основе доверия" - это отличная формулировка!!! Ее очень не хватало, когда продавали проекты лет 10 назад. Тогда не говорили про waterfall и scrum, называли это "по ТЗ" и "по почасовке" (не совсем то же самое, но почти). И, конечно же, мы хотели работать "по почасовке", а клиент предпочитал "по ТЗ". И вот сейчас я поняла, что имело смысл заговорить с ним именно про доверие, и продавать было бы проще. Спасибо за статью!

Ответить
4

А вот что выдает интернет: Скрам – это фреймворк для разработки и поддержки функционально сложных продуктов. Данное руководство содержит определение Скрама. Определение состоит из описания ролей, мероприятий, артефактов Скрама, а также правил, связывающих их. Кен Швабер и Джефф Сазерленд разработали Скрам; Скрам Гайд написан и представлен ими.

Черт ногу сломит

Ответить
1

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

Ответить
1

Екатерина, Вы правы, я после фразы "Создать продукт на основе доверия" понял что это что-то стоящее.

Ответить
2

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

Ответить
2

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

Ответить
0

прям любой участник?

Ответить
0

дилетантов не держим

Ответить
0

Дмитрий, на картах как раз числа из ряда Фибоначчи. Спасибо за дополнение

Ответить
2

Поправки в текст:
- В результате выполнения спринта имеем (или не имеем) - готовый инкремент продукта (а не закрытые таски).
- Цель спринта задаёт команда скрама (не только PO).
- В скрам не оговорено в чем оценивать таски - подойдет любой инструмент, в том, числа и оценка в чел/часах (да, это легально и часто используется на практике).

+ надо помнить что команды в скрам две: команда скрама (SM+PO+разработчики) и команда разработки (без PO и SM). В тексте эти 2 команды смешаны в кучу.

Ответить
0

по поводу инкрементов еще: по факту заказчику демонстрировали чаще всего готовый (или не готовый) инкремент продукта. На доски с тасками редко опирались в конце спринта.

Ответить
2

Не подскажите, каким образом у вас аналитик подстраховывает девопса?)

Ответить
0

с помощью знаний, умений, навыков

Ответить
2

Памятка для Заказчика: если работать по скраму - не получится как обычно валить все на тупых разработчиков. ("мы же говорили"... "а вы нам обещали"... "это само собой разумеется, исходя из 12-58 стр. ТЗ версия от 11.02.2003"). Идеология общей команды подразумевает и общую ответственность.
Памятка для Исполнителей: собрать команду дилетантов-джунов и назначить им три проекта одновременно - не прокатит. Прозрачность там... транспэренси.. доступ Заказчика в кишочки проекта (таск-менеджеры).
Памятка для продавцов: доверие - штука обоюдоострая... Если продавать проект на доверии, то и самому над быть откровенным. Навешать лапши при продаже, а потом: "разберемся по ходу обследования/тз"... никак. Нет обследования - одни спайки..

Ответить
0

вы случайно не управляете проектами?

Ответить
0

смотря что считать за проект. В каком-то смысле: я всегда управляю проектами!

Ответить
1

Кто в начале расскажет заказчику, сколько он в итоге заплатит? Или сюрприз будет?

Ответить
1

Изначально проект разбиваем на стори, стори предварительно набираем в спринты. Стараемся с заказчиком сформулировать цели спринтов. Зная стоимость команды даём предварительный бюджет. С заказчиком согласовываем цели и то, что +- спринт может быть.
Если изначально планируется более 6 спринтов, то дельта менее 15%. Для заказчика это нормально :)

Ответить
1

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

Ответить
1

Часто заказчик приносит функциональные требования с разной степенью проработки.
Мы их перерабатываем в стори и показываем мы видим реализацию.
Бюджет мы не фиксируем, но берем обязательства уложиться в то количество спринтов, которое обозначили. Обе стороны понимают, что изменения могут быть и будут.
Иногда запускаем нулевой спринт - вместе с заказчиков готовим подробно стори и описание, чтобы стартануть разработку и сделать нормальное планирование.
У такого спринта своя цель и стоимость, поскольку там меньше участников.

Ответить
0

При этом, если спринт неудачный и не сделали все что наметили вы ответственности никакой не несёте, просто переносите задачи на следующий. Максимальные последствия - без пиццы остались. Так?

Ответить
0

У разработчиков действительно нет финансовой мотивации на выполнение спринтов.
Если делать премию в зависимости от закрытых задач, то вся идея открытости превращается в фарс - разрабочики стараются растянуть оценку, чтобы точно укладываться в сроки. От этого зависит их уровень дохода.
Для разработчиков же важнее научиться правильно планировать, видеть результат улучшения процессов после ретроспективы.
А успешный спринт - это показатель профессионализма.
Данные об итогах спринта публичные. И все команды видят статусы по спринтам. Это тоже сделали сознательно.

Ответить
0

Советую обратить внимание на Reliable Scrum, первые строчки Гугла приведут на mnogosdelal, там и видео и шаблон excel.

Ответить
0

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

Ответить
0

это же не техасский холдем, это другой покер. Заказчик понимает.

Ответить
0

Мы заказчику показывали заранее сколько мы планируем говорить и когда. После 2 спринтов трудозатраты на это подтвердили и больше не возвращались в этой теме.

Ответить
0

Продакт-оунер сразу видит, за сколько спринтов он получит необходимый продукт, с примерным количеством стори-поинтов (если учесть фиксированное количество за спринт). Плюс-минус 10-15%.

Ответить
1

"в Scrum команда быстро реагирует на проблемы при решении задачи. Не надо ждать подтверждения на оплату дополнительных часов, чтобы их решить. Всё уже заложено в стори-поинтах." - не понятно, как это заложено. можно пояснить?

Ответить
1

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

Ответить
0

неуспешный сторипоинт, это по сути тот, который мы недооценили и в итоге делаем работы за свой счет без не эскалации на заказчика?

Ответить
2

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

Ответить
0

при такой оценке, когда у тебя НЕТ ПРАВА ошибатся -> это тебя толкает на завышение сложности (тоесть очковтирательству), если бы не было "штрафа" в виде переработок (типа обязан делать), за то что ты не верно оценил (обычное дело для людей у которых НЕТ МАШИНЫ ВРЕМЕНИ), можно было бы нормально работать, без всякого очковтирательства с оценками.

Ответить
0

ну а вы проповедуете подход "как получится - так получится". лимит ответственности - 2х-недельный спринт. все риски за конечный резульат несет заказчик. Конечно, очень комфортно.

Ответить
1

А не надо себе врать, другого варианта просто не существует, кто бы там что заказчикам не втирал, можно лишь предложить порядочное отношение к работе и попытаться сделать все что в твоих силах. Все остальное как получится так получится.
Заказчик как "предприниматель" в любом случае при любых раскладах несет полную ответственность за все свои действия (он же и получает за них всю прибыль). Неуспех проекта полностью на его плечах, даже если его проект слили дерьмовые исполнители, которые ему дичь втирали и что-то там "гарантировали". Таков закон бизнеса.
Главное себе самому не врать, веря в то что ты можешь переложить СВОИ бизнес риски на плечи исполнителей.
Не так просто найти людей с которыми можно двигаться на пути к успешному проекту.

Ответить
0

Попробуйте с такой позицией выйти на сколько-нибудь серьёзный тендер и с предложением делать по scrum без гарантии результата в договоре.))
найдите здравомыслящего it-директора на стороне заказчика, который пойдёт к руководству утверждать проект без определённого бюджета, но зато со стабильной оплатой спринтов 1-2 раза в месяц.

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

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

Ответить
0

В статье написано, что не сделанный сторипоинт улетает на следующий спринт. Какие переработки?

Ответить
0

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

Если не успеваем, то объясняем причины заказчику, иногда делаем переоценку, если заказчик с этим согласен.

Ответить
0

В статье вы пишете:
Не надо ждать подтверждения на оплату дополнительных часов, чтобы их решить. Всё уже заложено в стори-поинтах.

В комментах вы пишете:
Если не успеваем, то объясняем причины заказчику, иногда делаем переоценку, если заказчик с этим согласен.

Где правда?

Ответить
0

не, неуспешный не стори-поинт, а спринт )

Ответить
0

Понятнее не стало, даже как человеку работающему по скраму

Ответить
1

В России в принципе не просто с доверием. 10 лет назад еще тяжелее было, наверное )

Ответить
1

похож

Ответить
1

Окей, Grotem

Ответить
0

Какая мотивация у команды работать эффективно, если по сути ответственности за невыполнение спринта нет и бюджет резиновый?

Ответить
2

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

Но это работает только в случае полной открытости со стороны исполнителя. Мы начали так работал только тогда, когда стали уверенны в команде.
До этого было страшно.. :)

Ответить
1

Сколько громких слов)) в моей приземленной картине мира лучшей мотивацией для разработчика является хороший оклад+премия от эффективности. А нематериальная мотивация больше подходит для джуниоров.

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

Ответить
1

Мотивация деньгами работает на коротком отрезке, далее уже не работает, далее работает "Хочу интересные задачи и видеть довольные глаза Пользователя/Заказчика = Признание".

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

Ответить
0

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

Вы плохо разглядели. я работал по обоим схемам - и оклад и сделка.

Ответить
0

вы прям по Scrum работали?

Ответить
0

я работал по технологии, когда у программистов есть план работ, разбитый по задачам объемом 2-3 дня. еженедельный контроль результатов и актуализация плана. мотивация - оклад+премия от выполнения плана.
это подходит под определение scrum ?

Ответить
0

простите, но боюсь, что не совсем

Ответить
0

чем не подходит?

Ответить
1

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

Ответить
0

Манифест на то и манифест, чтобы в нем идеологию писать, а вот методологию пишут уже во всяких официальных стандартах типа "the scrum Guide" - и там как раз про порядок декомпозиции задач и контроль их выполнения

Ответить
0

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

Ответить
0

если у вас получалось работать - скажите пожалуйста, много ли было в команде исполнителей возраста 30+ у которых горели глаза от интересных задач настолько, что они были готовы к неоплачиваемым переработкам?

Ответить
0

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

Ответить
0

не понял, поясните пожалуйста

Ответить
1

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

Ответить
0

Scrum - это такая же технология управления проектами как и водопад. В ней также есть постановка задач и контроль их исполнения. Главные отличия-это фиксированные отрезки времени и инкремент результата после каждого. Остальные философские термины, вроде "доверия" "открытости" и т. д. -это розовые очки, не имеющие отношения к технологии

Ответить
1

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

Ответить
0

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

Ответить
0

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

Ответить
0

не вижу ничего противоречащего, делишь проект на несколько этапов "спринтов", и все тоже самое для каждого (постановка, анализ, проектировка, реализация и тд)

Ответить
0

и все уложить в 2х недельный спринт?

Ответить
0

ну при желании можно сделать 2 полугодовых "спринта" (можно и один "спринт" длиною в год), главное придерживаться терминологии и методологии, чтоб все было по скраму!

Ответить
0

пфф, в СССР были спринты-пятилетки, съезды-ретроспективы, а в колхозах рассчитывали задачи не в деньгах, а трудоднях. Но это не Scrum

Ответить
0

Если Вы сейчас серьёзно, то дальнейшая дискуссия не имеет смысла

Ответить
0

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

Ответить
0

Интересует следующий вопрос: что за сервис используете? Буду премного благодарен)

Ответить
1

Мы используем Jira, в связке с confluence. Если интересно, есть курс на Курсере "Agile with Atlassian Jira": https://www.coursera.org/learn/agile-atlassian-jira

Ответить
0

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

Ответить
0

А что обязанности?

Ответить
0

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

Ответить
1

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

Ответить
0

Заказ пиццы высокооплачиваемым сотрудником - это не про эффективность

Ответить
1

Если ребята фигачат код и в потоке, то почему нет? Сделает это он сам через приложение Чегототам.Еда или скажет девочке-АХО вторично.

Ответить
0

И в магазин канцтоваров съездить, чего уж там. Если компания маленькая и отдельного ахо нет-ситуация понятная.

Ответить
0

Если вам за скрум заплатили деньги то дальнейшие претензии не принимаются

Ответить
0

у кого претензии? К кому?

Ответить
0

да любые. карте место

Ответить
1

ну ладно

Ответить
0

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

Ответить
0

Ребята, все круто! Вы молодцы! А что по поводу ревью? На нем же кроме заказчика должны присутствовать пользователи. Таким образом вы бы сразу обкатывали ваш продукт и уточняли беклог. То есть не надо специально напоминать заказчику о сборе фидбека как вы пишете в последнем выводе. Почитайте внимательно гайд по теме проведения ревью! Ну и практика есть уже :) если что пишите мне на фб, пообщаемся по этому вопросу!

Ответить
0
{ "page_type": "article" }

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fjog" } } }, { "id": 10, "disable": true, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "disable": true, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "p1": "bscsh", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "bugf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-223676-0", "render_to": "inpage_VI-223676-0-1104503429", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=bugf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudx", "p2": "ftjf" } } }, { "id": 16, "label": "Кнопка в шапке мобайл", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byzqf", "p2": "ftwx" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "bugf", "p2": "fzvc" } } }, { "id": 19, "label": "Тизер на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "p1": "cbltd", "p2": "gazs" } } } ]
Приложение-плацебо скачали
больше миллиона раз
Подписаться на push-уведомления
{ "page_type": "default" }