Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 10 153 веб-студии, 892 CMS, 216 980 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Scrum - зачем заказчику знать такие непонятные слова?

Допустим, вы заходите к себе домой, садитесь на старый диван, из которого торчат пружины, смотрите на старую, облупившуюся мебель и говорите себе: “так дальше продолжаться не может!”. Вы решительно хотите сменить всю свою старую, потертую мебель на новую, экологичную и функциональную, подогнанную специально под ваши нужды. Причем вариант ширпотреба из IKEA — не рассматривается, т.к. у вас есть свои, четко осознанные специфичные требования к домашней обстановке. Вы идете к ОЧЕНЬ крутому мастеру, искренне считая, что только профи способен воплотить в реальность ваши желания.

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

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

Ждете. Куда-то делась радость спонтанной покупки? Никто из мастерской вам не звонит, особо не беспокоит, не отчитывается, вопросов не задает... Ждете. А потом ждете еще две недели. И вы уже в бешенстве. От былой решимости осталось не так много – а стоило ли вообще затевать переделку? А потом еще ждете, еще чуть-чуть и еще три часа, на которые вы пораньше ушли с работы. И вот вам привозят новый комплект. Собирают, расставляют, и вам в голову бьет вполне отчетливая мысль.

НЕ ТО!

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

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

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

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

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

ОК, это плохо. Но как этого можно было избежать?

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

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

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

SCRUM помог бы вам в ситуации, когда...

— Куча денег и времени ушла на проработку ТЗ, но по ходу работы над проектом поменялась концепция или бизнес-процессы. Доводить проект до конца в том виде, как описано в ТЗ — нет смысла. Деньги на ТЗ выброшены напрасно. Разработчик отказывается вносить изменения по ходу работы, ссылаясь на ТЗ.

— Разработчик показывает проект в последний день перед запуском. Однако все сделано не так, как вы себе это представляли. Нужна значительная переделка. Разработчик по-своему трактует описанные в ТЗ требования и отказывается вносить изменения в проект на этом основании.

— Нужно запустить костяк интернет-проекта с минимально-возможным бюджетом и сроками. Дополнительные функции разрабатывать уже после запуска, когда проект начнёт отбивать начальные инвестиции.

Знакомо? Скорее всего при разработке была использована «водопадная» модель, или все вообще шло как-попало.

Scrum — это альтернатива, лишенная перечисленных выше недостатков. И вот почему:

Механика процесса в web-разработке

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

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

Итак, работа по Scrum строится следующим образом.

Backlog вместо технического задания

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

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

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

Спринт — этап разработки

Вся разработка проекта идет короткими этапами (спринтами). Функции, которые нужно реализовать на каждом спринте — зафиксированы (их нельзя менять по ходу спринта). Они разбиты на задачи, а задачи имеют оценки и приоритеты. В классическом Scrum предполагается, что продолжительность спринта фиксирована и, как правило, составляет от 2 до 4-х недель, в зависимости от опыта команды.

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

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

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

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

Ху из ху на проекте

При разработке по scrum на проекте есть парочка ключевых ролей.

Product Owner – владелец продукта. Отвечает за представление интересов заказчика и конечных пользователей на проекте. Не является членом команды разработчиков. В идеале это должен быть представитель заказчика. Однако, поскольку эта роль накладывает очень высокие требования к опыту и компетенции индивида в сфере разработки и развития интернет-проектов, а так же требует постоянного личного участия в проекте (что не всегда возможно для заказчика)  - в нашем случае эту роль выполняет менеджер проекта.

Ну и конечно, на проекте есть команда разработчиков :-) А в ней:

Scrum Master – член команды, следящий за соблюдением принципов Scrum и проводящий ежедневные планерки. Роль не предполагает каких-то дополнительных полномочий по проекту, кроме самого Scrum-а.

Работа по этапам и приоритетам

Основная задача Product Owner–а – поддерживать в актуальном состоянии список задач по проекту (backlog) и правильно (с точки зрения бизнес-целей проекта) расставлять приоритеты. При этом в backlog попадают, как правило, не мелкие задачи (ака “нарисовать кнопочку”), а более крупные бизнес-задачи (например «реализовать авторизацию через социальные сети»).

Не обязательно иметь весь список задач (достаточно чтобы он был известен на пару следующих этапов) В начале каждого этапа работ команда набирает себе из этого списка столько задач, сколько способна реально успеть за этап (скажем, за 2 недели). Разбивает на подзадачи и делает точные оценки сроков.

Ежедневный контроль

Daily meetings (или Stand-up Meeting) – очень важный ежедневный ритуал, который позволяет ощутить пульс проекта. На протяжении всего спринта команда собирается в одно и тоже время в специально отведенном месте. Каждый член команды поочередно должен ответить на три вопроса:

1. Что было сделано вчера?

2. Что будет сделано сегодня?

3. Какие есть проблемы?

Важно не превращать Daily-Meeting в обсуждение технических деталей проекта (это можно сделать позднее), либо в формальное выяснение статуса проекта. У нас Daily Meeting обычно занимает по 5-10 минут на команду.

Частые демонстрации проекта

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

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

На практике нам за несколько лет работы по scrum только пару раз удалось привлечь разработчиков и клиентов на совместную демонстрацию проекта (очень сложно состыковать всех по времени, да и отечественные заказчики это не очень любят). Хотя вообще, получение отзывов на свою работу от бескомпромиссного заказчика (“О, ребят, вы клёвую штуку сделали” или “Блин, ну чё за дрянь наворотили!”) может стать весомым стимулом к саморазвитию команды. (Опять же, наш русский менталитет заказчика склонен выискивать и преувеличивать недостатки проекта. Получать отзывы на свою работу от Европейцев или Американцев намного приятнее. Нужно понимать, не будет ли команда демотивирована после полученного отзыва).

От редакции



Представляете крупную компанию?

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

При его составлении были учтены открытие источники информации: рейтинг 2000 крупнейших мировых компаний Forbes, рейтинг ведущих компаний российской экономики «Эксперт-400», плюс списки 200 крупнейших публичных и 200 непубличных компаний России.

Плюсы и минусы Scrum

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

Q. Какие преимущества Scrum дает клиенту?

A. Быстрый запуск проекта с самыми приоритетными функциями и минимально возможным бюджетом. Контроль над ходом работ и более гибкий контроль над бюджетом проекта.

Q. Как оформлять договорные отношения?

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

Q. Сколько занимает внедрение scrum? Что это дает?

A. У нас внедрение заняло около полугода. В первые месяцы мы получили довольно резкий негатив со стороны разработчиков (люди не любят, когда что-то меняется и добавляется больше контроля). Пришлось много рассказывать, убеждать, показывать. Мы получили довольно существенное проседание по качеству и скорости в этот период. Однако на сегодняшний день, когда период адаптации давно прошел, я расцениваю прирост производительности на уровне 20-30% (в разных командах - по разному).

Q. Когда SCRUM не сработает

A. Гос-заказы. А также все случаи, когда не сработают и другие методы: низкая квалификация команды, заниженные сроки/бюджет, некомпетентный менеджер проекта.

Q. Какую оценку вы показываете заказчику?

A. Мы показываем экспертную оценку, выставляемую менеджером проекта или техническим руководителем. В ней как правило, заложены риски и учтена скорость работы конкретной команды (по опыту предыдущих проектов). Затем планирование этапа работ команды идет с помощью более точного механизма Planning Poker. Однако эта оценка редко интересует заказчика (как правило, она очень оптимистична и выставлять счета на основе этой оценки — самоубийство). Фактическую трудоемкость показываем некоторым клиентам, для которых это принципиально (например, если в договоре прописана почасовая оплата).

Q. Как поступать с этапами дизайна и контента? Тоже скрам?

A. Вообще можно попробовать. Методика — адаптивная, может и получится. Но у нас — не прижилось. Мы используем эти этапы как-бы за рамками Scrum.

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

Автор: Владимир Завертайлов, Сибирикс (Генеральный директор)

Комментарии экспертов

Юрий Гугнин

Компания: Бизнес-школа РИК
Должность: Управляющий партнер

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

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

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

Борис Вольфсон

Независимый эксперт

Автор статьи очень верно отмечает тенденции применения Scrum’а в веб-разработке и преимущества этой методологии над стандартными подходами с громадными документами типа ТЗ или ФТ и тяжеловесными подходами организации реализации проектов.

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

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

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

Макс Гулевич

Компания: РосБизнесКонсалтинг
Должность: Руководитель отдела проектирования и дизайна

Спасибо, очень интересная статья!

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

Создание и развитие данной методологии во многом обусловлено тем, что современный рынок ПО очень динамичен и развивается в жесткой конкурентной среде. Сегодня невозможно представить себе компанию, которая, работая на рынке e-commerce, не желала бы ускорить процесс доставки новых (или модернизации старых) продуктов и услуг на рынок. ИТ-процессы просто не поспевают за динамикой развития и трансформации бизнеса. Бизнес хочет «все и сейчас», стандартный водопадный процесс доставки может «что-то и завтра». Именно «что-то». Полностью согласен с автором, что за время пути собака обычно успевает подрасти до неузнаваемости и это при практически стопроцентной вероятности перерасхода бюджета.

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

Процессы разработки технических заданий, сбора требований, анализа, проектирования и дизайна сильно укорачиваются и, как следствие, удешевляются по сути, но усложняются по своему составу — работать «как получится» уже не получится!

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

Помните! Scum – методология разработки ПО для проектов с высокой долей неопределенности и креатива. Если бизнес вашей компании никак не связан с попыткой оторвать кусок рынка или вывести новый продукт на него за минимальное количество времени и средств, а вы просто оказываете консалтинговые или аутсорсинговые услуги и ваша деятельность гарантированно спланирована на годы вперед, то, увы, данная методология не для вас.

Александр Сергеев

Компания: Yangutu
Должность: Технический директор

Спасибо автору за увлекательный экшн вначале и за happy end - Скрум действильно работает. Мы используем элементы скрума в разработке нашего стартап-проекта Yangutu.

Хотел бы поделиться с читателями нашим опытом:

  • Детальное прототипирование и разработка ТЗ позволяют прийти к общему знаменателю со всеми участниками проекта, а также свести неопределенность в требованиях к минимуму; 
  • Непрерывный циклический процесс "точно вовремя": постоянно думаем над новыми фишками и идеями для проекта, изучаем конкурентов,
  • далее фильтруем идеи и отдаем их в проектирование, далее делаем ТЗ и далее в производство. В итоге люди не простаивают, всегда есть много задач,
  • воздух наполнен напряженностью, мотивация у всех зашкаливает;
  • Проект у нас большой, поэтому всю работы мы разбиваем на сервисы или фичи, каждый сервис разрабатывается как отдельный проект на 1 - 1, 5 месяца; 
  • Очень важно поддерживать информацию о ходе проекта в актуальном состоянии - нельзя управлять тем, что нельзя измерить;
  • Важно, чтобы ваш инструмент позволял легко и удобно работать с задачами и их приоритетами, мы используем Jira и плагин Green Hopper для Скрума;
  • Chart board - любимый вид отчета, не только для менеджеров проекта, но и для программистов;
  • Важно поддерживать ТЗ в живом состоянии (спасибо Google Docs), ТЗ может и должно меняется в течение всего времени разработки проекта (когда-то меньше - ближе к концу проекта, когда-то больше - на старте проекта);
  • ТЗ надо давать на вычитку тестировщикам, чтобы оно обрастало "мясом" и нюансами, про которые проектировщики/менеджеры проектов иногда забывают;
  • Проводим демонстрацию проекта на дев-серверах - сначала менеджеру проекта, потом тестировщикам, потом проектировщикам и далее бета-тестерам;

Тачат Игитян

Независимый консультант

Интересная статья, понравилась. Мое мнение по поводу Scrum-а.

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

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

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

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

Олег Бунин

Компания: Онтико
Должность: Генеральный директор

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

В статье, в списке вопросов и ответов, скромно помечено, что Scrum не работает для госзаказов и для команд низкой квалификации, заниженных сроков/бюджетов и некомпетентных менеджеров проектов. Да, я согласен почти полностью, разве что спектр заказчиков, не готовых использовать Scrum чуть более широк. Проблема в том, что эти условия, все вместе или что-то одно из них, наблюдаются в 90% случаев и в 90% случаев Scrum НЕ работает.

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

Например, мы делали проект ТакЗдорово по заказу компании "Ашманов и партнеры". Сроки - три месяца, объем проекта - 36 человеко-месяцев. Никакой Scrum не справился бы с такой задачей, использовался старый добрый водопад. Жесткий контроль, жесткие планы, позволяющие через несколько дней после возникновения проблемы перестраивать все будущее проекта вплоть до запуска. И успевать в срок!

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

Кроме того (и это признают сами евангелисты Scrum'а) - для использования гибких методологий требуется зрелая команды и высокий уровень ответственности. Давайте будем реалистами - таких команд не много и, в
большинстве случаев, риски просто не оправданы. Мы не можем рисковать деньгами заказчика: "Проверь, милый друг, а созрела ли у меня команда, чтобы применять на тебе нанотехнологичный способ управления работой". Заказчик делает бизнес, а не тестирует натотехнологии.

Мы (Онтико) следуем простому правилу - используемая методология целиком и полностью зависит от трех факторов:

  1. Заказчик;
  2. Проект;
  3. Команда.

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

Григорий Добряков

Компания: Paymico
Должность: Владелец

Автор поднимает весьма щепетильную тему для многих российских веб-студий и компаний-разработчиков. По своему опыту могу сказать, что многие команды поднимают у себя вопрос о переходе на Scrum и другие Agile-практики, так как это отвечает их пониманию эффективной разработки. Но они встречают препятствия сразу внутри своей же компании, даже не дойдя до Заказчика. Это и некомпетентные менеджеры, привыкшие "рисовать диаграммы Ганта" на полгода вперёд. И аккаунт-менеджеры (продавцы услуг) которые прямо мотивированы продать "вперёд и надолго", чтобы получить свой процент. И высшее руководство компании, которое заинтересовано продавать не "трудочасы", а так называемые "комплексные готовые решения" со значительной добавочной стоимостью.

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

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

Со стороны команды разработчиков хочу дополнить, что один из важнейших аспектов Scrum - короткие итерации - необходим для того, чтобы локализовать область концентрации внимания. Никто не может удержать в голове весь проект, все взаимосвязи и всю документацию. Поэтому правильно составленный спринт (итерация) локализует внимание команды и Заказчика в одной области задач, которые можно быстро спроектировать, быстро решить, и быстро протестировать. Этому же способствует методика feature branches, которая позволяет в любое время иметь проект в стабильном состоянии, и в любое время "пускать" туда Заказчика без "багов" и остатков недоделанных функций.

Евгений Курышев

Компания: Ostrovok.ru
Должность: Командор

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

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

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

Денис Тучин

Компания: i-Sys
Должность: Руководитель команды разработки

В большинстве своём грамотно описана методология Scrum и все её плюшки. Добавлю лишь немного из собственного опыта.

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

В статье очень скромно упомянута роль Scrum-мастера, возможно, потому что в проектах автора часть его обязанностей на себя берёт менеджер проекта, который вроде как ещё и Product Owner.

Scrum-мастер – на самом деле, это то человек, за счёт которого весь Scrum и работает. Он следит, чтобы все описанные в статье процессы работали и работали правильно и эффективно, а не формально. SM огораживает от всех невзгод и устраняет внешние препятствия, а внутренние проблемы он делает для команды более явными и подталкивает команду к их решению. Часто, правда, Scrum-мастер сам является членом команды, но это отдельная история.

На первый взгляд, Daily Scrum Meeting действительно похож на ритуал, но если к нему так относиться, то толку от него не будет – только впустую потраченное время. Ежедневный Stand-up – это то время и место, где команда может узнать, что у кого-то возникли проблемы, а он не решается об этом сказать; где можно порадоваться быстрому прогрессу или договорится поднапрячься, чтобы нагнать план; это в первую очередь для команды – это не контроль! Контроль, если он необходим, чаще, чем раз в итерацию нужно проводить другим способом, но никак не в доверительной обстановке Daily Scrum!

Есть момент, где я и некоторые мои коллеги не согласимся с автором: с гос. заказчиком нельзя работать по-другому, кроме как по Scrum. Требования постоянно меняются, стейк-холдеры пытаются давать задачи напрямую программистам, минуя аналитиков, ПМов и тим-лидов, заказчик может сказать на финальном показе, что вы сделали всё не так, как нужно, и вам придётся посадить за проект весь офис с круглосуточным рабочим днём, чтобы в недельный срок перелопатить 1/3 проекта. Понятно, что такому заказчику необязательно знать, что такое Scrum – нужно иметь одного или команду аналитиков, выполняющих роль Product Owner-а и отличную Scrum команду, которая будет проводить периодически показы заказчику – не обязательно раз в итерацию, но желательно, не сильно реже.
 

Дмитрий Спирин

Компания: Greencom
Должность: Тимлид

Я был свидетелем перехода работы компании (да вся компания, по сути, это "отдел производства") на рельсы Scrum'а. Небольшой коллектив, занимаемся развитием пары собственных IT-проектов. Проблема до этого была в том, что цели ясны были, а сроки их достижения нет, и никто не мог ответить, когда. Поскольку мы сами кузнецы своего счастья и очень сильно углубляться в разные игры, парное программирование и т.п. не хотелось, то был выбран именно Scrum. Как написано почти во всех книжках и говорят почти все тренеры-консультанты, команда должна сама выработать тот способ работы, какой ей подойдет больше (т.е. все на примере проб и ошибок, нет какого-то списка четких правил к действию)". Долгое время мы решали, сколько будет длиться спринт, кто должен присутствовать на scrum-митингах, как и сколько мы должны обсуждать постановку задачи от product owner'а, насколько детально должны потом анализировать задачи между собой, чтобы их правильно оценить. Ведь на планирование очередного спринта у нас, по сути, уходит целый день, а сам спринт длится 2 недели (включая этот день).

Что по факту. Да, мы достигли того, что теперь каждый участник команды знает, куда развивается продукт, что будет готово через 2 недели, а что через 4, какие планы. Да, теперь каждый из нас знает, чем занимается другой. Каждый участвует в обсуждении всех задач и может высказать мнение, пожелание, возразить. Каждый может выбрать интересную ему задачу из пула задач на спринт. У нас появились сроки и мы не 100%, но все-таки их выдерживаем! У нас появилась гибкость, и если что-то идет не так или появилось ново видение, в течение 2х недели мы сможем без проблем скорректировать наш курс.

Но есть и проблемы. Большой проблемой всегда оставалось в течение дня (на планировании) услышать задачи, обсудить их устно и тут же указать длительность ее реализации (а это нужно, чтобы спланировать спринт и ресурсы). Даже при наличии 1-2 часов на то, чтобы посмотреть детали по задаче, в 50% случаев, а то и больше, срок оказывается неточным (как в большую, так и в меньшую сторону по факту). Вторая большая проблема - это стыковка параллельный процессов, когда сначала дизайнер в течение недели рисует дизайн, а на вторую неделю его внедряют. Если поплыл срок на первой или, что бывает чаще, поменялись требования, то разработчику на второй недели приходится не сладко.

Проблемы бывают и основанные на человеческом факторе. Бывают люди интроверты, которые может и качественные работники, но совершенно не могут/умеют/хотят общаться. Такие люди могут просидеть все планирование и не сказать ни слова. К тому же, все-таки для scrum'а подходит "командная игра", т.е. для решения своих задач исполнители самостоятельно должны проявлять какую-то инициативу, контактировать с дизайнерами, проектировщиками, да и между собой принимать какие-то решения. И вот тут личности-одиночки довольно сильно выбиваются их концепции Scrum'а. Эту ситуацию помогает только частичное перевоспитание людей и подстройку команды под их личные особенности.

Сергей Скорбенко

Компания: Will Digital Agency
Должность: Владелец

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

1. Небольшой(бюджетный) проект – веб приложение для
a. Хранения данных, заносимых пользователем или импортируемых из внешних источников (Excel)
b. Обработка(всякие прогнозы потребления электроэнергии на основе статистических данных) и визуализация этих данных в виде диаграмм(чартов)
c. Выгрузка в тот же Excel с красивым форматированием.

Решили использовать Flex(Adobe) для клиентской стороны(GUI) и PHP+Oracle для серверной. В качестве мостика для передачи данных между клиентом и сервером использовали AMFPHP. Разработка и внедрение проекта было рассчитано на 1 месяц.
Изначально в команде было 4 человека: 

  • Flex разработчик, 
  • PHP (это был я, по совместительству и руководитель проекта), 
  • структуры БД,
  • тестер.

После первой встречи с заказчиком и ознакомлением с основными требованиями к системе была составлена первая версия ТЗ и отправлена на подтверждение. После 2ух или 3ёх таких встреч была утверждена «окончательная» версия.

Работали мы по такой схеме:
Каждый день с утра(после кофе) примерно в одно и то же время в одном и том же месте собирались на планерку, минут на 10. В зале заседаний у нас была доска с маркерами и куча больших белых листов к ней. Повестка была всегда одной и той же. 

  • что мы сделали вчера, 
  • чего не сделали из запланированного, почему и насколько это отодвигает наши сроки,
  • что мы собираемся делать сегодня (и возможно завтра) (и это было детальное техническое обсуждение функционала необходимого для стыковки клиента с сервером)

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

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

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

Когда возникали мелкие вопросы, я звонил представителю заказчика, обсуждал их и вносил правки в ТЗ. С более крупными – уже договаривался о встрече, собирались и обсуждали.

Как ни странно, но через месяц система была готова, установлена у клиента и презентована (мной) высшему руководству.

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

2. Второй проект был намного серьёзнее, - тоже веб приложение, но уже с использованием Java технологий(SpringMVC, Hibernate, JSF, Oracle, Maven и т.д.)

Проект был для Европы и работали мы удалённо. Команда состояла из 5 разработчиков(из них было даже привлечено 2 фрилансера), 1 тестера и меня как руководителя (со знанием языка заказчика :)

Пришлось изучить методика расчёта functional points для расчета времени разработки. От заказчика мы получили пакет документации с функциональными требованиями и даже придуманным им GUI. На его основе и были рассчитаны functional points, и как оказалось, с нашими ресурсами необходим был 1 год на разработку.

Ежедневно мы собирались, как и на предыдущем проекте с теми же вопросами. Обменивались мнениями, решениями возникших проблем и двигались вперед, не останавливаясь и не изобретая колес, изобретенных ранее. После того как скелет был готов и более половины функционала детально обговорена с клиентом(сначала через почту и кучу xls файлов, потом быстро через JIRA ) необходимость в фрилансерах отпала. Через три – четыре месяца была готова первая версия с основным – базовым функционалом, чтобы показать клиенту. После чего начались спринты, в одну-две недели. Клиенту устанавливалась версия, высылался документ, содержащий инфу о том что было протестировано, что работает и что нет.

Стали появляться новые требования и колесо закрутилось. Ежедневные совещания закончились еще через месяц, когда в команде осталось только 2 лучших разработчика (остальных перекинули на другие проекты). Все мы работаем в одном офисе и при необходимости обсуждаем проблемы на месте, иногда в зале. Все основные борозды уже прорыты, каждый знает, что и как делать и так, человек в команде мало, задания я могу распределить лично, поэтому и отпала необходимость в ежедневных собраниях. Иначе бы они носили чисто формальный характер.

Сейчас прошел год и система готова на ~95% несмотря на множество изменений в ходе процесса разработки и уменьшение народа в команде.

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

Александр Макарчук

Компания: qb interactive
Должность: Генеральный директор

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

  1. Разработку крупных проектов бьем на этапы не больше 2-3 месяцев;
  2. Weekly meetings – тот же смысл, что и daily meetings, но с немного бОльшим погружением в детали. На 1 проект – не более 20-30 минут;
  3. На проектах с длительностью более месяца – презентуем текущий результат клиенту ориентировочно раз в месяц, составляя при этом список доработок и «хотелок»;
  4. Часть доработок сразу пускаем в ход, часть заносим в так называемый «полуторный этап», оплачиваемый отдельно. Цена этапа обычно не столь существенна (в масштабах всего проекта) и обычно этот этап закрывает «рюшечки», о которых большинство клиентов не умеют думать, смотря просто на ТЗ, прототипы, дизайн и прочее, но не на готовый результат.

Главные плюсы:

  1. Мотивация рабочей команды и бОльшая вовлеченность в процесс. Я, кстати, с удивлением прочитал про резкий негатив со стороны разработчиков. У нас реакция была противоположной;
  2. Прозрачность со стороны клиента.

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

Дмитрий Бороздин

Компания: Интаро
Должность: Генеральный директор

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

На что обратить внимание при использовании SCRUM:

  1. Нарушение плана на спринт. Если интернет-магазин уже начал свои продажи, тогда возникает риск нарушения планов на спринт. Происходит это из-за появления посреди спринта срочных обращений, связанных с текущей работой магазина, например, проведение маркетинговых акций, исправление дефектов, появление новых товарных групп. В такой ситуации либо меняется план на спринт, либо срочные задачи отдаются ресурсу, не занятому в реализации функций спринта.
  2. Product Owner – наиболее проблемная и важная роль. Если у клиента свой сильный департамент по интернет-продажам, то он выделит сотрудника, который сможет принимать участие в планировании спринтов, демонстрациях по итогам итерации. В иных случаях на эту роль лучше подойдет сотрудник исполнителя или вообще сторонний консультант, помогающий выстроить клиенту продажи в сети.
  3. Договор. Наша практика такова, что почти всегда с клиентом заключаем 3 контракта на старте проекта: на стартовые работы (начальная аналитика, дизайн, работы первой очереди), на лицензию, на сопровождение (большая часть работ проходит в рамках договоров этого типа).

Главный плюс гибких подходов в том, что клиент получает именно то, что ему нужно.
 

Владимир Синельников

Компания: Aero
Должность: Совладелец

Scrum – это менеджемент-фреймворк, больше рассчитанный на длительные и нетиповые проекты. Его итерационная структура идеальна для проектов, которые постоянно развиваются и зачастую не имеют четкого финиша. В наших условиях это, в основном, стартапы, разработка которых ведется «in house», без привлечения сторонних разработчиков, силами заказчика – он же в этом случае является Владельцем продукта (Product Owner).

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

Плюс к этому возникают дополнительные сложности ведения параллельной разработки и поддержки одного и того же ресурса (на примере интернет-магазина: использование одной БД с «живыми» заказами, товарами, пользователями и для разработки, и для продаж).

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

Артем Лебсак

Компания: Joomru LLC
Должность: Владелец

Scrum полезен на долгосрочных проектах, при взаимодействии с "вменяемыми" заказчиками, без жестких временных и финансовых рамок на разработку. Со стороны заказчика должен выступать технически подкованный человек, а не просто "фантазёр". Внутри команды важно сформировать понимание того, что результат работы оценивается не по отдельности для каждого. Эффективность процессов напрямую будет зависить от личностных качеств Scrum Master. Вышеперечисленное - те узкие места, через которые придется пройти каждому, начав следовать методологии Scrum.

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

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

Асхат Уразбаев

Компания: ScrumTrek
Должность: Управляющий партнер

Scrum - это фреймворк, который используется, разумеется, далеко не только в web и не только в заказной разработке.

В заказном вебе специфика применения Scrum, правильно отмеченная в статье, в следующем: 

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

Тут важно, с моей точки зрения, четко отслеживать, какие преимущества дает применение Scrum.

  • Повышение внутренней прозрачности. Компания и разработчики понимают статус и цели проекта. 
  • Фокусирование. Работа в Scrum ведется небольшими командами. Традиционно в веб разработка "размазана" по группе людей. Сфокусированная разработка позволяет быстро заканчивать важные куски работ. 
  • Частая обратная связь с заказчиком. Если риски пересмотра концепции и требований высокие, частая демонстрация результатов приводит к вскрытию проблем раньше. Это, конечно, все равно бывает достаточно болезненно, но чем раньше мы узнаем о проблемах - чем проще выкрутится. 
  • Прозрачный статус для заказчика. Наличие баклога с четким статусом упрощает общение с заказчиком. 
  • Имхо, вне зависимости от типа контракта, изменениями нужно уметь управлять. Фактически, как Владимир и описывает в статье, баклог используется для процесса управления изменениями.

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

Борис Чернецов

Компания: Badoo
Должность: Руководитель отдела

Статья хорошо обосновывает плюсы SCRUM для заказчика, но практически не затрагивает другую сторону — разработчиков. Важно понимать, что SCRUM ни в коем случае не является для команды разработки универсальной панацеей от всех её бед. Невозможно действительно эффективно изменить методолгию «сверху» от менеджеров и руководства, просто спустив указания и объяснив разработчикам что мы с сегодняшнего дня переходим на новую схему, необходимость подобных изменений должна быть обоснованной, а лучше всего если она назреет внутри самой команды.

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

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

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

 

PS ведь иногда достаточно просто сократить время waterfall итерации :-).

Если Вы хотите дать экспертный комментарий к статьям, публикуемым на CMS Magazine, следите за анонсами материалов в нашей группе в Facebook.

Рекомендуем:

Комментарии (9)

Дмитрий Подлужный      Создано: 28.11.2011, 14:27          

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

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

Что заставила обратить мое внимание на Scrum?

В работе нашей студии мы давно ввели практику трех промежуточных этапов, которые можно было бы назвать спринтами в понимании Scrum. Мы обязательно проектируем варфреймы и обсуждаем проект на «бумажной стадии» с заказчиком, стараемся делать после верстки HTML прототип и обсуждаем его с заказчиком уже в реальном дизайне и с реальной интреактивностью, в итоге собираем сайт на CMS, который тоже обсуждается и тестируется совместно с заказчиком. Эти этапы были введены для контроля качества проекта (под качеством я понимаю решение задач проекта и удовлетворение заказчика итоговой работой), но я сейчас вижу, что можно добавить еще некоторые элементы Scrum, чтобы улучшить работу над проектами.

В процессе разработки сайтов я постоянно сталкиваюсь, что требования заказчика меняются (это не ново и с этим сталкиваются все). Но дело в том, что нередко я или мои коллеги предлагают новые, более эффективные решения задач, которые стоят перед сайтом и эти решения или изменяют существенно проект или усложняют его, т.е. получается, что в желании сделать лучше мы можем сами себе навредить. С точки зрения банальной логики получается, что не нужно предлагать заказчику ничего большего сверх того, что он запросил, но это идет вразрез с моими моральными убеждениями. Я лично желаю делать только хорошие продукты. Разрешить это противоречие, как я вижу, можно с использованием Story Map и выстраивания правильной политики релизов проекта. Мы еще это не ввели в практику заключения договоров, но все чаще и чаще в процессе работы над сайтами, нам удается показать заказчику, что новые сложные функции вполне можно вынести в следующий релиз сайта и что выстраивания нескольких релизов – это правильная политика в развитии сайта (экономит время, деньги, нервы, и приносит реальный результат).

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

И в качестве ссылки для размышления http://experience.openquality.ru/agile-ruined-my-life/

Softline      Создано: 28.11.2011, 14:32          

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

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


Сергей      Создано: 31.5.2012, 10:26          

Цитата(Softline @ 28.11.2011, 14:32)
Что касается гос. заказчика, не соглашусь с автором. Гос. заказчику на самом деле и не обязательно знать, по какой методологии будет работать команда, и будет ли она вообще пользоваться ей.

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

Анатолий      Создано: 28.11.2011, 18:24          

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

Андрей Базулин      Создано: 28.11.2011, 19:54          

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

В скольких случаях Product Owner это действительно представитель заказчика?

Владимир Завертайлов      Создано: 29.11.2011, 7:06          

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

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

Очень часто последнее время наблюдаю такую картину:

Есть менеджер проекта — который вроде как формально Product Owner. В команде есть Scrum Master. В общем, все по науке. Только скрам-мастер выполняет свои функции номинально. А вот менеджер проекта действительно вкладывается в то, чтобы сделать команду эффективной. Он задает правильные вопросы на ретроспективе, его советы команде наиболее дельные, он решает все внешние зависимости и устраняет препятствия.

Самое интересно, что и Product Owner из него тоже в общем-то нетипичный. Он старательно дистанцируется от самостоятельного принятия решений. Чаще всего он старается собрать всех заказчиков в группу и проводит встречу, заказчики коллективно договариваются о приоритетах и требованиях. Как правило, он устанавливает некоторую каденцию общения (уж простите термин, не удержался) — например, назначает еженедельные встречи.

Забавно, но он точно также вкладывается в то, чтобы команда заказчиков стала эффективной, как и в команду разработчиков. Если отбросить тонкости, то он становится скрам-мастером команды заказчиков и команды разработчиков, формально таковым не являясь. Такая схема на практике часто является очень эффективной.
-------------------------------------------------
[Источник: http://blog.scrumtrek.ru/2011/04/product-o...rum-master.html]

Softline      Создано: 2.12.2011, 11:31          

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

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

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

Alexander      Создано: 10.8.2012, 23:31          

Scrum это, прежде всего, мотивация каждого члена команды делать свою работу наиболее эффективно, так, чтобы конечный продукт стал конкурентным и на это потратили меньше ресурсов, чем тратят другие. Что говорит Scrum - лучше работать сообща - да, дураку понятно, что это так. Лучше работу сделать раньше - да, естественно. Лучше делать только то что нужно для конечной цели - да, так и есть. Лучше быстро реагировать на изменения окружающей среды, чтобы быть конкурентным - ну а как иначе.
Scrum - это достижение результата наиболее разумным способом (с наибольшей эффективностью), жаль что не все это понимают. Например, сидят люди на госбюджете, ресурсы позволяют не использовать скрам, более того, использовать его - самоубийство в таких ситуациях, и какова эффективность таких организаций? SCRUM - синоним эффективности и его можно применять везде, просто не везде нужна эффективность.

Сергей Волков      Создано: 28.11.2014, 17:07          

Интересная статья, однако не очень точно выбраны сравнения. особенно с диваном.
Согласитесь, покупать диван без привязке к пониманию общего интерьерного решения – просто глупо.
В целом SCRUM должен применяться только как методика управления процессом. Это подразумевает, что архитектурно все уже более-менее понятно, дизайн примерно продуман, есть, как ни странно ФТ, ТЗ и т.д. Ведь строить полезную функциональность на несоответствующей платформе – не гуд.
В отношении самой методики две вещи играют ключевую роль (сугубо мой взгляд):
1. Готовность заказчика проводить приемку результатов спринтов.
2. Размеры проекта и команды подрядчика. Формирование спринта не должно занимать более 5% времени команды.


CMS Magazine CMS Magazine
RSS-подписка комплексные решения
CMS Magazine CMS Magazine
CMS Magazine