После публикации интервью Асхата Уразбаева «Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану» у участников Сообщества Executive.ru возникли вопросы о сущности гибкой методологии. Я хочу рассказать о несложном кейсе из практики компании ScrumTrek, после которого, надеюсь, многое прояснится.
Этот проект был выполнен где-то год назад. Он длился примерно восемь месяцев. Мы реализовывали его для заказчика из банковского сектора. В этом банке назрела потребность переделать одну из своих подсистем, отвечавших за взаимодействие с клиентами.
Информационная система, которой пользовался банк, не отражала его потребности. Она была сделана некоторое время назад и предполагала, что клиенты банка – физические лица – будут выполнять те или иные операции самостоятельно, без обращения к операционисту. Если клиент не мог выполнить операции и обращался к сотруднику банка, это рассматривалось как отрицательный результат. Банк хотел исправить ситуацию, снизить нагрузку на штат и сократить некоторое количество рабочих мест. Наверное, с точки зрения управления людьми эта цель была не очень… экологичная, но от подобной ситуации уйти невозможно: автоматизация деятельности очень часто приводит к сокращению рабочих мест.
Проект был оценен и должен был быть выполнен в течение 9 месяцев. Оценка проводилась привычным для банка методом и планировалось делать проект по каскадной модели.
Практика банка показывала, что проекты очень часто затягиваются и затягиваются достаточно сильно, иногда и в два раза от первоначальной оценки. Руководство было недовольно этим фактом, поэтому решило попробовать реализовать этот проект с использованием Scrum, и нас привлекли для помощи с организацией Agile-процесса.
Мы собрали команду всех необходимых для реализации проекта специалистов из сотрудников банка. Размер команды был в рамках требований Scrum. Всех людей пересадили в один офис, рядом друг с другом. Прежде они никогда не работали в такой тесной коммуникации. Только один участник проекта работал в удаленном доступе, но у него был небольшой фронт работы. Этот сотрудник тем не менее участвовал во всех рабочих встречах.
Роль нашей компании состояла во внешнем консультировании. Мы помогли команде выполнить все необходимые процедуры, обучили их Scrum, помогли провести стартовать производственный процесс и несколько месяцев сопровождали работу команды.
Нулевой спринт был посвящен формулировке базовых знаний по проекту.
Команда, как это обычно бывает, прошла все стадии роста. В начале команда не очень понимала, как именно предстоит работать. Постепенно команда входила в роль, и на третьем-четвертом спринте вступила в этап шторма, то есть начала создавать и преодолевать конфликтные ситуации – это тоже было ожидаемо. Поскольку команде удалось преодолеть противоречия, к четвертому спринту она подготовила продуктивную среду и готовое описание функционала.
Поскольку команда двигалась в соответствии со Story mapping, она старалась как можно быстрее реализовать функционал для конечного пользователя, хотя бы и в минимальном объеме. Начиная с четвертого спринта продукт с ограниченным функционалом был выведен в прод, и здесь начинается самое интересное: команда начала получать обратную связь от пользователей.
В нашем случае заказчик и пользователь – не одно и то же. Заказчик – подразделение банка, которое может поделиться своим видением проекта, а пользователь – клиент банка, у пользователя может быть свое видение, предугадать которое очень трудно. Поэтому те кусочки функционала, которые были готовы на четвертом спринте, команда решила показать именно конечному пользователю.
Этого конечного пользователя команда решила найти в лице самих сотрудников банка. Им отправили письмо примерно такого содержания: «Коллеги, мы разрабатываем такую-то систему, мы пытаемся сделать ее максимально удобной и правильной. С сегодняшнего дня вы переводитесь на обслуживание этой системы, и если вы видите какие-то проблемы или хотите улучшить наш продукт – вот вам все координаты для обратной связи». В ответ на это письмо пошли сигналы обратной связи. Мы начали вносить изменения в журнал продукта, в котором фиксировались заявки на разработку новых функций. Таким образом продукт пришел в движение.
В итоге через девять месяцев мы получили весь функционал, который был нужен заказчику, и который был заложен в проект. Но функционал этот был реализован с учетом требований конечного пользователя, вот в чем особенность.
Мы могли строго следовать ТЗ, которое получили от заказчика, и выдать ему в срок точно то, что он заказывал (так обычно и реализуются проекты, построенные по каскадной модели разработки). Однако это был бы совершенно иной продукт. После того, как он был бы принят в эксплуатацию, его пришлось бы дорабатывать в соответствии с требованиями конечного пользователя. Так обычно и происходит: доработка превращается в самостоятельный проект, который требует ресурсов.
Мы же включили требования конечного пользователя на раннем этапе разработки. При этом, приступая к проекту, мы эти требования еще не представляли. В этом и есть пример применения гибких методологий управления производственными процессами: как можно раньше показать реальному пользователю продукт и наладить цикл обратной связи, чтобы постоянно корректировать продукт к потребностям конечных пользователей.
Очень важно – на каком этапе в проект вносятся изменения. Если изменение влияет только на какую-то презентационную часть, например, на веб-приложение, это одна ситуация. В данном случае объем доработок может быть не очень велик.
Совершенно иное дело, если изменение функционала влияет на архитектуру. В этом случае стоимость внесения изменений очень велика.
Разница между Scrum и Waterfall в том, что Scrum позволяет эти изменения вносить на раннем этапе. Смысл именно в этом. Понятно, что возможности гибких методологий не исчерпываются исключительно теми приемами, о которых я рассказал.
К автору статьи и другим сторонникам Scrum.
Цитата: "Разница между Scrum и Waterfall в том, что Scrum позволяет эти изменения вносить на раннем этапе."
Объясните, пожалуйста, что именно в Waterfall мешает (не позволяет) вносить изменения на раннем этапе? Я этого не понимаю потому, что в моей персональной практике мне этому НИЧТО не мешало. Мне теперь интересно что мешает другим....
Сам смысл, сделать декомпозицию таким образом, чтобы, как можно быстрее, ограниченный функционал (но функционал несущий маркетинговую ценность) показать потребителю (или ограниченной группе потребителей), чтобы понять - наша продуктовая гипотеза верна или нет. т.е. по сути мы пытаемся сьесть слона не просто разрезав его на куски, а разрезав так, чтобы каждый кусочек был слоном. Т.е. если мы делаем проект по выпуску, ну допустим, новой банковской услуги, который по оценкам укладывается в один год, то мы должны как можно раньше выкатить в ограниченный продуктив эту услугу и дать её пощупать пользователям в идеале в течении первого месяца после старта проекта. Пусть в жизненном цикле процесса получения услуги есть кастомные шаги, пусть подключены не все каналы общения с клиентом, пусть услугу может получить только резидент РФ и существующий клиент банка, пусть в первом самом виде её получит только тот, у кого точно нет задолженности перед банком, да пусть это будет хоть Иванов Иван Иванович - сотрудник банка, но он эту услугу попытается получить и даст нам обратную связь. А уж как дальше развивать продукт - это второе дело, дорабатываем функционал и обрабатываем запросы на изменения.
P.S. И все вышеописанное не значит что мы жертвуем качеством, программы не должны падать, сервера зависать а web-страницы выдавать коды ошибок
Алексей Пименов, благодарю Вас за развернутый рассказ. Но мой вопрос: "что именно в Waterfall мешает (не позволяет) вносить изменения на раннем этапе?" остался без ответа.
Можете на него ответить?
То, о чем Вы совершенно правильно пишете, я успешно применял еще когда слова Scrum в природе не существовало. Мы быстро делали прототип продукта для Иванова Ивана Ивановича, получали быструю обратную связь от пользователя, ну и т.д.
Что бы предотвратить словоблудие, ответ прошу начать словами: "В Waterfall мешает (не позволяет) вносить изменения на раннем этапе ....". Еще раз благодарю Вас.
Дискуссия отредактирована. Сообщения оф-топик удалены.
В Waterfall мешает (не позволяет) вносить изменения на раннем длительный этап сбора бизнес требований и длительный этап проектирования (Big Upfront Design) который не может быть проведен без, ну может не детальных, но всех бизнес требований.
Индикатором тут является фраза каждого первого архитектора, который не работал по Scrum: "Это невозможно сделать без полного набора БТ"
Аналогично может быть с постановщиками требований не являющимися основным заказчиком, например с Безопасниками. Они не хотят согласовывать требования итеративно-инкрементально, они не хотят смотреть поставки и давать фидбек, они хотят получить все требования на подписание сразу и смотреть только финальный результат
Но Scrum здесь "не панацея от всех болезней" .
Поэтому выбирают команду, у которой уже есть готовая платформа, достаточно опыта, и есть перспективы развития этой платформы - т.е. она не устареет в самое ближайшее время :). Тогда требования к безопасности, железу и выбору методов обеспечения жизненного цикла программного продукта понятны на самых ранних этапах разработки. Всё о чём пишут по поводу Agile, Scrum ... известно давно, мешала только бюрократия в ИТ - структурах и речь должна вестись о принципах организации структур. Если не менять эти принципы, Agile, Scrum, и многое другое работать не будет!!!
Вместо того, чтобы заявлять о полном наборе функциональных требований, опытные Архитекторы в начале выставляют требования, например:
1) в 10 раз, повысить производительность системы
2) обеспечить возможность совместной работы 100000 пользователей одновременно,
3) безопасность работы системы от возможных угроз.
а потом уже всё остальное , причём что-то уточняется в ходе работ, и современные средства разработки ПО позволяют многое менять и достаточно быстро.-
именно так и работали, когда появились средства разработки ПО типа PowerBuilder, Delphi, Clarion. В большом проекте, даже если в нём используется Scrum, есть команда, которая разрабатывает платформу с опережением по времени - начинает работу раньше, скорость разработки у неё выше, и она может задействовать Waterfall. А уже под неё будут подстраиваться остальные.
Но ведь длительность этапа определяет Руководитель Проекта исходя из соотношения показателей - качество (степень готовности) продукта, срок, стоимость. Если я Вас правильно понял, то когда классический Waterfall сделать очень коротким, на каждой итерации Продукт приближать к финальному состоянию, то это будет Scrum? т.е. Scrum это не альтернатива Waterfall, а его разновидность?
Александр. Заранее извиняюсь, что не могу очень оперативно отвечать
На счет панацеи - соглашусь. У Scrum есть четкое предназначение - это процессный фреймворк (именно фреймворк) для разработки и поддержки комплексных продуктов. Под комплексными продуктами понимаю именно с точки зрения теории запутанности (Cynefin Framework) продукты которые еще никто никогда не делал, у заказчика нет конечного видения продукта, есть только гипотеза и непонятно как на продукт отреагирует потребитель.
В данном случае не важно, есть у вас платформа или нет, ваша команда высоко квалифицирована или нет (точнее это важно но не в первую очередь), ведь нет видения того, что должно получиться в результате и тут мы как раз и начинаем работать "на ощупь", т.е. выделяем из продукта MVP (Minimum Viable Product) и даже с помощью таких инструментов как Storymapping пытаемся сделать его еще меньше. Затем мы стараемся его как можно быстрее сделать и показать потребителю (хорошо бы в течении одного - двух спринтов) и начинаем собирать обратную связь и корректировать наш продукт.
Судя по комментариям к моей статье и статье Асхата - тут очень не любят заказчиков, которые не могут сформулировать что они хотят, считают их ненормальными и предпочитают с ними не работать. А ведь это нормальная ситуация, когда речь идет об инновациях а не типовых проектах.
А на счет опытных Архитекторов, можно сколь угодно выставлять требований и изначально планировать высокие нагрузки, закладывать zero-copy механизмы в обработку данных или планировать шардинг БД, это все никому не нужные вещи, если продукт получается не тот. Весь смысл вначале нащупать продукт, а уже потом догнать все до вышеперечисленных вами требований, порой даже выбрасывая то, что было сделано до этого (принцип Fail Fast).
Про про шардинг и zero-copy я не зря вставил замечание. У меня был опыт, когда реализация на старте проекта zero-copy архитектуры в конец убила продукт (он тупо не был доведен до релиза) ну и тема с шардингом - есть продукт, в архитектуру которого этот шардинг заложен, это мешает быстро продукт разрабатывать, но потенциально продукт способен выдерживать большие нагрузки. Но беда в том, что продукт до этих нагрузок не дорос, т.к. функционала в нем достаточного нет ибо он разрабатывается медленно из-за шардинга %)
Вы приводите примеры задач, достаточно популярные, и в этих примерах могут работать 1-2 программиста. И выбирали правильную стратегию - вначале платформу разрабатывали, чтобы выяснить возможные ограничения и что-то своё вложить.
Если бы результаты были впечатляющие, то могли бы собрать дополнительные инвестиции. А если бы разрабатывали функционал , потребовалось человек 5-7. - Затраты заказчика минимизировали, когда начали таким образом.
Для комплексного продукта "просто" эта платформа слабовата, скорее более развитые могут подойти, которые обеспечат работу сразу нескольких команд. Но чтобы их развести по задачам и они не мешали друг другу, платформу развивают с опережением.