Ссылка на видео отсутствует или повреждена.

Вход Или регистрация

Войти с помощью::

Регистрация или вход

Обратите внимание, все поля являются обязательными для заполнения.
Войти с помощью::

Восстановление пароля или регистрация

Все, что вы хотели знать о Scrum, но боялись спросить

16 сентября 2013 г., 11:18 51,253 1

Scrum – фреймворк, позволяющий решать совершенно разные задачи: от разработки сложных IT-продуктов до грамотного выстраивания домашних дел. Zillion собрал много полезной информации и пообщался с известным экспертом Владимиром Железняком, чтобы Scrum стал полезен и вам.

Для начала – о том, что такое Scrum: как происходит его применение в работе над проектами, что означают основные термины и как распределяются роли. Чтобы получить объемное представление о Scrum, поговорим с известным экспертом Владимиром Железняком о практике применения. И обратимся к эмпирическим наблюдениям различных команд.

Что такое Scrum?

В переводе с английского «scrum» означает «схватка». Это методология управления проектами, относящаяся к Agile-методам, то есть гибким подходам к разработке программного обеспечения. О Scrum, как правило, говорят именно в IT-контексте, хотя применяться он может много где. Это фреймворк, то есть каркас, структура, и оплетать этот эффективный каркас индивидуальными особенностями проекта можно в разных областях, если по самой своей сути проект и Scrum «совместимы».

«Прототип» современного Scrum был описан японцами Икудзиро Нонака и Хиротака Такэучи (заслуженные профессоры Hitotsubashi University) в 1986 году в статье «Гарвардского делового обзора» под названием «Новая игра в производстве продукта» («The New Product Development Game»). Как уже видно из названия, подход изначально позиционировался как игровой, образно его связывали со спортивным приемом «скрам», то есть «схваткой» вокруг мяча в регби. Отсюда и название «подход регби», которое со временем перешло в других языках в «подход скрам», или просто «скрам».

В начале 1990-х американские разработчики Кен Швабер и Джефф Сазерленд сформулировали принципы Scrum. Таким образом, создателями методологии считаются именно они. В 2001 году Кен Швабер в соавторстве с Майком Бидлом детально описал скрам в книге «Гибкая разработка программного обеспечения по Scrum» («Agile Software Development with Scrum»). Среди других известных книг: «Scrum: гибкая разработка ПО» («Succeeding with Agile: Software Development Using Scrum») Майка Кона и «Scrum и XP: заметки с передовой» («Scrum and XP from the Trenches») Хенрика Книберга.

В Scrum много специальных терминов, обозначающих ключевые константы и применяемые практики. Чтобы стало понятно, как это работает, быстро пройдем по ключевым словарным терминам.

kenАмериканские разработчики Кен Швабер и Джефф Сазерленд, авторы принципов Scrum

Терминология

Скрам (Scrum) – это набор принципов, на которых строится процесс разработки, позволяющий в жестко фиксированные и небольшие по времени итерации (спринты) предоставлять конечному пользователю работающий продукт (например, ПО) с новыми возможностями, для которых определен наибольший приоритет.

«Куры» и «свиньи» – это деление всех участников скрам-процесса на две группы. Названия для групп пришли из анекдота о курице и свинье, которые решили открыть ресторан, но свинья оказалась против названия «Яичница с беконом», поскольку свинье пришлось бы в этом случае полностью посвятить себя проекту, а курице – только частично. «Куры» – это специалисты, вовлеченные в проект частично: пользователи (Users); управляющие персоналом (Managers); эксперты-консультанты (Consulting Experts); клиенты и продавцы (Stakeholders), инициирующие проект для получения выгоды. «Свиньи» – это те, кто непосредственно вовлечен в проект и скрам-процесс: скрам-мастер, владелец продукта и скрам-команда. Скрам-мастер (Scrum Master) корректно ведет скрам-процесс: проводит совещания, следит за соблюдением принципов Scrum, разрешает противоречия, защищает команду от отвлекающих факторов и решает проблемы, которые мешают ей двигаться к цели. Владелец продукта (Product Owner) – представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Скрам-команда (Scrum Team) – кросс-функциональная команда проекта, обычно состоящая из из 7-9 специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и др.

Резерв проекта (Product Backlog) – это список требований к функциональности продукта (ПО), упорядоченный по степени важности и редактируемый всеми участниками скрам-процесса.

Спринт (Sprint) – это итерация в скрам, в ходе которой создается функциональный рост программного обеспечения. Возможности софта, которые необходимо реализовать в очередном спринте, определяются в начале спринта на этапе планирования и не могут изменяться на всем его протяжении. Длительность спринта строго фиксирована (1-6 недель), что придает процессу разработки предсказуемость и гибкость. Считается, что чем короче спринт, тем более гибким является процесс разработки: релизы происходят чаще, минимизируется работа в неправильном направлении, к разработчикам быстрее поступают отзывы от потребителей, что ускоряет улучшение продукта. Преимущества длительных спринтов – в уменьшении затрат на демонстрации и совещания и увеличении для команды времени решения проблем. Длительность каждого спринта команда подбирает индивидуально, исходя из задач, требований и состава. Предварительная оценка выражается в очках истории и позволяет определить объем работы в спринте. Ключевая особенность спринта: никто, кроме скрам-команды, не имеет права менять список требований к работе, запланированной для данного спринта. Остановка спринта (Abnormal Termination) командой или владельцем происходит в исключительных случаях по значимым причинам при невозможности продолжать спринт и необходимости перейти к следующему. Резерв спринта (Sprint Backlog) содержит функциональность, выбранную владельцем проекта из резерва проекта для реализации в данном спринте. Все функции разбиты по задачам. Каждый день команда разработчиков оценивает объем работы, оставшейся для завершения спринта. История спринта (Sprint Story) – это требуемая функциональность, добавленная в резерв. Зачастую формулируется понятным для всех образом: «Будучи пользователем (тип пользователя), я хочу сделать (действие), чтобы получить (результат)». Планирование спринта (Sprint Planning Meeting) происходит в начале нового спринта: команда выбирает объем работ и обсуждает реализацию, при этом задачи оценивают в человеко-часах (не более 12 часов или одного дня) и разбивают на подзадачи.

Диаграмма сгорания задач (Burndown Chart) – это общедоступный график (для спринта и выпуска продукта), показывающий, сколько задач выполнено и сколько осталось.

Скорость команды (Velocity) – количество очков, набранных командой за предыдущий спринт. Помогает команде понять, сколько она может сделать за спринт.

Покер планирования (Planning Poker, или Scrum Poker) – это техника оценки сложности предстоящей работы или относительного объема решаемых задач. При этом используется особая колода неигральных карт.

Ретроспектива (Retrospective Meeting) – совещание по завершении спринта для анализа того, что было сделано хорошо и что улучшить в следующем спринте.

Скрам над скрам’ом (Scrum of Scrums) – проводится после ежедневного скрам-совещания. Позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. К трем классическим вопросам скрам-совещания добавляется один: «Что каждая команда сделала с момента предыдущего ежедневного совещания? Что каждая команда сделает к следующему ежедневному совещанию? Есть ли проблемы, мешающие или замедляющие работу каждой команды? Нужно ли другой команде сделать что-то из задач вашей команды?».

Средства управления проектами с поддержкой Scrum: Banana Scrum, CollabNet ScrumWorks Pro, Hansoft, en:IBM Rational Team Concert, Ice Scrum, Kunagi, JetBrains YouTrack, JIRA с использованием плагина Green Hopper, Mingle, ThoughtWorks Studios, OneDesk, PangoScrum, Pivotal Tracker, Rally Software, Redmine and ChiliProject с использованием плагинов, ScrumDo, ScrumPad Pro, Scrumwise, Scrumy, Sprintometer, TargetProcess, Tinypm, VersionOne, Visual Studio 2012, Microsoft Team Foundation Server, Yodiz.

Правила Scrum можно скачать здесь на разных языках The Official Scrum Rulebook и здесь – на русском.

Что еще нужно знать о Scrum?

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

Scrum: возможности & особенности

  • Идеальный «климат» для Scrum: гибкие сроки и бюджет; творческий проект; клиент, понимающий суть Scrum и одобряющий этот подход; технически компетентный Product Owner с готовностью и возможностью выполнять свои функции в проекте; сработавшаяся профессиональная ответственная команда с энтузиазмом и низким уровнем эго в работе.
  • Скрам хорош, когда есть понимание, что продукт может разрабатываться поэтапно; нет ясного понимания, что необходимо, но клиент хочет получить в итоге то, что ему нужно, а не что получилось; необходим быстрый запуск проекта (вначале – с ограниченными функциями); есть понимание, что какие-то составляющие будущего продукта и приоритеты могут поменяться в процессе разработки. (Появляются новые идеи, обнаруживается возможность сделать лучше, у заказчика возникли другие потребности. Соответственно, и для заказчика, и для исполнителя все это лучше понять задолго до сдачи/приема готового продукта, чтобы сэкономить время, деньги и нервы.)
  • Скрам хорош для нетривиальных, долгих, сложных, развивающихся в процессе проектах.
  • Скрам предполагает работу по фреймворку, а не как получится. Это непрерывный циклический энергичный процесс, препятствующий застою в команде. Он позволяет уменьшить неопределенность требований до минимума, дает возможность детального прототипирования, повышает внутреннюю прозрачность процессов.
  • Короткие итерации позволяют сосредоточить внимание заказчика и команды на конкретной задаче и решить ее с минимальной степенью недопонимания.
  • Выбор традиционного подхода или Agile зависит от того, какой в данном случае заказчик, какой проект, какой командой располагает компания-исполнитель, от компетентности менеджера, от устоявшихся процессов в компании и даже от таких факторов влияния как стремление продажников получить гарантированный процент при продаже традиционных решений.
  • Некоторые команды подчеркивают, что Scrum наиболее эффективен на начальных стадиях больших проектов, когда необходимо фундаментальное выстраивание работы. В дальнейшем могут быть использованы только часть практик Scrum и только часть первоначальной команды – гибкие подходы это допускают и предполагают.
  • Нельзя делать из Scrum карго-культ и слепо следовать каждому пункту из формальных соображений.

Переход на Scrum & Scrum-команда

  • Перед решением о переходе на Scrum необходим тщательный анализа процессов в компании для понимания целей.
  • Скрам может работать в одной команде и, напротив, разрушать другую. Для работы по Аgile-подходам, и в том числе по скрам, нужна команда с высоким уровнем ответственности, сработанности и профессионализма. Хорошо, когда Scrum-команда максимально кросс-функциональна.
  • Команда выбирает тот подход работы, который удобен ей и эффективен. Но она может быть переведена на скрам и по желанию руководителя. Внедрение Scrum может занять несколько месяцев. Реакция на переход зависит от конкретной команды: скрам может быть встречен с энтузиазмом или с негативом разработчиков. Необходимы разъяснения, обучение, тренинги.

Лучше, если необходимость перехода на скрам назрела в самой команде, а не спущена «сверху» – тогда выше уровень приятия и мотивации. Команда может неявно «сопротивляться» переходу, если процессы работы и так были отлажены и переход навязывается ей как дань моде или желание менеджмента внедрить прогрессивные подходы.

 

  • Руководителю/менеджеру нужно быть готовым к временному ухудшению качества исполнения проектов в период, пока команда переходит на скрам. После адаптации эффективность обычно возрастает.
  • Скрам позволяет каждому члену команды понять сроки, планы, последовательность, суть продукта и направление его развития; быть в курсе того, чем занимаются коллеги и выбирать себе задачи из резерва спринта; обновлять свой vision.
  • Для Scrum не слишком подходят специалисты, которым важна индивидуальная оценка работы, поскольку оцениваются командные результаты.
  • Есть мнения, что по Scrum сложно/невозможно работать в компаниях, где одновременно идет работа над несколькими проектами и не получится создавать стабильные группы для каждого отдельного проекта.
  • Скрам помогает определить слабое звено в команде или слабые компетенции каждого разработчика – и совершенствовать подготовку прицельно.
  • Команда разработчиков может состоять из 7-9 человек и работать над долгим сложным проектом (полгода, год). Но на практике элементы Scrum могут быть использованы и малыми командами в коротких проектах. Ежедневные обсуждения по трем ключевым вопросам могут выявить, что часть команды в действительности не требуется в маленьком проекте. В небольших проектах скрам полезен тем, что позволяет улучшить внутренние процессы в команде. Опыт применения Scrum очень разнообразный, это предполагается самой сутью гибких подходов.
  • С точки зрения личностных особенностей, для Scrum больше подходят «командные игроки»: специалистам необходимо все время находиться в контакте для поиска оптимальных решений и идей для улучшения продукта. Но можно попробовать и развивать специалистов для командной игры, учитывать их особенности, сильные и слабые стороны.

Кен Швабер о скрам

Заказчики & отношения с заказчиками

  • В каких проектах и с какими заказчиками подходит Scrum – вопрос открытый и дискуссионный. Нередко говорят, что Scrum не работает при заниженном бюджете проекта, нереалистично оцененных сроках, при низкой квалификации команды и менеджера проекта.
  • Работает ли Scrum на государственных заказах – разные отзывы: одни команды говорят, что не работает, а другие – что такие особенности госзаказчика, как постоянные изменения требований, обусловливают необходимость Scrum, поскольку множество итераций и демонстраций позволяют снизить риски.
  • Scrum хорош для разработки продукта (ПО) в креативных проектах с высокой степенью неопределенности, поэтому подходит для стартапов и нестандартных проектов.
  • Есть мнение, что скрам больше подходит компаниям для работы с собственными продуктами, чем с продуктами заказчиков.
  • Скрам хорош для заказчика, который хочет «классно», но не знает, чего и как именно.
  • После каждого спринта происходит прирост функциональности, то есть заказчику можно показать готовую протестированную часть продукта, созданную за этот и предыдущие спринты. Таким образом, возможен ранний запуск продукта (сайта, например) с базовой функциональностью. «Оптимально частые» демонстрации тестовых версий проекта с приростом функций дают возможность заказчику и команде свериться и подтвердить правильность исполнения, оговорить то, что нужно учесть в следующих спринтах.

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

 

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


Product Owner, менеджер проекта, Scrum-мастер

  • Scrum-мастер не только следит за соблюдением правил Scrum, но и поддерживает психологический комфорт и нужный уровень продуктивности в команде. Его роль чрезвычайно важна: он не только обеспечивает команде все условия для работы и решает проблемы, но и направляет ее в поиске оптимальных решений. Качество работы и психологический климат в команде во многом зависят от личных качеств скрам-мастера.
  • Product Owner, или владелец продукта, в проекте – это роль, он не обязательно является непосредственным владельцем продукта: он может представлять интересы заказчика и пользователя. Иногда на практике его функции берет на себя менеджер проекта (не стоит путать со скрам-мастером). Product Owner актуализирует список задач и расставляет приоритеты. Роль Product Owner может выполнять аналитик заказчика (команда аналитиков).
  • Одним клиентам важно знать, что их продукты будут разрабатываться методично, по фреймворку скрам. Другим это не важно. А третьим это знать не обязательно. Главное – чтобы заказчик вовремя смотрел демонстрации и высказывал соображения, которые нужно учесть в дальнейшей разработке, либо подтверждал, что работа идет в верном направлении.
  • Клиент при разработке продукта по Scrum получает важную роль в проекте и постоянно находится в контакте с командой, например, смотрит демо после каждой итерации. Такой режим работы не всем удобен и не со всеми заказчиками будет разумным. Кроме того, при поэтапной оплате клиенту может быть сложно оценить бюджет и сроки единовременно. Однако существенным плюсом для клиента будет возможность быстро запустить продукт с ключевой функциональностью, избежать рисков и затрат на переделку целого продукта.

Нужно иметь в виду, что некоторые клиенты боятся работать по Scrum: боятся роли Product Owner, то есть необходимости принимать решения при планировании работ и после демо; боятся неконкретных бюджетов и сроков; не готовы к возможности сразу модифицировать продукт, быстро отреагировать на отклик пользователей.

 

  • Заказчику либо его представителю (Product Owner) нужно будет принимать много решений при работе по Scrum, поэтому предполагаются ясность видения проекта, право принятия решений, а также высокий уровень компетентности, ответственности и общей адекватности.
  • Если роль Product Owner выполняет представитель агентства, нужно учитывать, что он фактически является посредником: не всегда имеет актуальную информацию о продукте и его изменениях, не может принимать ключевых решений по срокам и бюджету. То есть выполнение многих ключевых функций Product Owner для него затруднено или невозможно.
  • Есть мнение, что в компании-исполнителе должен быть свой сотрудник, выполняющий роль Product Owner и максимально контактирующий со стороной заказчика.
  • Нередко на практике, в зависимости от личных качеств и отлаженности процессов, происходит смещение/смешение функций Product Owner, менеджера проекта и Scrum-мастера. Канонически классические роли Scrum-мастера и Product Owner не должны сливаться или меняться местами. Однако на практике могут происходить интересные деформации, отход от типичного образа, причем как в лучшую, так и в худшую сторону, в зависимости от особенностей конкретного сотрудника.


Нюансы в работе по Scrum

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


Юридические и финансовые аспекты

  • С точки зрения работы с бюджетом есть разные подходы к реализации проектов по Scrum: фикспрайс, гибкий бюджет, поэтапная оплата, выстраивание графика релизов с выносом дополнительных функций в допсоглашения и отдельные договора и т. д. Хочется, но не стоит рассчитывать на гибкий бюджет – практики говорят, что пока таких заказчиков в России немного. При нефиксированном бюджете заказчику необходимо осознавать высокую вероятность перерасхода.
  • Экспертная оценка работы может быть дана менеджером проекта или техническим директором. Planning Poker – достаточно точный инструмент оценки, но оптимистичный.
  • Можно заключить договор на поэтапную разработку проекта. Возникающие пожелания в этом случае будут отражены в допсоглашениях.
  • Сложные функции продукта, которые добавляются позднее, также можно выносить в следующие релизы и оформлять отдельными договорами и допсоглашениями. В этом случае важно выстроить логику релизов.

 

Интервью с экспертом

1f448fd85a167bbc092dfe57db63d50b

Владимир Железняк: «Scrum эффективен во многих областях – от разработки IT-продуктов до ремонта квартиры»

azheleznyak

Владимир Железняк

Практикующий тренер и практик Scrum. Менеджер, программист, тренер и коуч с 14-летним опытом в коммерческой разработке. Соавтор блога «Психология в IT». Соавтор видео-курса о психологических основах Scrum «Эмоциональный Scrum» и программы «Клуб Корпоративного Общения» для Stratoplan.Ru. Докладчик 20+ конференций за последние несколько лет.

54f16dd848707d748825b58ca8cf9454

Что представляют собой Agile-подходы и в частности Scrum?

– Если кратко, то быструю и дешевую адаптацию к изменяющимся требованиям. Слово «дешевая» здесь подразумевает не только экономию денег заказчика, но и экономию нервов исполнителей. Помните анекдот? «Молодцы, классную яму выкопали! А теперь подвиньте ее на пять метров левее». Ситуации, когда твоя работа идет на свалку, – страшный демотиватор.

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

– Я скажу так: если у вас все хорошо, то и скрам не нужен. Если же что-то идет наперекосяк, то практики скрам могут пригодиться. Правая рука не знает, что делает левая? Стендапы в помощь. Заказчик замучил проверками и считает бездельниками? Будет полезен еженедельный показ достижений, то есть демо. Часто приходится переделывать результаты работы, которая заняла месяц? Опять же, делаем еженедельные демо. Срываем сроки, потому что все время происходят какие-то неожиданности? Помогут Planning Poker и Burndown’ы. Planning Poker при всей своей наигранности позволяет вскрыть проблемы на этапе планирования, а не тогда, когда уже поздно. Срываем сроки, потому что их спускают сверху? А вот это уже со скрам совместимо только тогда, когда команда может определять объем работ для этих сроков.

Вот, кстати: для каких компаний, заказчиков, команд и проектов Scrum подходит, а для каких – нет?

– Скрам сам по себе не нужен, разве что продажникам, чтобы продать услуги клиенту, который знает, что «Scrum – это круто и модно». И то: продажа – это уже цель. Scrum решает задачи, причем не все – бывает, и несовместимость. Например, очень сложно совместить авторитарный стиль управления с гибкостью. Это показывают и практика, и обширная теоретическая база психологии: можно почитать, в частности, у Эрика Берна о модели «Родитель-Взрослый-Дитя» и т. д. Если в компании много (!) значимых людей-тиранов, всезнаек, капризных звезд, нытиков и ворчунов, раздолбаев и болтунов – тут также будут сложности.

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


Scrum применяется только в IT-сфере или в других областях тоже эффективен?

– Скрам эффективен очень много где. Я читал даже про успешные примеры использования практик Scrum в ремонте. Имеется в виду применение таких практик как Backlog и Burndown, а также в текущих семейных делах, использование скрам-доски, к примеру. Я бы сказал так: скрам эффективен везде, где есть измеримое окончание задачи и важна инициативность участников. Ну а если на проекте все предсказуемо, нет частых изменений, то традиционное планирование может быть лучше. И фигурально, и буквально: для ремонта в отдельно взятой квартире скрам вполне подходит, а для уборки картошки – нет. Разве что в том случае, если в процессе возникают непредсказуемые сложности: от визита санэпидемстанции, засухи и наводнения до изменения гравитационной постоянной.

Часто Scrum используется не целиком, а отдельными практиками: бэклогами (Backlog), берндаунами (Burndown), стэндапами (Standup). Backlog – это список задач проекта: ближайшие описываются подробно, а остальные – нет. Burndown – это график, в котором ось X – время, а ось Y показывает, сколько работы осталось. Там же есть идеальный график, то есть прямая линия от старта до финиша. Стендапы – это короткие пятиминутки, которые проводятся стоя для всех каждый день в одно и то же время. Каждый участник в трех предложениях рассказывает о том, что делал, что будет делать и какие есть проблемы.

Какие ошибки и неудачные ситуации типичны в практике Scrum?

– Основная ошибка, которую я вижу: люди не понимают, зачем им скрам нужен. Здесь хорошо работает техника «договор на крови». Пара примеров.

«Коллеги, у нас сложилась такая ситуация: Вася и Петя начали работать над одним и тем же модулем одновременно. В результате поломали друг другу работу и будут сидеть совмещать изменения. Каждый не знал, что второй сейчас тоже работает над этим модулем. Мы потеряли один день, а релиз все ближе. Как мы можем предотвратить такие провалы в будущем?» Слушаем ответы, пробуем по предложенному. Если предложений нет или они себя не оправдали, предлагаем внедрить пятиминутки с тремя вопросами: «Что закончил за день? Что планирую закончить на завтра? Есть ли проблемы?»

Или такой пример: «Мы классно сделали модуль отчетов. Спроектировали, реализовали, прикрутили дизайн, протестировали, исправили ошибки, перепроверили. Показали заказчику – он сказал, что ему совсем другие отчеты нужны. Что делать, чтобы в будущем это не повторялось? Пусть заказчик точнее формулирует требования? Хорошая мысль, попробуем, только этот заказчик  – "творческий" человек, четкости от него ждать не стоит. Еще идеи? Как минимизировать потери? А давайте показывать сырой вариант, без дизайна и багфикса? Скажем, раз в неделю?»

Это все к тому, что практики Scrum внедряем по мере надобности и для решения задач, а не для галочки.

То есть их можно внедрять по отдельности: брать то, что подходит к задаче и команде? А можно так: «Ребята: с понедельника всю работу переводим на скрам»?

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

333   Классическая схема Scrum

Необходимо ли юридически регламентировать разработку продукта по Scrum в договоре с заказчиком?

– Если вы знаете, зачем вам это, то да. Скрам – это не цель, а инструмент для ее достижения. В моей практике заказчики больше ориентируются на результат, чем на формальные пункты. Хотя в работе с корпорациями всякое может быть. У меня нет примеров, когда скрам был оговорен в контракте. На мой взгляд, если заказчик требует скрам от команды, которая по Scrum не работала, это до добра не доведет. Если же исполнитель требует от заказчика что-то, связанное со Scrum, и вносит этот пункт в договор, то от заказчика сложно ожидать понимания практик Scrum. Это не его область, и здесь нужно подробно расписывать, что именно от него требуется: к примеру, регулярно смотреть демо и давать обратную связь.

Возникает ощущение, что в Scrum невероятное множество теоретических и эмпирических нюансов: можно ли научиться Scrum самостоятельно и начать практиковать в своей компании? Или так: тренинг, а затем самостоятельная практика?

– Лучше всего, конечно, поработать по Scrum в компании, в которой это «работает». Например, там, где проект набирает достаточно много баллов по Nokia Scrum Test. Если же внедрять скрам с нуля и без возможности попробовать, все пути подойдут: и чтение книг, начиная с коротенькой «Scrum и XP: заметки с передовой» Хенрика Книберга, и наш обучающий курс «Эмоциональный Scrum», и тренинги – по Scrum, по коммуникациям на проекте и по конфликтологии. Тренинги для команды многое могут дать. Часто какие-то практики разработки не приживаются не по техническим причинам, а из-за человеческого фактора. Это касается и Scrum, и Test Driven Development и т. д. Пример: в команде формально практикуют скрам, но задачи раздает один человек, он же выдает оценку по времени и контролирует результат. Его желание все контролировать сводит к нулю энтузиазм и скорость работы остальных. Или другой пример: кто-то попробовал внедрить практику стендапов, но не смог уговорить всех проводить их стоя и слушать собеседников. В результате один человек бубнит десятиминутную лекцию о том, как ему сложно работать, а остальные тихо храпят в креслах в ожидании своей очереди. (Zillion: TDD – разработка через тестирование. Continuous Integration – практика разработки «Непрерывная интеграция», суть которой в выполнении частых автоматизированных сборок проекта для скорейшего выявления и решения интеграционных проблем.)

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

– Да, скрам-опыт очень разный. На то и Agile, чтобы быть гибким и подстраиваться к разным требованиям, людям и задачам. Пожалуй, сразу приходит в голову типичная ситуация: топ-менеджер или заказчик прочитал где-то, что скрам – это хорошо, и поручил подчиненным внедрить. Они полгода помучались и сказали: «Фигня ваш скрам, не работает».

А почему так бывает? Правда ли, что есть противники Scrum и с чем это связано?

– Обычно это происходит, когда не понимают, что хотят решить. Если человек в начале внедрения говорил: «Мы хотим повысить производительность» и прочий marketing bullshit, то во время внедрения у него большой шанс заметить, что до внедрения производительность не мерялась, а сам процесс измерения требует времени. Из разочаровавшихся людей, которые зашли без четко сформулированных задач и проблематики, и получаются потом противники Scrum: «До этой работы у меня было ничего, а теперь – ничего и дергающийся глаз». Цель нужна!

Что такое «Эмоциональный Scrum»?

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

  • Сама ретроспектива воспринимается как «разбор полетов» и «публичная порка провинившихся».
  • На ретроспективе начинаются обвинения с переходом на личности «Ты поступил плохо», «Ты всех подвел» и т. д.
  • Обвинения выходят на уровень идентичности: «Как человек с твоим опытом мог допустить такую детскую ошибку? За что тебя поставили лидом?».
  • Неконкретные условия исполнения: «Ты не умеешь писать Unit-Test’ы, поэтому в следующем спринте должен стараться в два раза больше».

(Zillion: ретроспектива в Scrum – это обсуждение в конце каждого спринта. Участники высказываются о том, что было хорошо и что можно улучшить в следующем спринте.)

А в целом насколько работа по Scrum стрессовая? Если говорить о работе в команде и о ситуациях конфликтов и непонимания между заказчиком и командой?

– По сравнению с традиционными методами разработки, в Scrum-проектах стрессы чаще переносятся на начало работы. То есть при обычной схеме мы получаем огромный стресс в конце, при сдаче проекта, когда вскрываются все неудачные решения. А в Scrum это будет серия более простых стрессов по ходу работы, пока «болезнь» еще не «запущена». Для этого есть инструментарий, о нем можно долго говорить. Для примера: во многих практиках Scrum прячется психологическая установка Prime Directive: «Вне зависимости от того, что мы определили или нашли, мы понимаем и искренне верим, что каждый делал лучшее из того, что мог, и берем во внимание знания, умения, навыки, ресурсы и обстоятельства на тот момент».

«Если человек в начале внедрения говорил: "Мы хотим повысить производительность" и прочий marketing bullshit, то во время внедрения у него большой шанс заметить, что до внедрения производительность не мерялась, а сам процесс измерения требует времени. "До этой работы у меня было ничего, а теперь – ничего и дергающийся глаз". Цель нужна!»


Если сравнивать с традиционной разработкой по критериям времени и затрат, дает ли скрам какой-то выигрыш?

– С численной оценкой сложно: очень много «входных» параметров, и о серьезных статистических исследованиях я не слышал. Тут бы на команду и на заказчика посмотреть. Рискуя попасть пальцем в небо, попробую обозначить коридор значений: вряд ли удастся ускориться больше, чем вдвое, и вряд ли переход даст экономию времени меньше, чем 10%.

Говоря о финансовых преимуществах работы по Scrum, давайте попробуем вывести формулу для расчета «цены опоздания». Не помню проектов, которые опережали бы график. Вот у нас есть проект с поэтапной оплатой, мы знаем, что потратим на первый этап N денег на зарплату, аренду, налоги, амортизацию железа и т. д. От заказчика же получим M денег. Наша ожидаемая прибыль равна M-N. И пусть первый этап будет K месяцев.

В классической схеме мы понимаем, успеем или нет, примерно к середине проекта. Обычно если не успеваем, то тут же начинаются идеи: «А давайте таки успеем и будем работать по выходным», «Дальше задачи будут проще» и т. д. В результате после 0,7*K мы понимаем, что не успеем никак и наша прибыль (M-N) целиком будет съедена опозданием. И выбор состоит в том, чтобы продолжить работу себе в убыток или списать 0,7*N денег. 0,7 вот откуда: через 50% времени начало появляться ощущение, что можем не успеть, а еще через 20% это стало очевидным настолько, что уже нельзя игнорировать.

Пусть этап – это четыре месяца, и четверым сотрудникам мы платим по $1500. Еще столько же уходит на налоги, аренду и т. д. Тогда N=4*(4+1)*1500. Таким образом, общая сумма зарплат составит $30 000. C заказчика мы получим (M) $50 000. Тогда ближе к концу третьего месяца, когда уже нельзя будет закрывать глаза на отставание и мы увидим, что работы осталось еще как минимум на два месяца, у нас будет выбор: списать или нет $30 000*0,7, то есть $21 000.

Если в схеме применены скрам-практики Burndown и Velocity, а также недельные итерации, то мы получим заметный и сколько-то точный прогноз через шесть итераций. То есть в начале-середине второго месяца мы уже будем знать, успеем или не успеем: N=$30 000*1,2/4=$9000. (Zillion: «Velocity» означает «скорость, быстрота». Это практика вычисления скорости команды путем подсчета завершенных частей работы за определенный отрезок времени.)

Итого в рамках этого примера, работая по классической схеме, мы рискуем $21 000, а с подсчетом Velocity, то есть скорости команды, при работе по Scrum – $9000. Конечно, в этом примере много чего упущено: репутационные издержки, пени и т. д. Но все же он достаточно нагляден. Такую формулу можно составить для своего проекта.

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


Встретила такое мнение, что Scrum – методология, созданная для защиты разработчиков от изменений условий проекта в процессе. И потому Product Owner находится в менее выгодном положении. Так ли это?

– Это один из хороших «лозунгов», с помощью которых можно продать Scrum исполнителям. Да, Product Owner осознанно отказывается от мелких вмешательств в середине спринта. Но крупные он все равно может сделать: в явной форме – прервав спринт. Про выгодность положения можно поспорить, так как владелец продукта что-то теряет, а что-то и приобретает. Например, он экономит то время, которое обычно уходит на переключение с задачи на задачу. Человек вообще с трудом входит в поток – в то самое состояние, которое наиболее эффективно. А прерывание на короткую двухчасовую задачу, как правило, приводит к тому, что после этого сотрудник тратит часа три на разгон.

Как вам кажется, необходимо ли обучать работе в фреймворке Scrum в IT-вузах, на этапе изначального IT-образования?

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

Получается, проблема глубже: можно было бы учить решать проблемы по Scrum, но из-за отсутствия прикладного обучения студенты, по сути, не понимают даже, что такое практические проблемы?

– Да, именно так. Есть еще такой термин «зона ближнего развития»: эффективное обучение только в ней и идет. Например, мне будет бесполезен продвинутый курс китайского языка, я и начальным-то не владею.

А где и как обучаются на скрам-мастера?

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

А как понять, что задачу поможет решить именно скрам?

– Парой слов здесь не обойдешься. Просмотрите хотя бы пару страниц описания скрамовских подходов. Или задайте вопрос подходящим людям. Можно мне написать на vz@it-boost.com

Есть ли какие-то тенденции внутри Scrum?

– Из явного – видна тенденция к коротким итерациям. Раньше говорили про 4-6 недель, а сейчас спорят: одна или две недели. Остальные тенденции сложно уловить, слишком большая разница между проектами.

«Скрам нужен для решения проблем, а в вузе еще нет понимания того, что проблема есть. Командная работа на курсовых и лабораторках обычно выглядит так: один пишет программу, второй – отчет, а остальные им пиво носят. Здесь много чего можно еще сказать. И про самоорганизацию команд – откуда она в вузе? И про ориентацию на конечный результат: "сдать" и "чтобы пользовались реальные люди" – это разные задачи».

 

 

 

Отметить прочтение на Facebook

Автор
Анастасия Подберезкина
Автор
Работает в Zillion

Шеф-редактор Zillion
Рекомендуем
Безжалостный менеджмент в кризис
Project Management. 7 инструментов для менеджера проектов
Как разработать антикризисную стратегию
Как сюда попасть

Zillion приглашает к сотрудничеству

Zillion приглашает к сотрудничеству обладателей уникальных знаний готовых делиться ими и совместно зарабатывать. Для вас мы подготовили уникальную инфраструктуру, которая позволит комфортно работать онлайн преподавателем, создавать собственные курсы и проводить вебинары. Чтобы узнать подробности, напишите нам: ideas@zillion.net

Комментарии 1

На моей практике случился проект, управление изменения в котором, благодаря пониманию всех участников этого проекта, эволюционировал в scrum сам по себе. Иного пути мы и не видели. Хотя даже и не знали, что это называется scrum - вот что забавно. Сама техника очень интересная и очень производительная, но двигать тяжёлые, мощные изменения с её помощью сложнее и тут рождаются гибриды. К сожалению мало было написано о Planning Poker. Точность оценки времени задач качественно повышает весь спринт на мой взгляд, т.к. приближает спринт к идеальному варианту с правильной оценкой затрат времени и других ресурсов.
21 июля 2014 г. в 22:39
1
Ответить
Vitaly Zvyagintsev
Пользователь

Отправить комментарий на Facebook


Рекомендуем к просмотру
Тренды
Подписывайтесь на новый блог Trendspot by Zillion
13 августа 2017 г. 6,740
Менеджмент
Владимир Завертайлов: «Мой телефонный номер есть в подписи у всех менеджеров. Клиенты этим пользуются редко, но возможность такая есть»
12 июня 2017 г.
7,860
Управление проектами
Zillion.Quick: «Управление продуктом в Scrum», Роман Пихлер
8 июня 2017 г.
7,918
Управление проектами
Мемесы про пиэмов. Chapter 1: топ-5 Романа Вейнберга
18 мая 2017 г. 7,477
Управление проектами
Правда жизы. Владимир Завертайлов («Сибирикс») про управление проектами (18+)
16 мая 2017 г.
2,704
Управление проектами
Стейкхолдер-менеджмент. Как идентифицировать, анализировать и вовлекать стейкхолдеров в проект
15 мая 2017 г. 3,290
Управление проектами
Zillion.Quick: «Канбан» Дэвида Андерсона
6 мая 2017 г.
3,514
Тренды
Новое на Trendspot. Флэш-фикшн: твиттература, чат-книги, дрибл, драбл, 6 и 9. Создатель Telegram-канала «Кароч.» Дмитрий Соловьев рассказывает о микролитературе и фикшн-форсайте
26 августа 2017 г. 5,846
Управление проектами
Zillion.Quick: «Мифический человеко-месяц» Фредерика Брукса
26 апреля 2017 г. 2,613
Управление проектами
Чем занимается Project Manager?
20 марта 2017 г.
9,906
Управление проектами
Zillion.Quick: «Корпорация гениев. Как управлять командой творческих людей», Эд Кэтмелл
9 марта 2017 г.
4,399
Управление проектами
Проектное мышление. Поиск инвестиций: зачем использовать CRM
23 февраля 2017 г. 4,185
Управление проектами
Надпрофессиональные навыки: управление проектами
22 февраля 2017 г.
3,419
Управление проектами
Управление проектами: как организовать путешествие
14 февраля 2017 г.
5,354
Развитие персонала
Zillion.Quick: синопсис + инфографика. «Лидер и племя. 5 уровней корпоративной культуры»
9 февраля 2017 г. 4,690
Образ жизни
Как пробежать свой первый марафон
19 января 2017 г.
7,106
Продуктивность
С 2017-м! Начните год продуктивно: 5 полезных курсов вместо 5 новогодних кило
1 января 2017 г.
4,205
Маркетинг
Zillion.Quick: «Фиолетовая корова. Сделайте свой бизнес выдающимся», Сет Годин
28 декабря 2016 г. 5,189
Управление проектами
Павел Капусткин: «Смотри, наиболее вредна для пиэма непродуктивная эмоция»
12 апреля 2017 г. 8,864