Comments 25
У нас в проекте часть работ отдана на аутсорсинг и подрядчика сами просим работать с нами по SCRUM-у (product owner и manager с нашей стороны, т.е. по сути — аутстаффинг). И как-то туго получается… Хотя для внутренних команд все более или менее.
То, что вы описываете — это совсем обратная ситуация ) это не продажа «времени-материалов» конечному заказчику, о которой речь идет в статье, а навязывание работы по SCRUM'у своему подрядчику.
Тема не менее интересная, кстати, но отлаженный процесс работы исполнителя (какой бы он ни был), ломать не стоит, проще просто договориться о демонстрациях каждые 2 недели, например. Подогнать под принятые вами итерации.
Тема не менее интересная, кстати, но отлаженный процесс работы исполнителя (какой бы он ни был), ломать не стоит, проще просто договориться о демонстрациях каждые 2 недели, например. Подогнать под принятые вами итерации.
Както скудно, честно говоря. Всегда интереснее практический опыт, что и как конкретно делается у каждого на кухне. У меня, в общем, положительный опыт использования scrum'а.
Про инновационные игры интересно, спасибо.
Про инновационные игры интересно, спасибо.
UFO just landed and posted this here
Это у вас meeting driven development, а не скрам.
UFO just landed and posted this here
При правильном соотношении длины спринта (2 недели), количестве человек (4 девелопера, 1-2 тестера) в команде получается, что:
1 день уходит на планинг, 1 час на ретроспекцию, полчаса на шоукейс (его может проводить 1 человек из команды) и по 5-10 минут ежедневно стендапов. От этого получается большая польза — все знают что происходит в проекте, видят/решают проблемы. Это только помогает, и бесполезного времени не добавляет.
Остальные митинги проводит скрам-мастер, либо они архитектурные и от них не уйти нигде.
1 день уходит на планинг, 1 час на ретроспекцию, полчаса на шоукейс (его может проводить 1 человек из команды) и по 5-10 минут ежедневно стендапов. От этого получается большая польза — все знают что происходит в проекте, видят/решают проблемы. Это только помогает, и бесполезного времени не добавляет.
Остальные митинги проводит скрам-мастер, либо они архитектурные и от них не уйти нигде.
>Если мне не изменяет память — где-то до 30% времени уходит именно на обслуживание процесса.
У нас в команде Скрам практикуется в течение года (причем именно классический Скрам со всеми его элементами, а не «немного отсюда, немного оттуда»). Живые данные из живого проекта: планирование спринта: 1 час, демо/ретроспектива: 1 час, стенд-апы: 15 минут ежедневно. Продолжительность спринта: 2 недели. Итого, накладные расходы по обслуживанию одного спринта: 1 + 1 + 0.25*10 = 4.5 часа за 2 недели.
Разумеется, отдельной статьёй идёт составление бэклога, «покер», разбиение юзерстори на задачи и прочие подготовительные процедуры, проводимые в самом начале, но от них никуда не деться и при «водопаде», и при любой другой методике управления жизненным циклом проекта.
У нас в команде Скрам практикуется в течение года (причем именно классический Скрам со всеми его элементами, а не «немного отсюда, немного оттуда»). Живые данные из живого проекта: планирование спринта: 1 час, демо/ретроспектива: 1 час, стенд-апы: 15 минут ежедневно. Продолжительность спринта: 2 недели. Итого, накладные расходы по обслуживанию одного спринта: 1 + 1 + 0.25*10 = 4.5 часа за 2 недели.
Разумеется, отдельной статьёй идёт составление бэклога, «покер», разбиение юзерстори на задачи и прочие подготовительные процедуры, проводимые в самом начале, но от них никуда не деться и при «водопаде», и при любой другой методике управления жизненным циклом проекта.
Длинные митинги и их большое количество — это не скрам, а некачественная работа скрам-мастера :) Скрам — это гибкая методология с жестким таймбоксингом…
Самое сложное это пропихнуть scrum там, где есть тендер. Т.е. приходит заказчик и говорит: «Скажите скока стоит это, а я сравню с другими предложениями», правда речь идет не о крайностях типа соперничества с индусами.
Самое ведь интересное, что, как и написано в статье, во-первых все риски будут перезаложены в стоимости, плюс 100% появятся ситуации типа: "- а вот это добавить можно? — Так мы на это не договаривались! — Ну хорошо, за доп деньги" и тут наступает рай для проекта который непопадает в срок. В оценки и стоимость вкладывается и непопадание, и риски и сама работа.
Поэтому хорошо, когда заказчик говорит — есть такой бюджет, давайте делать. А потом смотрится по ситуации, какая функциональность критична, а какая нет. Всегда можно что-то выбросить, если не укладывается в бюджет. А это возможно, когда заказчик участвует в митингах и делится планами и намерениями.
В другом случае получается, что Скрам — это просто стендапчики и отсутствие документации. Заказчик лениво появляется на митингах, никогда не трогает продукт до сдачи, угрожает сроками. А это уже не скрам.
Самое ведь интересное, что, как и написано в статье, во-первых все риски будут перезаложены в стоимости, плюс 100% появятся ситуации типа: "- а вот это добавить можно? — Так мы на это не договаривались! — Ну хорошо, за доп деньги" и тут наступает рай для проекта который непопадает в срок. В оценки и стоимость вкладывается и непопадание, и риски и сама работа.
Поэтому хорошо, когда заказчик говорит — есть такой бюджет, давайте делать. А потом смотрится по ситуации, какая функциональность критична, а какая нет. Всегда можно что-то выбросить, если не укладывается в бюджет. А это возможно, когда заказчик участвует в митингах и делится планами и намерениями.
В другом случае получается, что Скрам — это просто стендапчики и отсутствие документации. Заказчик лениво появляется на митингах, никогда не трогает продукт до сдачи, угрожает сроками. А это уже не скрам.
Вы перечислили вкусные для заказчика приемущества скрама. И T&M для разработчика — просто мечта.
Но как бороться с основным недостатком скрама для заказчика — нельзя заранее спланировать расходы на проект? Собственно заказчика как раз и интересует то, что вы берете на себя все риски, а он просто платит сумму N.
Как быть?
Но как бороться с основным недостатком скрама для заказчика — нельзя заранее спланировать расходы на проект? Собственно заказчика как раз и интересует то, что вы берете на себя все риски, а он просто платит сумму N.
Как быть?
На мой взгляд, никто не отменял опыт исполнителя, и никто не отменял возможность предварительной хотя бы сравнительной оценки расходов при реализации любого функционала.
Более того, все равно происходит первоначальный сбор требований по всему функционалу (не детально, без аналитики практически любой заказчик может представлять себе свой проект), и на основе этих данных можно предварительно давать вилки цен.
Более того, все равно происходит первоначальный сбор требований по всему функционалу (не детально, без аналитики практически любой заказчик может представлять себе свой проект), и на основе этих данных можно предварительно давать вилки цен.
Я бы еще добавил, что через пару спринтов, можно уже давать оценки по завершению проекта на основе реальной скорости команды и скорости добавления новых фич. Просто называете этот период «прототипирование» или «предварительное проектирование» и затем уже идет «разработка проекта».
Госзаказ — лесом. Только fixed cost.
Что касается коммерческих заказчиков — то здесь все намного проще. Дело в том, что (ну, может это только у нас так), заказчик начинает понимать чего он на самом деле хочет только увидев уже работающий функционал. 90% не может сформулировать с 0, а в виде дельты с тем что уже есть — каждый. К тому же, фантазия у людей начинает работать. Так что митинги с заказчиком все равно будут и много раз, просто они могут быть до дедлайна или после.
Что касается коммерческих заказчиков — то здесь все намного проще. Дело в том, что (ну, может это только у нас так), заказчик начинает понимать чего он на самом деле хочет только увидев уже работающий функционал. 90% не может сформулировать с 0, а в виде дельты с тем что уже есть — каждый. К тому же, фантазия у людей начинает работать. Так что митинги с заказчиком все равно будут и много раз, просто они могут быть до дедлайна или после.
По поводу fixed cost: опять же можно отлично использовать внутри скрам, конечно, все бенефиты скрама вы в итоге не получите.
Согласен. И именно потому, что заказчик сам начинает понимать процесс, подсажен на итерации, как-то даже поинтересовался, что такое scrum, сам понимает в процессе работы, что ему нужно, при этом он сам понимает скорость и соответственно стоимость разработки своих «хотелок», тем нам лучше, как подрядчику-исполнителю. При этом нужно только обеспечить качественное тестирование и приемлемую скорость разработки фич.
И именно в его же (заказчика) интересах проводить митинги (по сути участвовать в планировании, ретроспективах и обсуждать фичи с аналитиком) во время работы по принципу «время-материалы».
И именно в его же (заказчика) интересах проводить митинги (по сути участвовать в планировании, ретроспективах и обсуждать фичи с аналитиком) во время работы по принципу «время-материалы».
А что пишете по Scrum — если без NDA?
мне кажется, что для того, чтобы работать по SCRUM нужно:
0) всё руководство (менеджеры, техлиды, аналитики и т.д.) должны быть знакомы со SCRUM лично, хотя бы побывав на семинаре, а не просто прочитав в интернете.
1) Единство и вера руководства, что работа по SCRUM решает их задачу лучше, чем методологии из их прошлого опыты (как правило waterfall)
2) Дипломатия. Умение решать конфликты с заказчиком, которому все нужно и сразу и он не хочет платить за changeRequest.
3) Фикс прайс. У заказчика есть ожидания и бюджет, который нужно освоить, но не более. Он хочет за те же деньги больше, чем это можно сделать. Scrum это исключает, поэтому заказчику не нравится (находятся те, кто готов плясать под их дудку)
4)Scrum Master должен сам соблюдать и пресекать нарушения правил SCRUM: митинги больше 15 минут или сидя, разговор «не по делу», неверное планирование (поднажмём и сделаем), сложившаяся иерархия руководителей, которые дают задания. Это опять вопрос убежденности, что SCRUM поможет, если всем всё делать по правилам.
5) Вера ВСЕЙ команды, что scrum лучше чем «давайте просто кодить» или «дайте задание».
Написав эти строки сложилось мнение, что скрам зависит на 90% от веры. Но т.к. весь предыдущий опыт большинства разработчиков скорее всего был негативным и они получили по шапке незаслуженно, то у всех страшная боязнь всего нового: кто-то боится персональной ответственности, кого-то много отвлекали бесполезными митингами по 2 часа каждый день, кто-то просто не понимает, зачем это нужно и хочет делать как раньше (там же можно ни чего не делать).
0) всё руководство (менеджеры, техлиды, аналитики и т.д.) должны быть знакомы со SCRUM лично, хотя бы побывав на семинаре, а не просто прочитав в интернете.
1) Единство и вера руководства, что работа по SCRUM решает их задачу лучше, чем методологии из их прошлого опыты (как правило waterfall)
2) Дипломатия. Умение решать конфликты с заказчиком, которому все нужно и сразу и он не хочет платить за changeRequest.
3) Фикс прайс. У заказчика есть ожидания и бюджет, который нужно освоить, но не более. Он хочет за те же деньги больше, чем это можно сделать. Scrum это исключает, поэтому заказчику не нравится (находятся те, кто готов плясать под их дудку)
4)Scrum Master должен сам соблюдать и пресекать нарушения правил SCRUM: митинги больше 15 минут или сидя, разговор «не по делу», неверное планирование (поднажмём и сделаем), сложившаяся иерархия руководителей, которые дают задания. Это опять вопрос убежденности, что SCRUM поможет, если всем всё делать по правилам.
5) Вера ВСЕЙ команды, что scrum лучше чем «давайте просто кодить» или «дайте задание».
Написав эти строки сложилось мнение, что скрам зависит на 90% от веры. Но т.к. весь предыдущий опыт большинства разработчиков скорее всего был негативным и они получили по шапке незаслуженно, то у всех страшная боязнь всего нового: кто-то боится персональной ответственности, кого-то много отвлекали бесполезными митингами по 2 часа каждый день, кто-то просто не понимает, зачем это нужно и хочет делать как раньше (там же можно ни чего не делать).
Sign up to leave a comment.
Особенности применения Scrum в заказной разработке