Инструменты agile. Что такое Agile-подход и зачем он нужен бизнесу? Гибкие методологии в сравнении с традиционным подходом к управлению проектами

Для начала. Scrum и Agile - в чем разница? Если коротко, Agile - это философия, семейство гибких подходов к разработке ПО. Scrum - один из таких подходов. У него есть братик - Kanban. Он тоже подход, используемый в Agile.

Елена Трускова рассказывает:

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

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

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

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

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

Эджайл

(англ.agile -«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» - и эти принципы станут близкими и понятными.

«Работающий продукт - основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» - правда, звучит разумно?

Скрам

(англ. scrum - толкотня в борьбе за мячик в регби)

Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.

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

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

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

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

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

Команда в скраме

Стандартный размер скрам-команды - 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама - команда.

В каждой команде есть:

• участники (в случае IT - разработчики, кто эти семь человек у вас - решите сами)
• продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
• скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
  Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

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

Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.

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

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

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

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

Структура спринта

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

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

• что я сделал вчера
• что я сделаю сегодня
• что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) - что мы делали не самым лучшим образом весь спринт и хотим улучшить далее - о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

• В 1991 году появился метод быстрой разработки приложений RAD
• В 1994 году появился метод разработки динамических систем DSDM
• В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
• В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
• В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

Манифест, созданный программистами, включает в себя 4 базовых идеи и 12 принципов эффективного управления проектами. Любая из систем управления проектами на основе Эджайл (о системах мы поговорим позже) опирается именно на эти идеи и принципы, хотя и использует их в разных вариациях.

1. Люди и их взаимодействие важнее, чем процессы и инструменты
2. Рабочее ПО важнее, чем документация
3. Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
4. Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

1. Удовлетворять клиентов, заблаговременно и постоянно поставляя ПО (клиенты довольны, когда рабочее ПО поступает к ним регулярно и через одинаковые промежутки времени)
2. Изменять требования к конечному продукту в течение всего цикла его разработки
3. Поставлять рабочее ПО как можно чаще (раз в неделю, в две недели, в месяц и т.д.)
4. Поддерживать сотрудничество между разработчиками и заказчиком в течение всего цикла разработки
5. Поддерживать и мотивировать всех, кто вовлечен в проект (если , она намного лучше справляется со своими задачами, нежели команда, члены которой условиями труда недовольны)
6. Обеспечивать непосредственное взаимодействие между разработчиками (возможность прямого контакта способствует более успешной коммуникации)
7. Измерять прогресс только посредством рабочего ПО (клиенты должны получать только функциональное и рабочее программное обеспечение)
8. Поддерживать непрерывный темп работы (команда должна выработать оптимальную и поддерживаемую скорость работы)
9. Уделять внимание дизайну и техническим деталям (благодаря эффективным навыкам и хорошему дизайну команда проекта получает возможность постоянного совершенствования продукта и работы над его улучшением)
10. Стараться сделать рабочий процесс максимально простым, а ПО – простым и понятным
11. Позволять членам команды (если разработчики могут сами принимать решения, самоорганизовываться и общаться с другими членами коллектива, обмениваясь с ними идеями, вероятность создания качественного продукта существенно возрастает)
12. Постоянно адаптироваться к меняющейся среде (благодаря этому конченый продукт будет более конкурентоспособен)

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

• Что я делал вчера?
• Чем я буду занят сегодня?
• Что мешает мне работать?

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

1. Четко обозначается значение проекта
2. В процессе реализации активно участвует клиент
3. Общий объем работ выполняется пошагово
4. Ориентироваться следует на конкретный результат
5. Численность одной рабочей группы: от 7 до 9 человек

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

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что этоJ).

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

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

Существует немало методов проект-менеджмента, которые применяются разными современными компаниями. Но самыми известными и востребованными среди них по праву считаются Scrum (Скрам) и Kanban (Канбан).

Метод Scrum

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

Метод заключается в том, что разработка проекта разделяется на спринты, по окончании которых клиент получает улучшенное ПО. Спринты строго фиксируются по времени, и могут длиться от 2 до 4 недель. Рабочий процесс в одном спринте включает в себя несколько стадий:

• Определяются объемы работы
• Каждый день проводятся 15-минутные встречи, чтобы члены команды могли скорректировать свою работу и подвести промежуточные итоги
• Демонстрируются полученные результаты
• Спринты обсуждаются для поиска удачных и неудачных решений и действий

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

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

Метод Kanban

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

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

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

Это лишь примеры основных методов управления проектами, основанных на Agile. Но не стоит пренебрегать и другими методами, такими как PRINCE2, Lean, Six Sigma, XP, CCPM, ECM, Waterfall и другие. К тому же у Аджайл, наряду с преимуществами, есть и некоторые недостатки.

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

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

• Перевод

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
- закон Хофштадтера

Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут - лучшее что я видел. TED отдыхает.

Роли

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

Это заинтересованные лица . Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.

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

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

Это команда разработчиков . Те, кто будет строить рабочую систему.

Пропускная способность

Так как команда использует гибкую методологию разработки , они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность . Ее очень просто измерить - количество пользовательских историй за 7 дней.

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

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

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

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

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

Kanban рекомендует ограничиться несколькими задачами - WIP limit. Допустим команда решает, что 5 - это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем - это слово “нет”

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

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

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи - вот что помогает Пэт расставлять приоритеты.

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

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

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

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

Владелец ИТ-продукта должен постоянно со всеми общаться

Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

В идеале - все три одновременно, но в реальности приходится выбирать.

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

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

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

Между ролями в Scrum существует здоровое противостояние

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

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

Компромисс между разработкой нового продукта и улучшением старого

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

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.

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

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ - в апреле или мае.

Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.

Заинтересованное лицо спрашивает:«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

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

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

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

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

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

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

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

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

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

Делай сразу!

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

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

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

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

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

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

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

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

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

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

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

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

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

Система работы завода «Тойота» уже стала классической и успешной менеджмент-моделью. У каждого работника предприятия была возможность в любое время остановить конвейер в целях устранения дефекта, неполадки или внесения своего рационализаторского предложения. Именно на таком подходе основана философия 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.