Методологии программирования agile. Методология Agile: суть, основные принципы. Feature Driven Development состоит из таких цикличных этапов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Делай сразу!

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

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

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

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

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

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

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

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

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

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

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

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

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

Гибкая методология разработки (от англ. - Agile software development) - манифест, определяющий способ мышления и содержащий основные ценности и принципы, на которых базируется несколько подходов (фреймворков, от англ. framework - каркас, структура) к разработке программного обеспечения (хотя в последнее время идет тенденция и попытки применения гибкой методологии разработки к иным направлениям деятельности, не только в части информационных технологий), подразумевающих под собой интерактивную разработку, периодического (динамического) предоставления (обновления) требований от Заказчика и их реализацию посредством самоорганизующихся рабочих групп, сформированных из экспертов различного профиля (разработчики, тестировщики, внедренцы и т.д.). Такой перевод Agile, как "гибкая методология разработки" не совсем корректен т.к. обычно Agile не называют методологией, а вот подходы на основе данного манифеста и есть методологии, но с точки зрения Agile их называют - фреймворки. На данный момент существует множество фреймворков (методологий), подходы которых базируются на гибкой методологии разработки, например такие, как: Scrum, Extreme programming, FDD, DSDM и т.д.

Определение с точки зрения BPM CBoK [от англ. - Guide to the Business Process Management Common Body Of Knowledge]. Agile - Одна из методологий итеративной и пошаговой разработки ПО, в противоположность традиционной линейной методологии «водопад». Методология гибкой разработки определяет систему методов проектирования, разработки и тестирования на протяжении всего жизненного цикла ПО. Методы гибкой разработки (например, SCRUM) основаны на оперативном реагировании на изменения за счет применения адаптивного планирования, совместной выработки требований, рационализации самоорганизующихся кросс‑функциональных групп разработчиков, а также пошаговой разработки ПО с четкими временными рамками. Этот подход используется во многих современных проектах разработки коммерческого ПО.

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

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

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

История выпуска Agile манифеста

«Манифест гибкой методологии разработки программного обеспечения» был выпущен и принят в феврале 2001 года (штат ЮТА США, лыжный курорт The Lodge at Snowbird) группой экспертов. Данный манифест определяет 4 основные ценности и 12 принципов для методологий, базирующихся на нем, а также дает альтернативное видение подхода к разработке программного обеспечения в отличие от крупных и известных методов и методологий, но не является сам по себе методологией. Обычно Agile сравнивают в первую очередь с "методом водопада" ("waterfall"), т.к. на момент выхода манифеста, именно "метод водопада" являлся основным при планировании разработки программного обеспечения. В разработке и выпуске Agile манифеста принимали участие представители следующих методологий:

• Adaptive software development (ASD)
• Crystal Clear
• Dynamic Systems Development Method (DSDM)
• Extreme Programming (XP)
• Feature driven development (FDD)
• Pragmatic Programming
• Scrum

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

Agile-манифест разработки программного обеспечения:

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

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

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Авторы манифеста:

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

Основополагающие принципы Agile-манифеста:

Мы следуем таким принципам:

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

Критика Agile

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

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

Anti-Agile манифест (необходимо отметить, что данный anti-agile манифест на самом деле противоречит не самому Agile, а скорее одному из фреймворков, основанном на принципах Agile - Scrum т.к. в манифести используются термины именно из этого фреймворка):

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

• эпики (epics) - это просто проекты
• пользовательские истории (user stories) - это просто сценарии использования (use case)
• спринты (sprints) - это просто работа
• стенд апы (stand-ups) - это просто совещания
• итерации (iterations) - это просто версии
• бэклоги (backlogs) - это просто список дел
• скорость команды (velocity) - это просто результаты
• и эти задачи (tasks) - это реально, просто задачи

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

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

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

• Agile Modeling (AM) - данный подход в основе своей определяет процедуры моделирования (в т.ч. проверка модели кодом) и документирования в рамках разработки программного обеспечения. В меньшей степени описаны процедуры проектирования и построения диаграмм на UML. также не затронуты области разработки, тестирования, управления проектом, развертывания и сопровождения.
• Agile Unified Process (AUP) - унифицированная версия методологии RUP (IBM Rational Unified Process), которая была сформирована Скоттом Амблером. AUP определяет модель создания программного обеспечения в рамках бизнес-приложений.
• Agile Data Method (ADM) - набор итеративных методик гибкой разработки программного обеспечения, в рамках которых делается упор на формирование требований и решений посредством сотрудничества различных кросс-функциональных команд.
• Dynamic Systems Development Method (DSDM) - итеративный и инкрементный подход, базирующийся концепции быстрой разработки приложений - Rapid Application Development (RAD), упор в котором делается на максимальное привлечение конечного пользователя к разработке программного продукта.
• Essential Unified Process (EssUP) - подход, разработанный Иваром Якобсоном (Ivar Jacobson), содержит в себе методы итеративной разработки программного обеспечения, с упором на архитектуру продукта и наработанные практики команды (по сути заимствованные из RUP, CMMI и Agile Development). Идея заключается в том, что вы используете только те практики и методы, которые применимы в конкретной ситуации. На основе выбранных методов и практик определяется целевой процесс. В отличие от RUP, где все практики и методы взаимосвязаны, в данном случае появляется гибкость и возможность вычленить из всего доступного объема именно необходимые элементы (методы и практики).
• Extreme programming (XP) - идея экстремального программирования заключается в том, чтобы использовать уже имеющиеся лучшие практики в области разработки программного обеспечения, подняв их на новый (экстремальный) уровень. Например в отличие от обычной практики, когда один программист последовательно проверяет написанный код за своим коллегой, в экстремальном программировании данная проверка осуществляется параллельно, что увеличивает скорость выпуска продукта, но и риски тоже.
• Feature driven development (FDD) - основное ограничение, которое накладывается в рамках данного подхода, это "каждая функция должна быть реализована не более, чем за две недели". Т.е. если реально разработать функцию за один присест, то это хорошо, в противном случае данная функция должна разбиться на несколько и реализовываться постепенно.
• Getting Real (GR) - в рамках данного подхода исключены процедуры функциональных спецификаций, использующийся для веб-приложений. Разработка начинается от обратного, изначально разрабатывается интерфейс и дизайн, а потом сама функциональность.
• OpenUP (OUP) - данный подход определяет итеративно-инкрементальный метод разработки программного обеспечения. Разработан на основе RUP. В рамках данного метода определен жизненный цикл разработки (фаза запуска, фаза уточнения, фаза разработки и передачи заказчику). Благодаря определенной этапности и контрольных точек, повышается эффективность контроля и мониторинга хода реализации проекта, как следствие своевременное принятие решений по проекту.
• lean software development - данный подход основан на концепции бережливого управления производственным предприятием (lean production, lean manufacturing).
• Scrum - один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Примером философии Agile является принцип работы известного завода «Toyota», где любой подчиненный мог остановить конвейер, и внести корректировки. ()

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

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

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

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

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

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

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

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

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

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

История Agile

в 1970 году, д-ром Уинстоном Ройсом была представлена методика «управление разработкой крупных программных систем». С тех пор, стало существовать понятие Agile. Полная история становления проектного управления описана в

Кое что про Scrum метод

Преимущества гибких методов разработки

• Повышение качества результатов
• Адаптация к изменениям
• Очень быстро и эффективно
• Более контролируемый график реализации проекта

Основные принципы Agile

1. Вовлечение пользователей имеет решающее значение;
2. Чтобы принимать решения, команды должны быть высокоэффективными;
3. Этапность и цикличность как основа;
4. Концентрируется на частых представлениях промежуточных результатах проектов;
5. Применяется правило работы 80/20;
6. Использование совместного подхода к реализации плана;
7. Завершения отдельного этапа, для перехода к следующему.

Также мы вывели 12 основных принципов Agile методологии в отдельную инфографику. Посмотреть можно

Характеристики методики:

• Итерационная
• Модульная
• Возрастающая
• Адаптивная
• ОбъединяющаяОшибки при внедрении гибких методов управления проектами описаны в статье

Зачем использовать Agile?

• Прирост денежного потока
• Контроль рисков
• Снижение времени и накладных расходов
• Повышение подотчетностиО том как использовать Agile для развития читайте в статье

Какая методология управления проектами подходит для вас?

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

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

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

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

Каскадная методология управления проектами

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

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

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

• Лучше всего подходит для проектов, которые имеют дело с физическими объектами – от строительных проектов до проектов по установке оборудования
• Требования описываются в начале проекта
• Лучше всего для проектов с четко определенными задачами и этапами, которые необходимо выполнить в определенной последовательности (например, построить первый этаж здания до второго этажа)
• Не требуется участие заказчика в процессе разработки
• Графики проектов можно использовать в будущем, для идентичных или аналогичных проектов
• Полный объем требований заранее известен
• Определенные в ТЗ результаты снижают вероятность недоделок

Недостатки классической методологии проектного менеджмета

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

Agile – методология управления проектами

Agile – это быстрый и гибкий подход к управлению проектами на основе принципов сотрудничества, адаптивности и непрерывного совершенствования

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

Преимущества гибкой методологии проектного управления

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

Недостатки гибкой методологии проектного управления

• Команда все время вовлечена в проект
• Не подходит для проектов с четко определенными требованиями и объемами
• Неопределенность в объеме и сроках работ могут заставить нервничать Заказчиков и руководство (по началу)
• У клиента может не быть времени на вовлечение в проект
• Требует постоянного отслеживания работ и ведение документации по управлению задачами команды
• Заказчик может пересмотреть объем работ
• Быстрый запуск может привести к неполному выполнению задач

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

Удачи в проектах!

Совмещение Agile и поточной методологии

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

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

Процесс оказания услуг

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

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

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

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

4. Разработка решения
Команда разработчиков начинает проработку решения.

Гибкая методология разработки (agile-структура)

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

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

Уникальность совмещенной методологии:

Использование Agile методологи на каждом шаге приводит к экономии средств и ресурсов как клиента, так и исполнителя.

Использование каскадной модели для крупного проекта приводит к контролю над общими результатами.

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

Быстрое и частое прототипирование .

Подход, ориентированный на клиентов – ориентация на минимизацию общей стоимости владения (TCO) и максимизировать отдачу от инвестиций (ROI).

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

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

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

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

Вместо определения. Что сказать про 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-методологии и будет не лишним гордо сообщать об этом внутри коллектива.