Agile методы разработки по doc. Agile методология разработки. Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

Не потеряйте. Подпишитесь и получите ссылку на статью себе на почту.

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

Однако существенно упростить работу над проектом и научиться им управлять, тем самым повысив эффективность команды, можно при помощи системы гибкого управления проектами под названием 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-компания), «Сбербанк» (наверное, знаете, что это).

Эти и многие другие организации используют в работе самые разные методы управления проектами, основанные на 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 может стать в этом деле верным помощником.

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

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

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

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

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

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

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

Делай сразу!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое Agile Methodology (гибкая методология)?

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

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

12 принципов, которые составляют Agile Methodology, можно поделить на 4 главные идеи:

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

Методы присутствующие в Agile:

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

Метод успешно применяют такие компании как Microsoft, Yahoo, Siemens Healthcare, а проектный менеджер в Amazon даже описал на основе полученного опыта.

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

Джефф Сазерленд, автор выделил 8 шагов по использованию методики:

1. Выберите владельца продукта — он знает о цели проекта и ожидаемом результате.
2. Соберите команду — до 10 человек с необходимыми для создания работоспособного продукта навыками.
3. Найдите скрам-мастера — он следит за ходом проекта, помогает проектной команде бороться с трудностями.
4. Составьте бэклог продукта — на Agile-доске расставьте приоритеты по каждому требованию к продукту. В этом большую роль играет владелец продукта, который собирает пожелания к продукту для оценки командой бэклога.
5. Запланируйте спринты (итерации) — отрезки времени на выполнение определенного ряда задач.
6. Организовывайте ежедневные пятнадцатиминутные «мит-апы» — задавайте по 3 вопроса каждому из команды: что делал вчера, что будет сегодня, что мешает выполнить задачу.
7. Делайте обзоры рабочих частей продукта — с вовлечением в просмотр и обсуждение стейкхолдеров.
8. Проводите ретроспективу — обсуждение проблемы и поиск решения после каждого спринта. Полученный план изменения внедряете на следующем спринте.

Ретроспектива в Agile

В скрам есть 4 ключевых элемента:

• Product Backlog — список требований по проекту
• Sprint Backlog — список требований, которые нужно выполнить в ближайший спринт
• Sprint Goal — цель спринта
• Sprint Burndown Chart — диаграмма, которая обновляется по мере завершения задач. По ней легко понять динамику и уровень продвижения команды в проекте.

(XP)

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

Он применим исключительно в сфере разработки ПО, и строится вокруг 4 процессов:

1. кодирование — согласно единым в команде стандартам оформления;
2. тестирование — тесты пишутся самими программистами до написания кода, который будут тестировать;
3. планирование — как финального билда, так и отдельных итераций. Последнее проходит в среднем раз в две недели.
4. слушание — как разработчиков, так и клиента, в ходе которого исчезают неясности, определяются требования и ценности.

Methodologies

Малоизвестное на отечественных просторах проектного менеджмента семейство методологий, разработанное Алистером Кокберном, одним из автором «Манифеста гибкой разработки ПО». Классификацию Кокберн предлагает проводить по цветам за критерием количества человек в команде: от 2 (Crystal Clear) до 100 (Crystal Red). Под более масштабные проекты выделены цвета Maroon, Blue и Violet.

Crystal-проекты должны соответствовать 3 основным показателям:

1. быстрая доставка рабочего кода — развитие идеи итеративной модели разработки Agile.
2. совершенство через рефлексию — новая версия ПО улучшается на основе данных о предыдущей.
3. «осмотическое» взаимодействие — нововведение Алистера, метафора коммуникации и обмена информацией между разработчиками ПО в одной комнате.

Dynamic Software Development Method (DSDM)

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

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

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

DSDM делится на версии, которые обновляются по мере развития технологий, появления новых требований к разработке ПО. Последняя на сегодня — DSDM Atern, выпущенная в 2007 году, хотя предыдущая (2003 года) еще в строю.

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

1. цикл функциональной модели — создание аналитической документации и прототипов.
2. цикл проектирования и конструирования — приведение системы в рабочее состояние.
3. цикл реализации — развертывание системы.

Feature Driven Development (FDD)

Методология, которая появилась даже раньше, чем "Манифест гибкой разработки ПО«.

Хоть в FDD тоже применяется итерационная модель разработки, от Agile она отличается в следующем:

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

Feature Driven Development состоит из таких цикличных этапов:

1. Создание общей модели — видение проекта на основе предварительных данных.
2. Разработка списка свойств — аналог product backlog в методике скрам.
3. Планирование по свойствам — оценка сложности свойств каждым членом команды.
4. По каждому свойству — технический дизайн и реализация — финальная стадия, по окончанию которой свойство уходит в продукт и цикл повторяется.

Software Development

Lean Software Development — скорее не методология, а набор принципов бережливого производства, который направлен на повышение эффективности процесса разработки, минимизацию затрат.

В набор входят следующие 7 принципов:

1. избавление от потерь — всё, что не прибавляет ценности продукту для конечного потребителя.
2. постоянное обучение — непрерывное развитие команды увеличивает возможности эффективного выполнения задач.
3. принятие решения так поздно, как только можно — приоритет не спонтанным решениям, а продуманным, разработанным на основе полученных знаний.
4. быстрая доставка — по сути основа итеративной модели.
5. усиление команды — один из принципов «Манифеста...» гласит, что люди и взаимодействие важнее процессов и инструментов. Проектная команда — основа успешного завершения задач.
6. целостность и качество — нужно изначально делать качественный продукт, чтобы не тратить время и ресурсы на дальнейшее тестирование и избавление от багов.
7. видение цельной картины — разбиение проекта на отдельные части невозможно без понимания текущего статуса разработки, целей, концепции и стратегии разрабатываемого ПО.

Разновидность методологий гибкой разработки

Agile Modeling (AM)

Agile Modeling — набор ценностей, принципов и практик для моделирования программного обеспечения.

AM используют как составляющую полноценной методики разработки ПО — например, экстремального программирования или Rapid Application Development.

Принципы Agile Modeling таковы:

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

Agile Unified Process (AUP)

AUP — упрощённая версия другой методологии разработки ПО — Rational Unified Process (RUP). С 2012 года её заменили на Disciplined Agile Delivery (DAD), но кое-где AUP еще встречается.

Автор методики, Скотт Амблер, выделил следующие ключевые позиции Agile Unified Process:

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

Agile Data Method (ADM)

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

Суть Agile Data Method определяется шестью положениями:

1. Данные — основа создания любого приложения.
2. Проблемы с проектом — их можно обнаружить только при чётком понимании цели и концепции проекта.
3. Рабочие группы — помимо непосредственной команды разработчиков есть enterprise groups, которые поддерживают другие рабочие группы.
4. Уникальность — нет идеальной методики, под каждый проект нужно комбинировать инструменты с разных методологий.
5. Работа в команде — совместная работа гораздо эффективнее, чем поодиночке.
6. «Сладкое пятно» — поиск оптимального решения проблемы («сладкого пятна»), избегая крайностей.

Essential Unified Process (EssUP)

Разработка шведского учёного Ивара Якобсона, созданная для улучшения Rational Unified Process.

EssUP оперирует понятием практики, в которые входят:

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

Все практики в том или ином виде встречаются в методологиях RUP, CMMI и гибкой методике разработки.

Getting Real (GR)

Эффективная для стартапов и начинающих команд методология, которая предлагает по максимуму использовать особенности небольших проектов и компаний: мобильность, гибкость, поиск новых решений, отсутствие жёсткой запутанной иерархии и т.д. Джейсон Фрид и Давид Ханссон, основатели компании 37signals (теперь — Basecamp), определили Getting Real как систему для решения реальных задач: максимально простую, понятную и функциональную.

GR — сборная солянка из десятка инструментов гибкой разработки, которые используются для минимизации:

• возможностей
• опций и настроек
• структуры компании
• встреч
• обещаний.

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

OpenUP (OUP)

Независимая от инструментов методология разработки ПО без жесткой структуры, которая содержит такие практики:

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

Практики реализуются на основе четырех принципов:

Agile показатели

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

Для большинства проектов хватит 4 направлений метрик:

1. Производительность — сюда относятся Velocity и WIP. Первая подойдёт не для всех проектов, так как идет измеряются количество выполненных задач в итерацию, а они неравнозначны. Метрика Work-in-Progress определяет лимит задач на разных стадиях: и чем он выше, тем хуже;
2. Прогнозирование — метрика capacity: определение количества идеальных часов, доступных в следующем спринте. Соответственно, можно понять, сколько времени есть на работу, насколько эффективно выполнение задач и как для спринта;
3. Качество — например, индекс стабильности требований, который рассчитывается по формуле = (Общее количество оригинальных бизнес-требований + Число требований, которые поменялись к этому времени + Число добавленных требований + Число убранных требований) / (общее число оригинальных требований). С помощью метрики определяется количество времени, затраченное на переделывание задач;
4. Ценности — в каждом случае просчитывается индивидуально, зависимо от формата проекта. Например, стартап AirBnb в качестве метрики, определяющую конечную ценность продукта для пользователей, выбрала количество загруженных фотографий высокого качества. С их увеличением пропорционально росло и количество потребителей.

К метрикам применимы те же правила, что и к другим Agile-инструментам.

Нет единственно верной или нужной вашему проекту метрики.

Их нужно постоянно пересматривать, отбрасывать устаревшие и добавлять новые по мере необходимости. Она должна быть понятна и доступна всей всей команде, не превращаться в самоцель. Метрика ради метрики — плохое решение.

Разрушители мифов: Agile

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

Миф № 1: Agile подойдет для всех проектов.

Самое упорное заблуждение. Ни один метод Agile не добавит сам по себе ценности продукту и не смотивирует команду.

Миф № 2: Agile против документации.

Гибкая методология разработки не против документации, она против документации как самоцели. А вот при выборе документации как средства коммуникации Agile действительно отдаёт приоритет живому общению.

Миф № 3: Agile и планирование несовместимы.

Опровержением этого мифа служат дневные планирования с 10-минутными стэндапами, итерационное планирование каждые две недели, спринт-встречи и т.д.

Миф № 4: Agile требует много переделывания (re-work).

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

Плюсы и минусы использования Agile

Плюсы:

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

Минусы:

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

Приложения

Для ведения проектов с Agile подходят далеко не все сервисы или программы для проектного менеджмента, ведь у каждого есть своя специфика.

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

Вот пара лайфхаков, чтобы настроить Agile в

1. настройте метки и статусы , которые необходимы для работы именно вашей компании.
   Статусы могут быть такими: в работе, проверка, выполнено, требует доработки, критично, фича, оплатить .
   Метки часто выглядят как: верстка, тестирование, продакшен, концепт, код.
2. создайте проект-беклог и проект-спринг.
3. создавайте задачи и предварительные чеклисты, скетчи и прочее в беклоге.
4. на мит-апах определяйте задачи на спринг и переносите их из беклога в спринт.
5. используйте гостевой доступ клиентов к задачам, чтобы всегда иметь согласованные и актуальные комментарии по проекту.
6. отмечайте ответственных в задачах , чтобы каждый коллега знал зону своей ответственности и чувствовал причастность к результату спринта.

Вердикт

С гибкой методологией разработки программного обеспечения небольшие проектные команды добиваются максимальной эффективности. Agile реализуется через другие гибкие методы: Scrum, XP, Lean и т.п.

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

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

Три объёма значения Agile

В первом, более узком значении, этот термин стал с начала 2000-х использоваться в сфере разработки программного обеспечения, когда в американском штате Юта, на горном курорте, собрались отраслевые специалисты, чтобы обсудить методики и практики создания программных продуктов, востребованных конечным потребителем. Результатом той встречи стал Манифест (Agile Manifesto) разработки программных продуктов, с 12-ю принципами, которые, в первую очередь, касались узкой сферы деятельности авторов, но потенциально могли быть распространены и на некоторые другие бизнес-проекты.

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

1. Работа над проектом ведётся итерациями – короткими циклами (спринтами). (В случае с разработкой программного обеспечения продолжительность этих циклов составляет от 1 недели до 1 месяца).
2. По завершении каждого цикла выходит продукт, который уже можно применять в бизнесе. Для программного обеспечения таким продуктом может стать приложение или только его часть, однако даже «сырой» софт уже можно и нужно пробовать в деле.
3. Продукт проверяется заказчиком или пользователями, которые поддерживают с разработчиками постоянную обратную связь. Клиентоориентированный подход применяется в течение всего проекта (всех итераций).
4. Любые замечания быстро включаются в доработку, а изменения, позволившие сразу по ходу подправить разработку продукта, – приветствуются, поскольку это позволяет не накапливать глобальные ошибки системы.

В третьем, ещё более широком значении, Agile – это часть модели управления, применяемого на заводах «Toyota» и теперь – одна из базовых составляющих менеджмента почти любого успешного производства. Основы Agile в этом контексте схожи с основами понимания технологии в других контекстах.

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

Принципы Agile-управления

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

1. Решающее значение для настройки продукта имеет потребитель и степень его вовлеченности в создание результата.
2. Для принятия решения команды должны быть высокоэффективными и сплочёнными.
3. Поэтапная и цикличная работа становится основой процесса. Проект делится на мелкие части, которые завершаются к определённому сроку до завершения проекта в целом.
4. Фокус оценки результативности направлен на частые представления промежуточных состояний проекта.
5. В работе коллектив опирается на закон Парето, по которому 20% усилий дают 80% эффективности, что позволяет не доводить каждый отдельный цикл до совершенства перед представлением результата потребителю. Продукт совершенствуется естественным образом с каждой новой итерацией.
6. Предполагается обязательное завершение одного этапа перед переходом к следующему.

«Гибкий» подход стал базовым для целого ряда методологических практик, которые отличаются между собой, но включают идеи Agile: Scrum, Kanban, Lean, Crystal и др. Методология Scrum, например, практически всегда рассматриваются в связке с Agile как единая система управления проектами по разработке программного обеспечения.

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

• Product backlog предполагает формирование списка требований, созданного по единому шаблону (User Story) и отсортированного по приоритетам. Если требований нет, проект завершается.
• Sprint backlog – это требования ближайшего спринта (этапа), разделённые на задачи без возможности добавлять новые требования в течение спринта. Обязательство на ближайший этап, взятые командой с типом управления Agile, записываются на доске (т. н. Kanban).
• Sprint Goal – общая цель спринта – ориентир при принятии альтернативных решений.
• Sprint Burndown Chart – «диаграмма сгорания». Она показывает насколько продвинулась команда в течение этапа.

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

Характерные ошибки внедрения Agile и недостатки подхода

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

К распространённым ошибкам внедрения относятся следующие:

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

18 Oct 2017

Если заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на "Как рассказать бабушке" или "Как рассказать дедушке" и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

"Что с этим нам делать то, у нас из программирования только сайт?"

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс - в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

*Из большого ежегодного опроса компаний от VersionOne

Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

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

Команда в игре "Что? Где? Когда?" существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

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

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

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

Но . Даже если вы веб-студия и для вас это тысячный сайт, для клиента это первый раз. И его желания останутся неопределенностью до самого конца. Многие студии делают 3-4 варианта главной страницы и закладывают неделю на непредвиденные доработки. У всех, кого я знаю, работа разбита на итерации, после каждого есть демонстрация и обсуждение. Общение с заказчиком важнее подписанного контракта.

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

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

Итого ключевые ценности Agile (манифест):

• свободное взаимодействие в команде
• результативность проекта (классный продукт)
• партнерское общение с клиентом
• готовность к изменениям

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration). Если идет обсуждение вопроса "Как реализовать продукт?" на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: "Как управлять ресурсами когда все так гибко?"

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

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) - это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте - это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, "Выпуск досок с правами" или "Выпустить сайт на тест". Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь - это график с двумя линиями; первая - сколько времени сгорело и это всегда прямая, на второй - сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка - попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход - заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России - они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения - это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование - спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом - хорошая практика. Спринт - это несколько недель. Слишком короткие или слишком длинные отрезки - плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача - чтобы каждый день команда подтверждала единое направление движение всех участников. По классическому описанию каждый в команде раскрывает три вопроса:

• Что сделано к этому моменту из спринта?
• Что планируется на сегодня?
• Какие проблемы возникли или что мешает?

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

3. Ретроспективы (83% команд используют)
Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель - сделать выводы о том, как меняться.
Заказчику продукта - о том как лучше показывать ожидания пользователей, методисту - о том, как побуждать диалог и выполнять договоренности выбранных подходов, команде - о том, как при оценках учитывать новые открывающиеся факторы. Как правило ретроспективы проходят весело - итерация-то закончилась, можно выдохнуть и обсудить итоги. Хорошая практика что-нибудь пить или есть в перерывах этого процесса.

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

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании. Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

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

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

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

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