Особенности применения Scrum в заказной разработке

    В этой статье я расскажу об особенностях Scrum в заказной разработке, которая отличается от «тепличных» условий внутренней разработки. Можно ли применять Scrum в условиях рынка и на что надо обратить внимание прежде всего. Добро пожаловать под кат и в комментарии.

    Как продать Scrum заказчику?

    Первый вопрос, который обычно возникает, это «Как продать Scrum заказчику?», ведь его не очень волнует, каким иностранным словом вы называете свои внутренние процессы. На данном этапе очень важно объяснить заказчику (полагаем, что спринты у нас двухнедельные), что он сможет:
    • каждые две недели получать новый функционал, который можно попробовать и выпустить на рынок для заработка денег,
    • каждые две недели менять требования, чтобы изменения в бизнесе отражались и в ПО,
    • регулировать сроки и стоимость работ по проектам за счет возможности остановить проект после любого спринта;

    Второй вопрос, который появляется сразу после первого: «Как отразить процесс в контракте?». Самым лучшим вариантом здесь будет заключение контракта типа «Время и материалы» (Time and Material, T&M), при котором заказчик будет оплачивать вам стоимость команды плюс оговоренный процент. Преимуществом такого вида контракта является управление по срокам и стоимости со стороны заказчика, но надо заметить, что при таком подходе и риски перекладываются на него. Еще отмечу, что при таком подходе резко сокращается этап анализа проекта, так как нет необходимости давать точную оценку сроков и гарантировать ее.

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

    Нулевой спринт

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

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

    Следующим этапом идет выявление персон и их активностей (вплоть до отдельных юзер-стори), которые фактически являются легковесным и более визуальным вариантом экторов и юзкейсов. Уже традиционно данную активность Scrum-команды реализуют в виде Story mapping, результатом которого становятся доски и целые стены с визуализацией активностей в проекте:



    Обязательно надо вытащить представителей заказчика на процессы по выработке видения и Story mapping (а на последний еще потенциальных пользователей).
    Обратная сторона монеты – это выбор платформы для разработки и создания архитектуры. Конечно, я имею в виду не Big Upfront Design, а более гибкий подход, ведь десятки или сотни диаграмм, пылящихся в дальнем ящике стола – это не наша цель. Наша задача сделать продукт, минимизировав потери.



    В самом простом случае можно ограничиться диаграммой предметной области с максимально простым синтаксисом, который будет понятен и заказчику. В более сложных случаях эту диаграмму стоит дополнить до диаграммы классов и набрать в корзину архитектуры еще несколько UML-диаграмм, которые помогут описать динамическую часть вашей системы.
    Можно взять ICONIX в качестве подмножества UML и процесса (см. мою презентацию c AgileDays в Екатеринбурге), но он будет скорее замещать Story Mapping, чем дополнять его.
    В нулевой спринт входит и подготовка к первому спринту. Для этого необходимо юзер-стори описать, спроектировать для них интерфейс и оценить. Работу лучше всего построить в таком порядке, так как он способствуем более качественному пониманию требований и их оценке.

    Практики Scrum или посадить заказчика на итеративную иглу

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

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

    В следующий раз мы поговорим о том, как скрестить управление рисками и Agile.

    Автор: Борис Вольфсон — Руководитель департамента разработки Softline
    Softline
    Company

    Comments 25

      0
      У нас в проекте часть работ отдана на аутсорсинг и подрядчика сами просим работать с нами по SCRUM-у (product owner и manager с нашей стороны, т.е. по сути — аутстаффинг). И как-то туго получается… Хотя для внутренних команд все более или менее.
        +2
        То, что вы описываете — это совсем обратная ситуация ) это не продажа «времени-материалов» конечному заказчику, о которой речь идет в статье, а навязывание работы по SCRUM'у своему подрядчику.

        Тема не менее интересная, кстати, но отлаженный процесс работы исполнителя (какой бы он ни был), ломать не стоит, проще просто договориться о демонстрациях каждые 2 недели, например. Подогнать под принятые вами итерации.
        0
        Както скудно, честно говоря. Всегда интереснее практический опыт, что и как конкретно делается у каждого на кухне. У меня, в общем, положительный опыт использования scrum'а.
        Про инновационные игры интересно, спасибо.
          0
          А какие аспекты конкретно интересуют? У меня есть желание еще написать на данную тему…
            0
            Самое интересное это то, что не сработало. Пробовали но «не пошло». Ну или как адаптировали «под себя» какие-то техники.
        • UFO just landed and posted this here
            +2
            Это у вас meeting driven development, а не скрам.
            • UFO just landed and posted this here
                0
                При правильном соотношении длины спринта (2 недели), количестве человек (4 девелопера, 1-2 тестера) в команде получается, что:
                1 день уходит на планинг, 1 час на ретроспекцию, полчаса на шоукейс (его может проводить 1 человек из команды) и по 5-10 минут ежедневно стендапов. От этого получается большая польза — все знают что происходит в проекте, видят/решают проблемы. Это только помогает, и бесполезного времени не добавляет.

                Остальные митинги проводит скрам-мастер, либо они архитектурные и от них не уйти нигде.
                • UFO just landed and posted this here
                  +1
                  >Если мне не изменяет память — где-то до 30% времени уходит именно на обслуживание процесса.

                  У нас в команде Скрам практикуется в течение года (причем именно классический Скрам со всеми его элементами, а не «немного отсюда, немного оттуда»). Живые данные из живого проекта: планирование спринта: 1 час, демо/ретроспектива: 1 час, стенд-апы: 15 минут ежедневно. Продолжительность спринта: 2 недели. Итого, накладные расходы по обслуживанию одного спринта: 1 + 1 + 0.25*10 = 4.5 часа за 2 недели.

                  Разумеется, отдельной статьёй идёт составление бэклога, «покер», разбиение юзерстори на задачи и прочие подготовительные процедуры, проводимые в самом начале, но от них никуда не деться и при «водопаде», и при любой другой методике управления жизненным циклом проекта.
                  • UFO just landed and posted this here
                      0
                      «Отдельной статьёй» как раз потому, что присутствует везде, а я рассматривал дополнительный оверхед скрама по сравнению с водопадом и остальными методиками.
                    +1
                    Длинные митинги и их большое количество — это не скрам, а некачественная работа скрам-мастера :) Скрам — это гибкая методология с жестким таймбоксингом…
                +2
                Самое сложное это пропихнуть scrum там, где есть тендер. Т.е. приходит заказчик и говорит: «Скажите скока стоит это, а я сравню с другими предложениями», правда речь идет не о крайностях типа соперничества с индусами.

                Самое ведь интересное, что, как и написано в статье, во-первых все риски будут перезаложены в стоимости, плюс 100% появятся ситуации типа: "- а вот это добавить можно? — Так мы на это не договаривались! — Ну хорошо, за доп деньги" и тут наступает рай для проекта который непопадает в срок. В оценки и стоимость вкладывается и непопадание, и риски и сама работа.

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

                В другом случае получается, что Скрам — это просто стендапчики и отсутствие документации. Заказчик лениво появляется на митингах, никогда не трогает продукт до сдачи, угрожает сроками. А это уже не скрам.
                  +1
                  Проблема в том, что в классическом управлении изменениями требований дополнительно в бюджет закладываются не только риски, которые появляются при новых требованиях, но и уже сделанные промахи исполнителя. В итоге получается, что цена проекта вроде бы небольшая, а любое изменение — очень дорогое.
                  • UFO just landed and posted this here
                  +1
                  Вы перечислили вкусные для заказчика приемущества скрама. И T&M для разработчика — просто мечта.
                  Но как бороться с основным недостатком скрама для заказчика — нельзя заранее спланировать расходы на проект? Собственно заказчика как раз и интересует то, что вы берете на себя все риски, а он просто платит сумму N.
                  Как быть?
                    +1
                    На мой взгляд, никто не отменял опыт исполнителя, и никто не отменял возможность предварительной хотя бы сравнительной оценки расходов при реализации любого функционала.
                    Более того, все равно происходит первоначальный сбор требований по всему функционалу (не детально, без аналитики практически любой заказчик может представлять себе свой проект), и на основе этих данных можно предварительно давать вилки цен.
                      +1
                      Я бы еще добавил, что через пару спринтов, можно уже давать оценки по завершению проекта на основе реальной скорости команды и скорости добавления новых фич. Просто называете этот период «прототипирование» или «предварительное проектирование» и затем уже идет «разработка проекта».
                      +1
                      Госзаказ — лесом. Только fixed cost.

                      Что касается коммерческих заказчиков — то здесь все намного проще. Дело в том, что (ну, может это только у нас так), заказчик начинает понимать чего он на самом деле хочет только увидев уже работающий функционал. 90% не может сформулировать с 0, а в виде дельты с тем что уже есть — каждый. К тому же, фантазия у людей начинает работать. Так что митинги с заказчиком все равно будут и много раз, просто они могут быть до дедлайна или после.
                        0
                        По поводу fixed cost: опять же можно отлично использовать внутри скрам, конечно, все бенефиты скрама вы в итоге не получите.
                          0
                          Согласен. И именно потому, что заказчик сам начинает понимать процесс, подсажен на итерации, как-то даже поинтересовался, что такое scrum, сам понимает в процессе работы, что ему нужно, при этом он сам понимает скорость и соответственно стоимость разработки своих «хотелок», тем нам лучше, как подрядчику-исполнителю. При этом нужно только обеспечить качественное тестирование и приемлемую скорость разработки фич.
                          И именно в его же (заказчика) интересах проводить митинги (по сути участвовать в планировании, ретроспективах и обсуждать фичи с аналитиком) во время работы по принципу «время-материалы».
                          0
                          А что пишете по Scrum — если без NDA?
                            0
                            мне кажется, что для того, чтобы работать по SCRUM нужно:

                            0) всё руководство (менеджеры, техлиды, аналитики и т.д.) должны быть знакомы со SCRUM лично, хотя бы побывав на семинаре, а не просто прочитав в интернете.
                            1) Единство и вера руководства, что работа по SCRUM решает их задачу лучше, чем методологии из их прошлого опыты (как правило waterfall)
                            2) Дипломатия. Умение решать конфликты с заказчиком, которому все нужно и сразу и он не хочет платить за changeRequest.
                            3) Фикс прайс. У заказчика есть ожидания и бюджет, который нужно освоить, но не более. Он хочет за те же деньги больше, чем это можно сделать. Scrum это исключает, поэтому заказчику не нравится (находятся те, кто готов плясать под их дудку)
                            4)Scrum Master должен сам соблюдать и пресекать нарушения правил SCRUM: митинги больше 15 минут или сидя, разговор «не по делу», неверное планирование (поднажмём и сделаем), сложившаяся иерархия руководителей, которые дают задания. Это опять вопрос убежденности, что SCRUM поможет, если всем всё делать по правилам.
                            5) Вера ВСЕЙ команды, что scrum лучше чем «давайте просто кодить» или «дайте задание».

                            Написав эти строки сложилось мнение, что скрам зависит на 90% от веры. Но т.к. весь предыдущий опыт большинства разработчиков скорее всего был негативным и они получили по шапке незаслуженно, то у всех страшная боязнь всего нового: кто-то боится персональной ответственности, кого-то много отвлекали бесполезными митингами по 2 часа каждый день, кто-то просто не понимает, зачем это нужно и хочет делать как раньше (там же можно ни чего не делать).

                            Only users with full accounts can post comments. Log in, please.