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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо автору за увлекательный экшн вначале и за 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. Команда.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Расскажу вкратце о двух проектах, на которых мы в какой-то мере использовали 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, под каждый проект индивидуально.

«В России на данный момент практически нет заказчиков, готовых идти на гибкий бюджет проекта». Это утверждение является ключевым, поэтому веб-студиям до сих пор нужно с осторожностью относиться к технологии 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 контракта на старте проекта: на стартовые работы (начальная аналитика, дизайн, работы первой очереди), на лицензию, на сопровождение (большая часть работ проходит в рамках договоров этого типа).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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