Система работы завода «Тойота» уже стала классической и успешной менеджмент-моделью. У каждого работника предприятия была возможность в любое время остановить конвейер в целях устранения дефекта, неполадки или внесения своего рационализаторского предложения. Именно на таком подходе основана философия Agile. Изначально Agile методология около 10-15 лет назад была методом разработки программного обеспечения в малочисленных командах. В данный момент Agile методология – это новая культура управления крупными предприятиями. Сегодня любой прогрессивный менеджер знает, что представляет собой Agile.

Продукты и сервисы создаются, как правило, по единой классической схеме. Особенно это относится к IT-индустрии. Такую схему называют каскадной, или итеративной методологией разработки, а в английском языке – waterfall development («водопад»). По какой причине схема носит такое название? Все дело в том, что, если вы уже утвердили план программного продукта, то не можете приостановить его или внести коррективы до реализации. Совершенно иной принцип имеет Agile методология. Waterfall – понятие, которое к ней неприменимо. Это качественно новый подход к созданию продукции. Основу методологии составляет простая мысль – у каждого участника есть возможность внесения полезных предложений по оптимизации процесса, остановки конвейера с целью переосмыслить задачи и общее дело.

Agile методология имеет основу, наделенную рядом характеристик. Среди них:

• Быстрая реакция на изменения.
• Самостоятельная организация процесса производства.
• Предсказуемость.
• Наличие непрерывной и постоянной обратной связи.
• Разграничение рисков.

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

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

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

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

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

Основные принципы Agile методологии

Существует Agile-манифест, где сказано об основных принципах методологии:

1. Самое главное – регулярно и заблаговременно поставлять ценный продукт, удовлетворяя тем самым потребности заказчика. В соответствии с данным принципом Agile методологии создатели продукта обязаны не только реализовать требования, обозначенные в проектных документах, но и как можно раньше давать потребителю знать, что это будет за товар, с какими особенностями и характеристиками. Если продукция не удовлетворяет заказчика, необходимо срочно корректировать ее с учетом замечаний. Поскольку, выводя в рыночную среду новый продукт, есть большой риск ошибиться, логично использовать технические требования к созданию минимально жизнеспособного продукта minimum viable product (MVP), основная задача которого – проверить, насколько ключевые качества востребованы среди покупателей, и оценить уровень спроса.
2. Требования изменить можно, и это будет воспринято положительно, если речь идет о повышении конкурентных качеств товара. Обычно их меняют по окончании завершающего этапа разработки. Данный принцип Agile методологии на сегодняшний день очень важен, ведь продукция высокотехнологичных сфер в кратчайшие сроки становится устаревшей и уступает место новой. Сформировать ряд требований к продукту можно уже в финале его создания. Обычно это бывает вызвано изменениями на рынке или в среде конкурентов. Отметим, реализация данного принципа невозможна, если мы говорим о каскадной управленческой модели, или же она реальна, но обойдется спонсору в круглую сумму. Но чем больше будет происходить слияние технологий, тем более актуальной станет подготовка очередной версии продукта для опережения конкурентов.
3. Команда и заказчик должны непрерывно взаимодействовать на всех этапах создания товара. Данное правило носит примерно тот же характер, что и пожелания клиента. Это самое главное. Если нет постоянного взаимодействия, достичь поставленных целей сложно.
4. Agile методология гласит, что реализацией проектов должны заниматься исключительно мотивированные профессионалы. Позаботьтесь о создании должных условий и доверьтесь специалистам. В этом случае вероятность качественной реализации проекта очень высока. Современная наука говорит о том, что интеллектуальную работу сложно стимулировать финансовыми поощрениями. А потому сотрудничать следует только с теми специалистами, для которых главной мотивацией является непосредственно проект. Все, что им нужно, – это получить возможность работать в приемлемых условиях и заручиться доверием заказчика.
5. Лучший способ коммуникации – личный контакт. Желательно, чтобы все задействованные в проекте лица располагались на совместной территории. Пусть это будет одно здание. В идеале там же должен находиться и сам заказчик.
6. Проект прогрессирует, если продукт работает. Заказчика интересует готовый товар с теми или иными характеристиками. Еще один успешно выполненный этап процесса ему ни о чем не говорит. Заказчик должен видеть, что продукт развивается, а главное, работает и отвечает заявленным требованиям. Если его форма и наполнение приближаются к желаемой модели, значит, разработчики действуют эффективно.
7. Спонсорам, заказчику и разработчикам необходимо заботиться об обеспечении постоянного темпа деятельности. Если все участники процесса оперируют в устойчивом ритме, то перестают волноваться из-за вероятности аврала или срыва сроков.
8. Следует обращать внимание и на техническое совершенство и качество проектирования. Agile методология гласит, что разработка проекта должна быть гибкой, без ущерба качеству продукта и упрощения его характеристик. Отметим, к этому нередко прибегают, чтобы ускорить процесс создания проекта и оптимизировать его.
9. Не стоит забывать о принципе простоты. Применяя его, вы сводите вероятность выполнять лишние действия к минимуму. Суть не в том, чтобы упрощать характеристики продукта, а в том, чтобы избавляться от ненужных операций и не включать в проект нечто ненужное для его использования по назначению.
10. Самоорганизующиеся команды всегда генерируют лучшие идеи архитектурного, технического и иного плана. В этом уверены авторы Agile-манифеста. А потому все участники команды должны разрабатывать требования и принимать решения сообща. Если у членов коллектива общие интересы и единые цели, самоорганизация становится более эффективной.
11. Внешние условия постоянно меняются. В связи с этим следует постоянно анализировать и адаптироваться к обстановке, искать методы улучшения эффективности деятельности. Agile методология ориентирована именно на гибкость разработчиков. Это то, к чему нужно стремиться.

Мнение эксперта

Перспективы Agile методологии в России

Андрей Кочешков ,

главный аналитик ОАО «Издательство «Просвещение»

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

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

Гибкие методологии: Agile, Lean, Scrum и другие

В Agile Manifesto определены особые принципы. На их основе сформирована гибкая методология разработки Agile.

• Agile Modeling (AM). Здесь применяются процедуры по моделированию (в том числе проверка кодом модели) и документированию в ходе создания ПО. Меньше внимания уделяется процедурам по проектированию и строительству диаграмм на UМL. Не сказано о таких областях, как разработка, тестирование, управление проектом, развертывание и сопровождение.
• Agile Unified Process (AUP) является унифицированной версией методологии RUP (IBM Rational Unified Process), которую сформировал Скотт Амблер. АUP определяет модель разработки ПО в рамках приложений для бизнеса.
• Agile Data Method (ADM) - это итеративные методики гибкого создания ПО в комплексе, которые делают акцент на разработку решений и требований. Разные кросс-функциональные команды сотрудничают между собой.
• Dynamic Systems Development Method (DSDM) – инкрементный и итеративный метод, основа которого – быстрая разработка приложений (Rapid Application Development – RAD). Акцент делают на то, чтобы максимально привлечь конечного потребителя к созданию продукции.
• Essential Unified Process (EssUP). Автор подхода – Ивар Якобсон. Подход наделен методами итеративного создания ПО. Акцент делается на архитектуру продукции и наработанные практики команды, заимствованные из RUP, CMMI и Agile Development. Суть идеи состоит в использовании лишь тех методов и техник, которые применяются в конкретном случае. Именно их выбор является основой определения целевого процесса. Данный подход отличается от RUP с взаимосвязанными методами и практиками. Здесь же есть гибкость и возможность вычленения необходимых элементов из всего, что доступно.
• Extreme Programming (XP), или экстремальное программирование. Суть метода – в использовании уже имеющихся лучших техник в сфере создания ПО и усовершенствовании их. Данный подход и обычная практика отличаются друг от друга, в частности тем, что в последнем случае программист проводит последовательную проверку написанного своим коллегой кода. Экстремальное программирование предполагает параллельную проверку, что способствует более быстрому выпуску продукции, но вместе с тем увеличивает и риски.
• Feature-Driven Development (FDD). В рамках использования метода есть главный запрет, заключающийся в том, что реализация каждой функции должна осуществляться в течение двух недель и не более. В идеале ее разработка производится за один раз. Если это невозможно, функцию разбивают на несколько и реализовывают плавно.
• Getting Real (GR) - при использовании метода не прибегают к процедурам функциональных спецификаций, используемых для web-приложений. Разработку начинают с обратной стороны, то есть сначала задумываются о дизайне и интерфейсе, а потом – о функциональном наполнении.
• OpenUP (OUP) - в основу разработки подхода положен RUР. Метод определяет итеративно-инкрементальный способ создания ПО. В рамках подхода сказано о жизненном цикле разработки (фазах запуска, уточнения, разработки и передачи заказчику). Метод реализуют в несколько этапов, проверяя определенные контрольные точки, что способствует повышению эффективности контроля и мониторинга воплощения проекта в жизнь. Все решения, касающиеся проекта, принимаются вовремя.
• Lean Software Development. Основа подхода – концепция бережливого управления производственной компанией (lean production, lean manufacturing).
• Scrum является одним из наиболее востребованных методов гибкого создания ПО и определяет правила по управлению процессом производства с использованием известных способов. Акцент в данном случае делают на вовлечении заказчика в разработку (когда завершается очередной этап, возможна смена или уточнение требований к создаваемой продукции). Это позволяет выявить недочеты и откорректировать продукт.

Методология Agile Scrum – одна из популярных технологий

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

Период действия «скрам» небольшой. Участие в этой фазе регби принимают лучшие спортсмены с отличной подготовкой, так как она достаточно травматична. Если подготовленные и сильные игроки отсутствуют, «скрам» попросту не проводят. Методика Scrum в России становится все более распространенной. Остановимся на ней подробнее.

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

Важный элемент методологии – бэклог продукта (backlog). Это перечень требований к конечному результату. Требования здесь четко структурированы по уровню важности. Именно из перечня берут задачи для последующих спринтов. В список можно вносить коррективы и дополнения по ходу уточнения характеристик и реализации продукции.

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

В методологии также определены структурированные роли в проекте:

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

Финансистам методология дает ряд преимуществ, а именно:

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

Основная проблема в данном случае – вопрос юридического оформления такого вида деятельности и взаимодействия с внешней командой разработчиков.

Зачем вам нужна Agile методология управления

• Система позволяет хорошо себя чувствовать в кризисный период и в неопределенных ситуациях, получать доход, защищать свой бизнес, грамотно применять имеющиеся ресурсы и возможности.
• Agile методологии отдают предпочтение как крупные предприятия, занимающиеся внедрением гибких управленческих методов, так и небольшие компании. Для последних Agile методология – лучший вариант. Речь здесь идет о заведениях общепита, стоматологических клиниках и кабинетах, автосалонах; кроме того, Agile методология позволяет «тюнинговать» бизнес-процессы по таким направлениям, как организация внешнеэкономической деятельности, построение систем продаж и кризис-менеджмент.
• Применяется Agile методология в менеджменте, маркетинге, финансовой отрасли, управлении персоналом. Благодаря ей можно достичь сверхбыстрой реализации проектов и отличного результата.
• Agile методология – в первую очередь это гибкое мышление и только потом инструменты. Чтобы успешно пользоваться ею, следует внести определенные изменения в менталитет, культуру работы с проектами на предприятии.
• В Agile есть множество методов. Самые популярные сегодня – Scrum и Kanban.
• Agile методология способствует выведению вашего бизнеса на новый уровень с учетом существующих возможностей, ресурсов и практических навыков сотрудников.
• Agile методология подойдет любому предприятию, ориентированному на получение большего дохода и усиление влияния в рыночной среде.
• Agile методология обеспечивает поиск и введение новых технологий, связанных с прорывом, развитием внутренней предпринимательской деятельности, креативности подхода и мышления в крупных организациях.

Все вышеперечисленное – лишь начало. Многие эксперты бизнес-сферы и руководители крупных предприятий уверены: Agile методология – будущее современной экономической отрасли.

Мнение эксперта

Внедрение Agile методологии для повышения эффективности персонала

Мария Онучина ,

директор департамента управления объектами компании Becar Asset Management Group, Москва

Мы видоизменили наше офисное пространство, чтобы перейти к управлению по Agile методологии:

Этап 1. Организация рабочих мест.

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

Для сотрудников, деятельность которых предполагает постоянное нахождение на работе, оборудовали постоянные места. Мобильному персоналу предоставили временное пространство на территории open-space. Туда можно прийти, занять понравившееся место и включить удаленный доступ. Уделили внимание и неформальным зонам: помещениям для отдыха, переговоров, рабочим кафе.

Мы постарались организовать пространство в офисе так, чтобы у сотрудников появилась возможность в любой момент изменить расположение:

• если нужно, побыть в одиночестве;
• объединиться в мини-группы;
• провести совещание между отделами в любом составе.

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

Этап 2. Адаптация работников.

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

Этап 3. Введение необычных решений.

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

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

• современные инженерные решения;
• IT-инфраструктура;
• комфортабельная мебель;
• поверхности для записей идей в процессе переговоров и пр.

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

Результат . Несколько месяцев пребывания в улучшенном офисе показали: работа стала командной, а коммуникация между специалистами разных отделов улучшилась. Удалось сэкономить на аренде. В среднем на человека в офисе масштабной организации приходится 12-40 м 2 . Ранее у нас было 10 м 2 , и этот показатель удалось сократить до 6 м 2 , эффективно распределив рабочие места. Срок окупаемости проекта составил 1,5 года.

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

Какие проблемы могут возникнуть, когда используется Agile методология

Проблема 1. Привычка к роли.

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

Проблема 2. Привычка к документации.

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

Проблема 3. Новая команда.

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

Проблема 4. Проблемы с общением.

Задача менеджера проекта на начальном этапе – проведение митингов с участниками команды для достижения продуктивной и эффективной деятельности.

Проблема 5. Давление по срокам.

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

Проблема 6. Креативность.

Задачи в проекте бывают как интересными, так и не очень. Разработчики зачастую испытывают удовольствие от принятия решений, которые вредят проекту, но интересных технически. Здесь стоит вспоминать о принципах КISS (keep it simple, stupid) и YAGNI (you ain’t gonna need it). Пусть основной характеристикой проектных решений будет простота. Не следует выполнять то, что не особенно нужно в данный момент.

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

Проблема 7. Оценка времени.

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

Проблема 8. Проблема с менеджментом.

В ожиданиях менеджмента – наличие определенного функционала к указанному времени. Но Agile методология не гарантирует выполнения планов на 100 %. Логично лишь ждать, что будут решены приоритетные задачи. Полезным является согласование с менеджментом планов на уровне релизов. Высокий уровень плана релизов дает возможность руководителю в довольно больших временных рамках варьировать объем разработки даже отдельных характеристик системы. К примеру, задача создания подсистемы поиска может включать учет морфологии. Возможна и экономия на данном этапе.

Проблема 9. Проблемы некомандного поведения.

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

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

Agile методология без ошибок

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

Требуется точное осознание того, какой результат нас интересует, какими сроками и бюджетом мы располагаем. Нечеткие цели и красивые формулировки, к примеру, «Стать номером один в своей сфере» или «Начать работать более эффективно» не подходят. Пусть задачи будут выражены в цифрах. Например: «Достичь в 2018 году оборота в 3 млрд. долларов», «Сократить время создания продукта до 3 месяцев» и т.д.

Ошибка 2. Неверный диагноз.

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

Ошибка 3. Введение Agile только на отдельном участке бизнес-процессов.

Это логическое продолжение второй ошибки, описанной выше. Причина ее допущения такая же: отсутствие понимания проблемы и того, где она скрывается. Меняться должны все отрасли предприятия: производственная и маркетинговая части, бухгалтерия и продажи. В противном случае, ничего не получится. Если изменения ввести только в маркетинг и не дождаться желаемого эффекта, у вас закрепится прочное мнение о том, что Agile методология неэффективна.

Ошибка 4. Занижение важности вовлечения всех сотрудников компании.

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

Ошибка 5. Иллюзия, что все возможно только благодаря человеческим усилиям.

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

Ошибка 6. Нежелание менять кадры.

Практически 90 % успеха зависит от коллектива предприятия. Следует уделять непрерывное внимание развитию, обучению и правильной мотивации сотрудников. Множество специалистов не готовы вести деятельность по Agile методологии, им не интересны новые знания и возможности, освоение бизнес-процессов. Порядка 25-30 % персонала предприятия не желают выкладываться на все сто и стремиться к высокому заработку. Таким сотрудникам лучше сказать: «Прощай». Слабые звенья бывает достаточно сложно выявить, а потому HR-менеджеры зачастую не занимаются этим.

Ошибка 7. Потеря заинтересованности и участия топ-менеджеров.

Обычно на внедрение проекта уходит 8-16 месяцев. В 70 % ситуаций уже по прошествии трех месяцев заинтересованность участников понижается. Как следствие, члены команды просто не хотят входить в состав проекта. Если дела обстоят именно так, решить поставленную задачу вы, конечно, не сможете.

Agile методология: примеры неудачного применения

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

Пример: в 2015 году на фондовой бирже в Нью-Йорке проводились торги, которые пришлось остановить на целых 4 часа. Сначала это объяснили кибератакой. Но, как выяснилось позже, проблема заключалась в баге в процессе очередного обновления. Конечно, 4 часа простоя центра мировой торговли принесли миллиардные убытки.

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

Наиболее громкий провал использования Agile методологии связан с запуском системы медстрахования Obama Care в США. Смысл программы состоял в следующем: определенным категориям американских граждан предоставляли бесплатные полисы страхования. Для получения такого права человеку следовало заполнить анкету на сайте и дождаться решения определенных служб. Конечно, миллионы людей бросились заполнять анкеты. Но проблема заключалась в том, что анкету им удавалось заполнить, а отправить ее – нет, возникал какой-то сбой сервера. Система Obama Care прекратила свое действие приблизительно через 6 месяцев после старта. Чтобы наладить работу, заинтересованные лица привлекли специалиста извне, который оценил ситуацию. Консультант проделал огромный путь, начав с конца – «продакшна», собрал части вместе и сумел достичь корректного функционирования системы.

Мнение эксперта

Пример успешного внедрения A gile-управления

Сергей Бучик ,

генеральный директор NPM Group, Новосибирск

Фирма, включая все подразделения, переходила на работу по Agile методологии на протяжении 1,5 лет. Ранее в HR-отделе состояли: специалист по кадрам, менеджер по обучению и рекрутер. Руководство подразделений, выбирая новый персонал или проводя обучение, заполняло заявки в огромном количестве. Теперь каждый отдел предприятия имеет свой HR. В группах разработчиков, ведущих деятельность по Scrum методологии, это место отведено Scrum-мастеру. Продукция здесь – это кадровый сервис, а участники коллектива – внутренние потребители.

Новая манера управления по Agile методологии хорошо прижилась в области подбора сотрудников. Заказчик может планировать свою деятельность, учитывая выход кандидата в точно указанное время. В течение 9 спринтов длительностью в 2 недели нам удалось сократить количество просроченных вакансий в 2 раза. Простая вакансия (к примеру, литейщика) теперь закрывается за 20 дней, средняя (сервисного инженера) – 32 дня, редкого специалиста (инженера-технолога по литью пластика) – за 51 день. Завершив первый спринт, рекрутерам стало ясно: для руководства отделов главное – не быстрота поиска, а прозрачные сроки закрытия вакансий и период времени, который они могут потратить на выбор сотрудника с последующим обучением. В настоящий момент менеджер рассказывает заказчику о сроках и стадии поиска соискателя. В обязанности рекрутеров также входит «прокачка» технических компетенций, необходимых для того, чтобы эффективно подбирать производственные вакансии, к примеру, обучение чтению чертежей.

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

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

Agile методология управления проектами: 6 правил эффективности

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

У долгосрочных планов точность достаточно низкая, поэтому составьте план в трех плоскостях:

• план в долгосрочной перспективе с указанием всех задач, необходимых к выполнению и крупным планированием сроков реализации ключевых вех;
• помесячные планы целей, взяв за основу общий план (их выполнение не должно быть ниже 90%);
• определите в рамках месяца максимально детализированные цели, четко описав результаты их достижения.

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

Правило 3. Время от времени встречайтесь с командой по внедрению. Периодичность встреч – 1-2 раза ежемесячно. Это требуется для определения решения задач и проблем, своевременной корректировки плана при возникновении сложностей с внедрением. Вместе с тем регулировать острые конфликтные ситуации не следует в ходе встречи, которая по плану намечена через неделю. Разрешение должно быть четким и оперативным.

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

Правило 5. Говорите неэффективным сотрудникам «До свидания», если видите, что Agile методология им не близка.

Правило 6. Не настраивайтесь на идеальное решение задач с первого раза. Порядка 95 % эффективных инструментов и идей удалось достичь после множества повторов и внесения корректировок по прошествии нескольких итераций.

1. Эндрю Стеллман, Дженнифер Грин «Постигая Agile».

Книга рассказывает о четырех главных вариантах, в которых представлена Agile методология. Описание их достаточно интересно и подробно. Благодаря пособию овладение искусством применения методик становится легким и занимательным.

В книге раскрывается суть наиболее востребованных Agile методологий: Scrum, XP (экстремального программирования), Lean (бережливого программирования) и Kanban (Канбан); рассказывается, как использовать их, чтобы создавать качественные программы и достигать поставленных целей. В пособии говорится, как Agile методология помогает менять мышление участников проекта, сплачивать их и вместе стремиться к улучшениям. Цель издания – рассказать о методах Agile, ценностях и принципах, благодаря которым команды могут полностью менять стратегию работы над проектами и подходить к ней иначе. Пособие заинтересует и проектных менеджеров, и руководителей, и просто тех, кто увлекается гибкой методологией разработки Agile.

2. Борис Вольфсон «Гибкое управление проектами и продуктами».

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

3. Джефф Сазерленд «Scrum. Революционный метод управления проектами».

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

Scrum существует вот уже 20 лет, и за это время методикой успешно воспользовались не только разработчики ПО, но и производители авто, фармацевты, ФБР и простые люди, планирующие свое время и возможности.

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

4. Роман Пихлер «Управление продуктом в Scrum».

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

5. Кеннет С. Рубин «Основы Scrum».

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

Информация об экспертах

Андрей Кочешков , главный аналитик ОАО «Издательство «Просвещение». «Просвещение» - советское, а позже российское специализированное издательство учебной и педагогической литературы.

Мария Онучина, директор департамента управления объектами компании Becar Asset Management Group, Москва. ООО «Бекар-Эксплуатация» (Becar Asset Management Group). Сфера деятельности: системное решение проблем управления объектами (property management), проектами (project management) и инвестициями (брокеридж, оценка). Численность персонала: 5000. Территория: фронт-офисы – в Москве и Санкт-Петербурге; три представительства и 55 обособленных подразделений – в разных городах России.

Сергей Бучик, генеральный директор NPM Group, Новосибирск. ООО «НПМ» (NPM Group). Сфера деятельности: производство оборудования для индустрии напитков; разработка IT-решений для интеграции с оборудованием, мобильных приложений. Численность персонала: более 300. Доля рынка: 95% оборудования по розливу пива и газированных напитков в России. Количество патентов на собственную продукцию: свыше 80.

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

Agile, появившийся как метод разработки ПО в небольших командах лет 10-15 назад, сегодня становится новой культурой управления большими компаниями. Благодаря недавнему выступлению Германа Грефа термин Agile входит в лексикон всех современных российских менеджеров.

Что же такое Agile и почему этот метод называют чуть ли не единственно правильным?

Существует классический подход к созданию продуктов и сервисов, характерный в первую очередь для ИТ-индустрии. Этот подход называется каскадная, или итеративная методология разработки. В английской терминологии такой подход называют waterfall development (от англ. - водопад). Почему его называют водопадом? Потому что при такой схеме разработки, однажды утвердив план программного продукта, вы не сможете этот план остановить или изменить до его создания.

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

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

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

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

Безусловно, есть организации, которым Аgile вовсе не нужен. Например, государственные ведомства. Их деятельность основывается на законодательстве. Мы не сможем взаимодействовать с государством, если правила игры меняются каждый день.

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

Переход большого классического бизнеса (Enterprise) к Agile

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

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

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

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

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

Гибкое планирование

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

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

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

Читайте материал

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

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

Неудобные вопросы

• Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
• Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
• Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

Делай сразу!

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

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

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

Горизонтальная организация

Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле - лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах product owner’у, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

Еще одна важная ценность agile-команд - взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер - маркетологом.

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

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

Как внедрить Agile?

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

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

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

Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

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

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

(Управляющий партнер ScrumTrek Алексей Пименов в на Rusbase)

Слово экспертам

Владимир Овелян

Владелец и генеральный директор Dostаевский

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban.

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

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

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

Виталий Сотников

Креативный директор Бюро визуальных коммуникаций «Черника»

Илья Шихалеев

Ведущий разработчик и скрам-мастер iSpring

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

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

Евгений Россинский

Директор по технологии в онлайн-кинотеатре ivi

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.

Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.

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

Доктор Ройс создал так называемую водопадную модель разработки программных продуктов. Она быстро завоевала популярность на Западе, и некоторое время назад по этой модели работало подавляющее большинство компаний-разработчиков. Что она собой представляет? Разработка продукта проходит через ряд этапов:

• сбор требований;
• их анализ;
• создание архитектуры;
• создание дизайна системы;
• кодирование;
• тестирование;
• выкладка;
• эксплуатация.

В идеальном мире мы прошли бы по этим уровням сверху вниз, как течет водопад, и в конце у нас получилась бы хорошая система. В чем заключалось решение доктора Ройса? Он предложил писать много документации, обрабатывать риски, повторять по несколько раз какие-то этапы. В итоге получилась тяжеловесная водопадная модель. Вся индустрия коммерческого софта сформировалась в 1990-х годах. И если в Европе и США существовали тяжелые методологии, то у нас не было никаких. Собиралась группа людей, которые просто пытались сделать хороший софт. Обе проблемы - отсутствие методологии у нас и тяжеловесные схемы на Западе - хорошо решает Agile.

Для чего нужна методология гибкой разработки?

Итак, для чего же применяется методология Agile?

• Ускорение вывода продукта на рынок . Если вы хотите что-то сделать быстрее, нужно делать это в соответствии с Agile. Очень простой пример. Есть две компании, у них примерно одинаковый бизнес. Одна пишет ТЗ, затем проектирует систему и рисует дизайн - это водопадная модель, на разработку которой может уйти несколько месяцев. Во второй компании, работающей по Agile, к этому времени может быть уже запущен сайт, выпущено ПО, она начнет зарабатывать деньги и захватывать рынок, что самое главное.
• Управление изменениями в приоритетах . Это, пожалуй, весьма болезненная проблема практически для всех компаний. Если вы делаете проект, который длится хотя бы несколько месяцев, то у вас обязательно поменяются требования. Конечно, если это не софт, например, для спутника или марсохода. Хотя даже спутникам и марсоходам обычно заливают свежую версию софта, когда они прилетают в точку назначения. Если говорить про коммерческую разработку, то проблема в том, что мы, программисты, аналитики и дизайнеры, никогда не знаем, что нужно не только заказчику, который нам платит, но и пользователям. Обычно все подходят к вопросу так: пока пользователь не попробует функционал сайта или приложения, вы не знаете, нужен он или нет.
• Улучшение взаимодействия между IT и бизнесом . Это головная боль, особенно для крупных компаний, ведь у бизнеса периодически меняются требования, каждый говорит на своем языке. В результате стороны друг друга не понимают.

Ответом на все эти вызовы явился Манифест гибкой разработки ПО.

Манифест гибкой разработки

Он состоит из нескольких частей. Первая часть называется «Ценности» (Values). Это четыре «взвешивания»:

• Если вы хотите построить гибкий процесс, вам нужно взаимодействовать и общаться между собой. В чем это выражается - рассмотрим ниже на примере Scrum. При этом вы можете (и обязательно будете) использовать какие-то инструменты и процессы, например, трекеры - JIRA, Redmine и т.д. Но ваша работа должна опираться на различные митинги, встречи и взаимодействие, а не на настройки трекеров или TFS (если говорить про Microsoft стэк).
• Работающий продукт, который мы делаем, намного важнее, чем документация по нему. Выше был приведен пример с двумя компаниями: у одной имеется готовый продукт, который можно дать пользователям, заказчику, захватив рынок; а вторая пишет ТЗ, рисует макеты и т.д. Вся эта документация, которую пользователь не может применить по причине не готовности продукта, не приносит ценности этому пользователю. Если мы научимся работать, минимизируя эти шаги, либо делая их небольшими кусочками, то у нас получится более гибкий процесс.
• Сотрудничество и взаимодействие с заказчиком важнее жестких контрактных ограничений. Обычно подписывается договор, в котором указано, что к конкретной дате за определенную сумму разработчик обязуется выполнить оговоренный объем работ. Естественно, к договору прикладывается ТЗ. То есть фиксируется время, объем работ и сроки. Это называется Fixed Price. Такой подход не очень хорош, если вы хотите работать на долгосрочную перспективу и быть гибкими. В этом случае правильнее выстраивать партнерские отношения с заказчиком. Если говорить про контрактные оформления, то обычно это выливается в контракты по схеме «время - материалы», когда разработчику просто оплачивается потраченное время. Самое главное, что здесь начинается поиск партнерства и ситуации Win-Win, когда побеждает и заказчик, и его подрядчик.
• Готовность к изменениям во взвешивании со следованием первоначальному плану.

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

Приведу свежий пример. Мы выкатили небольшую фичу на HeadHunter, когда ваши навыки может подтверждать любой - поставил вам плюсик, и появится надпись, что столько-то человек подтвердило ваш навык. У меня Scrum подтвердило 18 человек. Мы специально запустили это в очень простом виде, чтобы посмотреть, как к этому отнесутся пользователи. Мы исходили из логики, что будет взаимодействие а-ля LinkedIn или Хабр, где пользователи друг друга плюсуют. Сняли статистику, и оказалось, что у нас эти плюсики ставят, вероятно, после собеседований HR. То есть дальше мы можем развивать эту фичу в сторону HR, либо как-то ее модифицировать, чтобы она была более полезна соискателям. Таким образом, в Agile существует четыре ценности:

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

12 принципов Agile

Ценности влекут за собой 12 принципов Agile:

1. Наивысшая ценность - это удовлетворение потребностей заказчика благодаря регулярной и максимально ранней поставке ценного для него ПО. Если заказчик хочет получить от нас большого слона, но мы можем дать ему часть этого слона не через год, а через три месяца, потом еще через три месяца еще одну часть, а затее ежемесячно выдавать кусочки, то чем чаще мы это будем делать и чем раньше, тем лучше.
2. Мы всегда готовы изменять требования, даже на поздних стадиях проекта, если узнаем что-то новое. Таким образом, мы создаем бизнесу или внешнему заказчику конкурентное преимущество. Допустим, работают две компании: одна написала ТЗ и за год сделала продукт, а мы сделали концепцию продукта (неважно, в каком виде) и постепенно его выкатываем и раскатываем. Тогда наш продукт будет больше соответствовать требованиям заказчиков, пользователей и рынка в целом.
3. При использовании Agile работающий продукт выпускают максимально часто. В манифесте прописаны сроки - от пары недель до пары месяцев. На самом деле это неделя/месяц, если вы используете Scrum. В России чаще всего каждые две недели выпускается что-то новое. А если делают какой-то веб-проект, то обычно используют одну из вариаций Kanban, значит, релизы можно делать каждый день. В HeadHunter обычно ежедневно выходит несколько релизов, что создает большие проблемы для наших конкурентов. Это могут быть правки багов, но мы умеем добавлять что-то ценное для наших пользователей.
4. Бизнес обязательно должен работать вместе с программистами, помогать им понять специфику данного рынка. Например, программисты в HeadHunter должны понимать, как работает HR, и как соискатели ищут работу. Если вы работаете в банке, то вам требуется понимание принципа работы банка в целом и очень подробные сведения о той сфере, за которую вы отвечаете. Наиболее частой проблемой, по моему опыту, является недоступность бизнеса - когда разработчик не может получить у сотрудника нужную информацию. При использовании Agile важно избегать возникновения подобных ситуаций.
5. Команда - один из краеугольных камней Agile. Наилучших результатов достигает команда замотивированных профессионалов. Есть гениальное замечание о том, что эффективность Scrum зависит от руководителя. В Agile руководитель прежде всего должен создавать условия для команды и обеспечивать всестороннюю поддержку, проводить коучинг, следить за атмосферой в коллективе.
6. Есть много исследований, которые показывают, что лучшее общение - лицом к лицу. Причем желательно, чтобы было какое-то средство визуализации, на котором можно писать: лист бумаги, доска со стикерами и т.д. Самый простой и эффективный способ узнать требования клиента, заказчика или пользователя - поговорить с ними.
7. Работающий продукт. Про него повторяться не буду. Степень готовности проекта должна измеряться не словами, о том, что ТЗ уже написано и 50% макетов нарисовано, а количеством функционала, выпущенного в production.
8. В Agile важен ритм, постоянные улучшения. Бизнес и программисты всегда должны иметь возможность делать процесс устойчивым, постоянно его улучшать.
9. Про этот пункт менеджеры обычно не любят говорить разработчикам, но Agile вообще не будет работать, если вы написали быдло-код. У вас должна быть хорошая гибкая архитектура, в которую можно добавлять разные элементы и при необходимости легко их изменять. И если команда не будет уделять максимум внимания техническому качеству (писать хороший код, использовать инженерные практики, автоматизировать процессы), то никакого Agile у вас не будет.
10. Простота. Она проявляется в технической составляющей, в дизайне. Это один из принципов экстремального программирования. Простота очень важна также с точки зрения выпуска продукта: когда вы хотите «нарезать» того «слона», лучше начать с простой части.
11. Менеджер (руководитель, Scrum-коуч, Agile-коуч) в команде меняет свою роль: он не столько занимается организацией процесса, сколько учит команду, поэтому команда должна быть самоорганизованной. Есть специальные стратегии, как из группы людей сделать самоорганизованную команду.
12. Команда должна постоянно анализировать свою работу, процессы: что получилось, как они этого добились, и постоянно улучшать организацию работ.

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

Итак, у нас получается пирамида, состоящая из четырех ценностей, на которых выстроено 12 принципов. Теперь появляются конкретные практики.

Практики

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

1. На первом месте стендапы . В России, даже если компания полностью зафейлила внедрение, использование и адаптацию Agile, обычно все равно остаются стендапы. Если у вас не получается их использовать, значит, у вас совсем не организованная команда. Практика простая: каждый день в определенное время команда собирается и синхронизирует свою деятельность.
2. На втором месте планирование итераций , когда команда планирует объем работ на ближайшую итерацию. Это к вопросу о том, что в Agile нет планирования. Если у нас итерация идет две недели, то мы пытаемся сделать план, декомпозицию, может быть, разбить бизнес-задачи на задачи технические.
3. Unit-тестирование - одна из самых простых инженерных практик, которую можно достаточно быстро начать использовать. При наличии проблем с качеством порядка 60-70% багов можно отловить unit-тестированием.
4. Планирование релизов . Здесь мы уже планируем большими кусками - что и когда выпустим. Если речь идет о Scrum, то измеряем большими мазками, в спринтах.

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

Нам надо дойти из точки А в точку Б. «Дойти» - означает «получить обратную связь». Допустим, у меня есть GPS, я могу дойти до какой-то точки и свериться, правильно ли я дошел. Водопадная модель - фактически, один большой шаг. То есть я куда-то пришел, выпустил на рынок продукт, и только после этого могу понять, то ли я сделал. Итеративная модель - это серия шагов. Я делаю первый шаг, снимаю метрики, что у меня используется в продукте, затем корректирую дальнейшие шаги. Пусть я приду не в точку Б, но окажусь в ее окрестностях.

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

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

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

Если вы работаете по «водопаду», то обычно у вас фиксировано содержание проекта. Вам говорят: «Хочу, чтобы вы сделали это. Я точно знаю, чего хочу я и мои пользователи. Оцените, сколько человек вам для этого нужно и сколько времени на это уйдет». В Agile мы действуем по-другому: у нас есть команда и фиксированные отрезки времени (я говорю про Scrum), например, двухнедельные итерации. Исходя из этого, мы планируем объем работ, который мы можем выполнить за это время.

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

Scrum

У Хенрика Книберга есть такая метафора - Agile-зонтик. Это те методологии, которые являются гибкими. Самая большая - Scrum, экстремальное программирование (XP), DSDM, Crystal, FDD, Kanban. Более половины компаний, применяющих Agile, используют Scrum. На втором месте комбинация Scrum и XP, когда берутся управленческие практики из Scrum и добавляются инженерные. Отдельно отмечу, что комбинация Scrum и Kanban используется примерно в 8% компаний. Сейчас это один из трендов, мода. Название Scrum пришло из регби и переводится как «схватка». Проще говоря, при возникновении спорной ситуации команды выстраиваются, вбрасывается мячик, и нужно друг друга перетолкать. К разработке продукции этот термин впервые применили в 1980-х годах два японца - Хиротака Такэути и Икудзиро Нонака. Это хорошие исследователи в области менеджмента. В частности, они написали документ «The New New Product Development Game». Здесь употребление слова «new» 2 раза не является ошибкой. Просто название переводится как «Новая игра для разработки новых продуктов». Что сделали эти два японца? Они проанализировали, как различные компании создают свои продукты. Причем даже не ПО, а всевозможную технику и электронику. Авторы разделили выявленные подходы на три типа.

• Первый тип (A): у нас есть фаза разработки, все жестко, последовательно и хорошо.
• Второй тип (B): связи пересекаются, есть возможность получить обратную связь. Я запрограммировал что-то, программирую еще, отдаю тестировщику, он дает свои комментарии, я успеваю их обработать до завершения своей работы.
• Третий тип: каждая фаза пересекается более чем с одной другой фазой. Я программирую еще что-то, а мои первые задачи тестируются, выкладываются в production, с них снимаются метрики, я могу внести изменения.

Тип C двое японцев сравнили с ситуацией в регби. Почему? Смысл игры в том, чтобы взять мяч и донести его до линии поля противника, преодолевая сопротивление. Но в регби нельзя кидать мяч вперед. Когда ты бежишь и понимаешь, что сейчас тебя положат наземь, то мяч можно отдать назад члену своей команды. Он его ловит и бежит дальше. Если не может преодолеть сопротивление, то бежит назад.

Современный Scrum создан двумя айтишниками - Кеном Швабером и Джефом Сазерлендом. На официальном сайте www.scrumguides.org вы можете ознакомиться с официальным описанием Scrum. Так выглядит общая схема Scrum:

Итак, мы хотим делать какой-то продукт. Он разрезан на отдельные кусочки, которые называются бэклогом (backlog) продукта. Это требование. То есть у нас нет технического задания или какого-то обширного документа, который все заранее описывает. Обычно чем важнее какие-то требования, тем качественнее они разбиты и описаны. Этим занимается владелец продукта (product owner).

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

Компоненты Scrum

Роли
Scrum-команда состоит из команды разработки, владельца продукта и Scrum-мастера.

• Почему мы говорим, что Scrum - это гибкий Agile-фреймворк? Потому что он напрямую реализует ценности и принципы, описанные в начале публикации. Команда в Scrum должна быть самоорганизующейся, а Scrum-мастер помогает ей такой стать, учит, как можно быстрее и качественнее из элементов бэклога создать инкремент продукта - новую версию софта. Scrum-мастер отвечает за то, чтобы все процессы работали, чтобы участники понимали, зачем и как это делается.
• Владелец продукта, product manager - человек, ответственный за максимизацию ценности продукта, он отвечает за продукт (например, Стив Джобс).
• Команда разработки должна состоять из мотивированных профессионалов, которые могут в течение каждого спринта делать поставку, то есть на основании требований создавать готовый продукт.

Процессы

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

Бэклог спринта - верхняя часть бэклога. Количество элементов обычно определяется скоростью команды на мероприятии, которое называется «планирование спринта», и проводится перед началом самого этапа спринта. Спринт длится 1-4 недели (чаще всего 2 недели). Чем быстрее и дешевле можно релизить, тем меньше продолжительность данного этапа.

Каждый день команда проводит 15-минутный стендап, Scrum-митинг, на котором все члены команды синхронизируют свои действия. Зачастую эти встречи называют просто «скрамами».

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

Артефакты
Это могут быть карточки на доске с кратким описанием, что собой представляет конкретный функционал. При этом содержание карточки может представлять собой обсуждения с владельцем продукта. Обычно это выливается в тикеты в трекере, который вы используйте - JIRA, Redmine и т.д.

• Бэклог продукта - это все тикеты, карточки или иные требования в виде элементов бэклога, которые есть в вашем продукте.
• Бэклог спринта - самые ценные и приоритетные требования.

Примеры Scrum-практик: оценки

Здесь не будет канонического/кошерного/ванильного Scrum"а, который описан Швабером и Сазерлендом, и про который можно почитать здесь: www.scrumguides.org . Расскажу о реальных практиках, используемых командами. Есть тяжеловесные, якобы точные методы все «правильно» посчитать и сделать. Но практически все большие проекты выбиваются из сроков. И это касается не только IT. Например, был случай, когда аэропорт не могли запустить в эксплуатацию из-за того, что не был готов софт, отвечающий за автоматическое распределение багажа. Если вы используете гибкие методологии, а также то, о чем я сейчас расскажу, то можете спокойно запускать проекты, без геройства. Один из наших больших проектов, который закончился в сентябре, фактически был готов на production за две недели до официального запуска. Я много наблюдал, как команда, тимлиды и менеджеры пытаются предсказать, когда у них будет готов проект. Это примерно то же самое, что подойти к команде и попросить назвать случайное число.

Agile и Scrum предлагают использовать такую практику: делать относительные оценки, то есть «измерять в попугаях». Это значит, что я оцениваю время, которое у меня уйдет на решение задачи, и сколько она займет попугаев. Их обычно называют story point. Эти story point лучше не привязывать ни к каким временным промежуткам. Каким образом делать такую оценку, почему она называется относительной? Обычно берут какую-то задачу, небольшую, стандартную и понятную всем, и объявляют ее мерой, эталоном - она занимает 1 попугай, 1 story point. Берется следующая задача, сравнивается с первой - она оказывается в 2 раза больше. Сколько она занимает? 2 story point. И таким образом мы раскладываем все задачи. В итоге мы не оцениваем каждую задачу по времени, а сравниваем их между собой. Если где-то ошибаемся, то это нормально. Главное, чтобы во всех задачах ошибались одинаково. Оценка делается командой и в рамках команды.

Что мы можем сделать после этого? Например, запустить двухнедельный спринт и взять верхние задачи без каких-то оценок. Когда спринт закончится, на выходе получим инкремент продукта, в который будет включено какое-то количество задач. Посчитаем, сколько story point мы сделали, и на следующий спринт просто можем планировать такое же количество story point. Подобная оценка получается относительной и эмпирической. Мы не предполагаем, как любят делать управленцы, что программист Вася работает 8 часов и с одинаковой эффективностью, а реально измеряем, сколько команда может проживать story point за спринт. Шкала оценок обычно подбирается так, чтобы различать задачи разных классов.

Если приглядеться, то похоже на числа Фибоначчи, либо на степени двойки. При этом оцениваются обычно действительно большие задачи, которые дальше разбиваются на более мелкие. Для формирования оценок обычно используется покер-планирование. Это модификация метода Delphi. Каждому члену команды дается колода карточек с числами от 0 до 100. Есть еще карточка с надписью «Я не понимаю, что это за задача» и карточка с кофе («Давайте сделаем перерыв, я уже замучился заниматься этой оценкой»). После этого берем задачу номер такой-то, читаем и обсуждаем, что она собой представляет: «Пользователь вводит логин-пароль для того, чтобы авторизоваться на сайте». Обсуждаем, как эта авторизация происходит, где мы храним пользователей. Затем каждый член команды рубашкой вверх кладет карту с оценкой, которую считает нужной. При этом разные члены команды друг на друга никак не влияют, потому что обычно в команде есть тимлид, ведущий, старший разработчик, на которого равняется большинство. После этого происходит вскрытие карт и обсуждение.

Согласно методу Delphi, обсуждение происходит между теми, кто поставил наибольшую и наименьшую оценки. Поставивший наибольшую обычно видит какие-то риски, которые не заметили другие члены команды. Он скажет: «Вы знаете, в эту базу, где у нас хранятся логины и пароли, мы давно не заходили. Там надо что-то отрефакторить, добавить колонку, применить другой хэш» и т.д. А человек, поставивший наименьшую оценку, либо не понимает задачу, либо видит способ сделать быстрее, либо уже делал что-то подобное. После этого происходит второй этап обсуждения: опять все кладут карточки рубашками вверх, потом вскрывают их. Обычно оценки более-менее сглаживаются. Снова проходит этап обсуждения, приходят к консенсусу. В результате записывается в трекер, в тикет-систему, либо прямо на карточку, что у нас эта задача на 3 story point.

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

Что делать в том случае, если заказчик хочет понять, сколько времени займет реализация проекта и просит сразу дать ему оценку? Идеальный вариант - работать с заказчиком по системе «время - материалы». Если заказчик новый, то можно один проект сделать по Fixed Price, убедиться, что заказчик адекватный, и дальше придерживаться системы «время - материалы». Если заказчик не соглашается сразу на данную систему, то можно ее скорректировать: например, если вы заканчиваете проект к определенной дате, то получаете какой-то бонус. На эту тему в сети тоже есть презентации.

Примеры Scrum-практик: скорость команды

Мы берем каждый спринт, измеряем, сколько story point сделали. И если нам надо спланировать девятый спринт, то просто берем среднее значение из предыдущих спринтов. Это называется «принцип вчерашней погоды». Здесь важно то, что мы набираем наиболее важные или ценные задачи исходя из скорости команды.

Если какая-то задача не помещается по размеру, то ее можно разбить на более мелкие, либо пометить, что она не войдет, либо отказаться от ее решения. Надо понимать, что скорость не будет равномерной. Люди работают с переменной интенсивностью, кто-то заболевает, кто-то работает медленнее из-за проблем дома, кому-то надо срочно пообщаться в соцсети, кто-то взял отпуск. Всегда нужно прямо и однозначно говорить владельцу продукта: «У нас есть задачи A, B, C, мы их точно успеем сделать, они попадают в нашу самую низкую скорость. Есть также задача D, которую мы, скорее всего, успеем сделать. Но есть и задача F, которая может выпасть». Кажется, что это неточность, и владелец скажет: «Вы что? Надо все успеть». На самом деле, когда вы ему говорите точно, что самые важные задачи будут сделаны, то это увеличивает доверие между вами и владельцем продукта или заказчиком, и он для каждого спринта сможет выбирать самые важные задачи и гарантированно их получать.

Примеры Scrum-практик: путевой контроль

Как во время спринта контролировать, что у нас все идет хорошо? Мы спланировали спринт и начали его реализацию. Для контроля используется диаграмма сгорания Burn Down Charts.

По горизонтали отмечаем дни - это двухнедельный спринт, 10 рабочих дней. По вертикали с одной стороны отложены story point, с другой - истории пользователей или элементы бэклога. Если бы мы с вами были роботами, а задачи маленькими и разбитыми на кусочки, то мы шли бы по пунктирной линии - это линия идеального Burn Down Charts. Что эти линии означают? Верхняя - сколько мы сделали историй пользователей, нижняя - количество story point. Такие графики автоматически строятся во многих системах для трекинга задач.

Как их читать? Если ваш график находится над линией идеального Burn Down, то вы отстаете, медленно работаете. Тогда к концу спринта будет не ноль задачек или story point, а где-то 20-25. Можно в Excel построить тренд или регрессию и посмотреть, сколько у вас получится задач с такой скоростью - очень просто и наглядно. Если команда видит, что она идет поверх идеального Burn Down, то надо принимать меры. На практике обычно получается вот так.

Идут небольшие отставания, но это у хорошей команды. Другой вариант встречается реже, когда Burn Down ниже диагональной линии. Это означает, что вы идете с опережением, то есть, скорее всего, вы просто взяли мало задач.

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

Примеры Scrum-практик: доски задач

Обычно в Scrum используют доски задач, хотя они не являются обязательным элементом. Команда распределяет задачи по отдельным этапам и размещает на доске в виде отдельных карточек. Есть электронные реализации досок задач, плагины для JIRA и т.д. Задачи упорядочиваются по степени важности. Когда команда собирается с утра, обновляются статусы задач, их переносят на другие этапы, смотрят, есть ли где-то затыки.

Примеры Scrum-практик: обзор спринта

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

Примеры Scrum-практик: ретроспектива

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

Начинается ретроспектива с открытия. Обычно она занимает 5% времени. Задача - растормошить всех присутствующих на ретроспективе, потому что очень часто в командах, особенно айтишных, присутствуют не очень общительные люди, но порой имеющие блестящие мысли. Задача ведущего заключается в том, чтобы разговорить этих людей. Второй этап - сбор данных, он занимает до половины времени. Команда ищет какие-то факты. Их можно вспомнить, достать из трекера, распечатать. Также можно собрать статистику по багам, кто репортил, каков их статус - вариантов множество. После сбора фактов начинается мозговой штурм: нужно понять, в чем проблема, проникнуть в суть, сгенерить идеи, которые помогут ее решить. На это уходит до трети времени. Например, если у нас много мелких багов, возникающих не на уровне интеграции системы, а в коде разработчиков, то можно предложить использовать модульное тестирование. Если у нас очень плохое качество, как его улучшить? Можно попробовать парное программирование, какие-то инструменты, которые делают автоматизированную проверку кода, еще что-то. Обычно набирается 5-10 идей. Далее нужно воплотить эти идеи в жизнь. Мы не можем сразу внедрить code review, разработать какие-то инструменты. Поэтому выбирается максимум одна-две идеи, реализацию которых надо запланировать на следующий спринт. После этого благодарим всех и закрываем ретроспективу. А еще через две недели можно оценить, получилось у нас это или нет, изучить другие проблемы.

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

Есть такое понятие, как «Цикл Деминга». Он состоит из четырех этапов: Plan - Do - Check (Study) - Act.

• Планирование (Plan).
• Реализация (Do).
• Проверка (изучение) (Check (Study)).
• Изменение (Act).

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

После этого можем вносить изменения: например, хотели сделать покрытие 50% - сделали, количество багов уменьшилось, но они еще остались - давайте поднимем до 70%. Или сделали 70%, цикл прокрутили второй раз, проверяем - улучшилось. Давайте сделаем 90%. Еще раз прокрутили: количество багов не уменьшилось, а затрат на написание и поддержку тестов получается много. Давайте сделаем более слабую границу. Благодаря этому циклу команда постепенно улучшает какую-то часть процессов. Самый простой вариант ретроспективы - Real-Time Board Service.

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

Напоследок о Scrum

Надо сказать, что Scrum, как и все гибкие методологии, лучше работает в командах, которые сидят в одной комнате. Тем не менее в сети можно найти сотни презентаций о том, как применять гибкие методологии в распределенных командах, когда люди работают на удаленке. Здесь идея такая: вместо реального общения максимально использовать программные и аппаратные инструменты. Что обычно используют? Во-первых, общий трекер, что-то типа JIRA. Это действительно помогает. Популярны программистские чаты, например, HipChat. Для общения - Skype, Hangout. Главное, чтобы была видеосвязь, и чтобы можно было демонстрировать экраны своих компьютеров.

Kanban

Это вторая по популярности методика. Ряд компаний работают одновременно по Scrum и Kanban, получается Scrumban. Наверное, это один из будущих трендов. Историческая справка: Kanban появился в Японии. Этим словом называлась бумажка с пул-запросом на какие-то действия. Например, мне нужна какая-то деталь, на нее делается отдельный канбан. Но в IT это все-таки применяется немножко в другом виде.

Ценности и принципы

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

• Начинаем с того, что есть сейчас, и дальше путем эволюции и постепенных изменений делаем из этого непонятного хаоса четко настроенную Kanban-систему. При этом стараемся только эволюционно изменять роли, зоны ответственности и обязанности. Поощряем инициативные действия на всех уровнях организации. Главная практика - визуализация, обычно в виде доски. Работа каждого члена команды должна быть визуализирована, видна всем.
• Количество работы в каждом процессе ограничивается. То есть в работе одновременно может быть не более какого-то количества задач. Это нужно для исключения мультитаскинга, который убивает эффективность. К тому же это дает определенные инструменты управления потоком задач.
• Все правила должны быть явными. Необходимо дать определение завершенности. Например, задача выполнена, если написан код, есть unit-тесты с покрытием 70%, и т.д.
• Необходимо делать улучшения с помощью постоянных экспериментов, используя модели и научный подход, в том числе цикл Деминга.

Визуализация

Обычно используется та же самая доска, что и в Scrum. Самый простой вариант - прото-Kanban. Поток задач разбивается на отдельные этапы. Что-то находится в плане, что-то в аналитике, что-то в разработке, что-то в тестировании, что-то мы уже сделали. При этом реализуется принцип ограничения количества одновременно находящихся в работе задач - WIP (Work in Progress). Есть формула Литтла, которая связывает скорость прохождения задачи в такой системе и количество одновременных задач. Чем меньше WIP, тем быстрее задачи проходят цепочку. Допустим, у нас завал в тестировании, а разработчик сделал следующую задачу. Он видит, что у тестировщиков проблема. Тогда разработчик помогает им что-то сделать, или они идут к руководителю и говорят: «Нам нужен еще тестировщик».

Обычно команда начинает с большого ограничения задач в работе, например, не более двух задач на человека. Если у меня один тестировщик - две задачи для разработки, если четыре тестировщика - восемь задач. Постепенно общее количество задач уменьшается, скорость работы возрастает. И доска уже выглядит примерно так.

Здесь есть те же самые WIP, внизу - критерии готовности (Definition of Done). Столбец делят на две части: «в работе» и «выполненное». Иногда доску делят на дорожки и размещают WIP по горизонтали. Это уже более продвинутая, полноценная Kanban-система. Каждая дорожка соответствует определенному классу обслуживания. Например, есть горячие задачи, когда к вам прибегает начальник и говорит: «Надо сделать это быстрее». Это отдельный класс обслуживания, под него стоит забронировать WIP.

Как и в Scrum, здесь тоже можно создавать диаграммы. Обычно их называют «Диаграммы кумулятивного потока». По горизонтали отмечено время, по вертикали - количество задач. Разными цветами показаны разные этапы. Я упоминал, что улучшение нужно осуществлять на основе цифр, используя научный подход. Эти цифры можно извлечь из диаграмм. Самые важные из них - WIP, то есть количество задач за исключением запланированных и выполненных. Мы его должны сокращать.

Вторые важные критерии - Cycle Time и Lead Time. Определения бывают разными, нужно очень внимательно смотреть. Эти два числа показывают, насколько быстро задачи проходят через вашу Kanban-систему.

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

Итог

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

• «Scrum и XP: заметки с передовой». Автор - Хенрик Книберг, Agile-коуч из компании Spotify. Книга полностью бесплатна и на русском языке. Ее минус - она очень старая. Ее большой плюс - в ней разобрано много инструментов, приведены конкретные ситуации в виде диалогов. Книгу очень любят практики, и для многих, в том числе для меня, это была первая книжка на тему Scrum и Agile. Также в ней описаны элементы экстремального программирования.
• «Scrum и Kanban: выжимаем максимум». Тоже на русском и бесплатная. Можно сказать, что это книга про Scrumban.
• На мой взгляд, лучшей книжкой по Scrum является «Scrum: гибкая разработка ПО» Майка Кона. В ней очень подробно расписано, как внедрить Scrum, кем должны стать менеджеры, архитекторы. Самая подробная книга на эту тему.
• И такая каноническая книга по Kanban Дэвида Андерсона - «Kanban: Successful Evolutionary Change for Your Technology Business». В следующем году выйдет обновленная версия.
• Моя книга «