Методика agile: Гибкая методология разработки — Википедия – преимущества, пути внедрения и подводные камни

Методологии разработки ПО: Agile | GeekBrains

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

https://d2xzmw6cctk25h.cloudfront.net/post/1863/og_cover_image/6ae757601184e793149f82c869acca51

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

В феврале 2001 года семнадцать человек — крупные IT-специалисты и разработчики — собрались на горном курорте в штате Юта. Отдохнули, пообщались и составили небольшой документ — Agile-манифест.

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

Гибкость во всем

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

Не углубляясь в детали, вспомним, как устроена разработка по методологии Waterfall:

1. Выдвигаются требования к ПО, разрабатывается техническое задание (ТЗ).
2. Поставленные задачи воплощаются в коде.
3. Выполняется тестирование.
4. Готовое ПО внедряется в работу.

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

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

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

Чтобы понять, как это работает, представим коллектив разработчиков, создающих аудиоплеер. Уже написан костяк программного кода: интерфейс и базовый функционал. Программа умеет воспроизводить файлы формата MP3, WAV и OGG. Но пользователи предлагают добавить проигрывание CD-дисков и подключить горячие клавиши, чтобы быстро управлять плеером.

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

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

На этом итерация завершается — и начинается новый виток разработки.

Идеи и принципы

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

Четыре центральных идеи Agile Manifesto

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

12 принципов Agile

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


9. Уделять пристальное внимание техническому совершенству и качеству проектирования — это повышает гибкость проекта.
10. Минимизировать лишнюю работу.
11. Стремиться к самоорганизующейся команде — в ней рождаются наиболее эффективные и качественные решения.
12. Всем участникам команды — постоянно искать способы повышать эффективность работы.

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

Scrum

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

Впервые термин прозвучал в 1986 году. Японские исследователи Икуджиро Нонака и Хиротака Такеучи в статье The new New product development game сформулировали принципы, позволяющие быстрее создавать новый продукт. Среди условий такой разработки назвали самоорганизующуюся команду специалистов, их полную свободу в творчестве и работе — без ограничений со стороны топ-менеджмента. Этот подход авторы описали так:

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

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

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

Методика, предложенная Нонака и Такеучи, нашла применение в IT-сфере, разработке инженерных решений в машиностроении, электронике. В 90-х Scrum оформился как проработанная и цельная методология, оброс конкретными приемами, помогающими с нуля наладить работу команды. Благодаря Кену Шваберу и Джеффу Сазерленду Scrum пришел в IT и приобрел популярность среди разработчиков — некоторые даже считают эту методологию революционной.

Командный дух

В команде, работающей по принципам Scrum, нет внутренней иерархии: ни руководителей, ни подчиненных, ни указаний-приказов. Есть два особых члена группы: product owner — владелец продукта, и scrum master — скрам-мастер.

Product owner лучше всех знает, каким должен быть продукт. Зачастую это заказчик, его представитель или сотрудник, ответственный за взаимодействие с клиентом. Он должен ясно понимать, что именно требуется конечному пользователю программы. Все пожелания и предложения по функциональности и внешнему виду продукта (в Scrum они называются stories — истории) он заносит в специальный список — Product Backlog. Бэклог формируется до старта разработки и по ходу постоянно пополняется. Здесь же указывают приоритеты доработок.

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

Рывок! Еще рывок!

Работа над программой в Scrum, как и в Agile в целом, разделена на итерации. Здесь любят спортивную терминологию: эти отрезки разработки называют забегами или спринтами. Каждый начинается с того, что команда сообща определяет, какие именно истории из списка владельца продукта она сможет реализовать на этом спринте. Выбранные идеи переносятся в отдельный список — sprint backlog. Фиксируется цель: что конкретно команда сможет продемонстрировать пользователю в итоге. Задачи распределяют, и начинается забег.

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

В конце забега результаты демонстрируют владельцу продукта. И немедленно начинают новый спринт — очередную итерацию цикла разработки.

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

XP — программируем экстремально!

Речь не о Windows XP. Под этой аббревиатурой скрывается еще одна методология из класса Agile: eXtreme Programming — экстремальное программирование. Ее придумал разработчик Кент Бек, развивали Уорд Каннингем, Мартин Фаулер и другие. Это набор простых принципов и практик, которые помогают наладить эффективную работу.

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

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

В экстремальном программировании все эти принципы доведены до предела. Нет времени объяснять — нужно делать! Планируют на короткий срок. Итерации разработки максимально сжатые. Чем быстрее выйдет рабочая версия — тем лучше. Реализуется самое простое из решений, а код пишется и тестируется параллельно.

Экстремальные практики

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

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

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

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

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

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

Парное программирование — одна из полезных практик XP

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

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

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

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

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

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

Экстремально — не значит плохо

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

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

Экстремальное программирование не предписывает, как действовать в конкретной ситуации. Если решение задачи для всех очевидно и написать код не составит труда — нет реальной необходимости в парном программировании. Если на часах 18:00, а вам осталось дописать двадцать строк кода — можно не откладывать на завтра. Методология не заменяет здравый смысл!

Никакого волшебства

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

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

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

Преимущества Agile

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

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

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

Темная сторона силы: недостатки Agile

Не факт, что программа когда-нибудь будет завершена.

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

Но если вы планируете долговременное сотрудничество с заказчиком и он готов платить за все время разработки — почему нет?

Пользователь требует все и сразу.

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

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

«Золотые пользователи»

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

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

Строительство без чертежей

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

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

Постоянная спешка

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

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

До тех пор, пока работает…

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

Кому подойдет Agile

Методологии класса Agile хорошо себя покажут, если:

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

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

Больше методологий богу методологий!

Мы рассмотрели Scrum и XP, но класс Agile включает и другие методологии. Есть любопытные подходы и вне Waterfall и Agile. Продолжим в следующей статье.

Гибкая методология разработки “Scrum” / Habr

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

В настоящее время, Scrum является одной из наиболее популярных «методологий» разработки ПО. Согласно определению, Scrum — это каркас разработки, с использованием которого люди могут решать появляющиеся проблемы, при этом продуктивно и производя продукты высочайшей значимости (с точки зрения клиента — прим. Автора) [1].

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

Когда говорят о методологии Scrum, чаще всего имеют ввиду гибкую методологию разработки ПО, построенную на основе правил и практик Scrum, так что вполне может оказаться что ваш Scrum круче моего Scrum, а также быть от него так же далеким, как ВАЗ 7-ка от BMW 7-й серии 🙂

Авторами Scrum заявлены следующие особенности:

-Легкий (англ. Lightweight)

-Понятный, доступный

-Сложный в освоении

(практически взаимоисключающие параграфы)

Роли в Scrum

В классическом Scrum существует 3 базовых роли:

—Product owner

—Scrum master

—Команда разработки (Development team)

Product owner (PO) является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды.

Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи (такие как Story, Bug, Task и др.), отсортированные в порядке приоритета (срочности).

Scrum master (SM) является «служащим лидером» (англ. servant-leader). Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, помощи PO

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. Согласно The Scrum Guide (документу, являющимся официальным описанием Scrum от его авторов), DT должны обладать следующими качествами и характеристиками:

-Быть самоорганизующейся. Никто (включая SM и PO) не может указывать команде каким преобразовать Product Backlog в работающий продукт

-Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта

-За выполняемую работу отвечает вся команда, а не индивидуальные члены команды

Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [1]

Процесс Scrum

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog.

Каждый день производится Daily Scrum, на котором каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint’а.

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

Схематическое изображение процесса приведено на следующем рисунке:

Важные, часто забываемые особенности

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

1. Scrum применяется неверно или неполностью.

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

2. Недооценена важность работы по обеспечению мотивации команды.

Одним из основных принципов Scrum являются самоорганизующиеся, многофункциональные команды. Согласно исследованиям социологов, численность самомотивированных сотрудников, способных на самоорганизацию не превышает 15% от работоспособного населения [2].

Таким образом, лишь небольшая часть сотрудников способно эффективно работать в Scrum без существенных изменения в ролях Scrum master и Product Owner, что противоречит идеологии Scrum, и потенциально приводит к неверному или неполному использованию Scrum.

3. Scrum применяется для продукта, требования к которому противоречат идеологии Scrum.

Scrum относится к семейству Agile, так Scrum приветствует изменения в требованиях в любой момент (Product backlog может быть изменен в любой момент). Это затрудняет использование Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, таким образом нет смысла зарание планировать весь проект, ограничившись только just-in-timе планированием, т. е. Планировать только ту работу, которая должна быть выполнена в текущем Sprint. [3] Существуют и иные ограничения.

Достоинства и недостатки

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

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

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

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

Проблема является большей, чем кажется. Т.к. Scrum относится к семейству Agile, в Scrum не принято, к примеру, создание плана коммуникаций и реагирования на риски. [3] Таким образом, делая сложным или невозможным формальное (юридическое или административное) противодействие нарушениям правил Scrum.

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

Список использованных источников

[1] The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff Sutherland)

[2] Психология управления, учебное пособие. (А. А. Трусь)

[3] How a Traditional Project Manager Transforms to Scrum: PMBOK vs. Scrum. (Jeff Sutherland, Nafis Ahmad)

Заранее благодарю за указанные ошибки и неточности!

Agile in IT: 7 техник оценки задач

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

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

Принцип 1: высокая скорость оценки

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

Принцип 2: командная работа

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

Принцип 3: относительные единицы измерения

• Следующая особенность методов оценки в Agile, это использование относительных единиц измерения. При использовании гибких методологий мы не считаем напрямую рубли, доллары, дни, килограммы и т.п. Для оценки могут используются какие-либо маркеры, точки, карты с числами, цвета и т.д., что дает хорошую возможность сравнивать  различные задачи друг с другом напрямую и качественно.  При этом мы избегаем каких-либо ассоциаций и привязки к дополнительным абстрактным величинам, например, дням.
• Например, если мы оценили задачу и получили трудозатраты 100000$, то мы невольно задумаемся много это или мало и это может повлиять на конечную оценку. При этом если задачу оценили в 100 story points (очков, баллов, попугаев), то само по себе это значение еще ничего не говорит, он работает только в сравнении с другой задачей и в этом случае оценка не искажается.

Метод 1: T-Shirt Sizes (Размеры футболки)

• В качестве единицы измерения в этой технике используется размер футболки: XS, S, M, L, XL. Команда принимает решение о размере той или иной пользовательской истории в ходе совместной открытой дискуссии. В случае неопределенности, возможно применение голосования. При желании можно договориться о соотношении «размеров», например, S это до 2 XS, M это до 2 S и так далее.
• Как правило первые несколько задач оцениваются предварительно. Далее начинает вырисовываться картина о степени декомпозиции историй. В итоге мы находим самые мелкие относительно остальных задачи и они принимаются за XS . После этого остальные задачи оцениваются с точки зрения насколько они больше XS. В зависимости от этого им присваивается определенный размер S, M, L или XL.
• Также можно договориться, что у нас есть, например, большой размер XXL. Присвоение истории этого размера говорит, что на самом деле мы не можем оценить задачу и она нуждается в дальнейшей декомпозиции и\или уточнении.
• Данная техника является довольно быстрой и ее можно использовать для оценки большого количеством user story за одну сессию. С ее помощью вполне реально за час оценить 15-20 историй.

Метод 2: Planning Poker (Покера планирования)

• Это одна из самых популярных техник оценки. Участники процесса используют специально пронумерованные карты (подобные игральным), чтобы голосовать с их помощью за оценку user story. Обычно для «покера» используются карты с числами Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89), но возможны и другие варианты.
• Процесс оценки выглядит следующим образом:
  • Каждый участник получает колоду карт с числовыми значениями для оценки, изображением «?» (запрос уточнения задачи) и «чашки кофе» (требование перерыва).
  • Product Owner делает краткий анонс очередной пользовательской истории и отвечает на вопросы команды по данной задаче.
  • Участники «покера» выбирают карту с подходящей по их мнению оценкой и кладут их рубашкой вверх (чтобы не влиять на выбор друг друга).
  • После того, как все члены команды выбрали свои оценки карты одновременно переворачиваются.
  • Участникам с самыми низкими и высокими оценками делают краткие комментарии объясняя свой выбор оценки.
  • В итоге процесса обсуждения команда приходит к единому решению и после этого переходит к следующей пользовательской истории.

• Planning Poker одна из самых точных техник оценки, но подходит для сравнительно небольшого количества задач. В течение часовой сессии таким способом можно оценить 4-10 историй.

Метод 3: Bucket System (Система «ведерок»)

• В этой методике используется принцип похожий на Planning Poker — задачи оцениваются и помещаются с ведерки с соответствующим размером. Для указания размера также можно использовать числа Фибоначчи. Однако у этих методов есть принципиальное различие – в Bucket System после начального масштабирования задач, процесс задачи разделяются между участниками для оценки.
• Процесс оценки выглядит так:
  • Все истории, которые требуется оценить, выписываются на карточки.
  • На столе или доске выстраивается последовательность из «ведерок» для задач различного размера.
  • Команда выбирает по очереди 3-5 произвольные карточки с задачами и оценивает их в ходе открытого обсуждения сравнивая и выстраивая их друг относительно друга.
  • Задачи помещаются в соответствующие «ведра» задавая общий масштаб и ориентиры для последующих оценок.
  • Далее все оставшиеся задачи поровну разделяются между всеми участниками и оцениваются ими самостоятельно, с учетом полученной шкалы измерений.
  • Если кто-то из членов команды затрудняется оценить какую-либо историю, то он передает ее другому.

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

Метод 4: Dot-voting (Голосование по точкам)

• Этот способ предполагает использование специальных «точек», которые показывают голоса участников\баллы оценки поставленные для той или иной задачи. В качестве таких «точек» могут использоваться: наклейки, стикеры, магниты, точки\штрихи проставленные маркерами.
• Этапы процесса оценки:
  • Все оцениваемые User Stories выписываются на отдельные карточки и размещаются на столе\доске.
  • Для выполнения оценки каждый из участников получает одинаковое количество «точек». Каждый член команды распределяет свои «точки» между задачами как он считает нужным, учитываю, что чем больше «точек», тем сложнее задача и тем больше на нее необходимо времени.
  • После того как каждый участник сделал свою оценку и распределил все свои «точки», подсчитывается общее количество точек выставленных для каждой пользовательской истории. В результате все задачи ранжируются между собой по количеству «точек».

• Данный метод является очень простым и быстрым, он будет эффективно работать для оценки небольшого количества историй (до 8-10).

Метод 5: Maximum Size or Less (Разделение до максимального размера или меньше)

• В рамках этой техники участники процесса оценки вначале определяют максимально возможный размер для задачи в бэклоге. Чаще всего в качестве максимального значения выбирается 1 человеко-день (1 FTE). В этом случае самые большие задачи должны требовать для их выполнения не более 1 дня.
• Далее процесс оценки выглядит следующим образом:
  • Каждая история обсуждается всеми участниками, чтобы ответить на вопрос: оцениваемая задача больше максимального значения или меньше\равна ему?
  • Если данная история больше максимального размера, то группа декомпозирует ее на подзадачи и повторяет процесс с оценки для составных частей.
  • Процесс продолжается пока все оцениваемые задачи не окажутся в разрешенном диапазоне размеров – будут равны или будут меньше выбранного за максимальное значения.

• Этот метод оценки также очень прост в использовании и с его помощью команда способна за справиться с 15-30 задачами (в зависимости от сложности и опыта декомпозиции).

Метод 6: Big/Small/Uncertain (Большой/Малый/Неопределенный)

• Данный метод похож на технику Bucket System, основное различие состоит в том, что в этом случае используется только 3 ведра: большой размер, малый размер, неопределенный размер задачи.
• Процесс оценки:
  • Все оцениваемые истории обсуждаются участниками и помещаются в одну из трех категорий Big/Small/Uncertain.
  • Сначала группа проводит групповое обсуждение нескольких первых задач (3-5), определяя масштаб и ориентиры для каждой категории. 
  • Затем, подобно Bucket System, оставшиеся истории распределяются между участниками и оцениваются самостоятельно, что сильно ускоряет процесс.

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

Метод 7: Ordering Rule (Выстраивание порядка)

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

• Этот метод довольно эффективен для оценки небольшого количества задач (5-15). Участники вовлечены в общий геймифицированный процесс и изменяя положения историй относительно друг друга добиваются высокой точности оценки.

 Смотрите также:

Agile: 8 методов декомпозиции задач

Agile: методы приоритезации задач

Менеджмент

Agile in IT

10 апреля 2017

GTD vs Agile Results. Исправляем недочёты Дэвида Аллена / Habr

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

Вступление и причина основных недостатков GTD

«Поразительно: те же люди, которые оставляют предзаказы на новый iPad, считают дни до следующего мероприятия Apple и следят за тем, чтобы всегда иметь самую последнюю версию каждой программы — придерживаются системы продуктивности, которая была разработана более 10 лет назад». Sven Fechner

Да-да, книга “GTD” вышла в далёком 2002-ом. Меня она, бесспорно, научила многому:

• принципу “Inbox” для разгрузки оперативной памяти мозга;
• привычке задавать вопрос: “Какое конкретное действие должно быть следующим?”;
• алгоритму обработки и организации задач и, в частности, золотому “правилу 2-х минут”;
• использованию контекстов и практике еженедельного обзора.

Однако к ортодоксальным GTD-шникам я себя отнести не могу и насчет идеальности этой системы иллюзий не питаю. Вот с какими недостатками GTD я знаком не понаслышке:

• GTD не для практиков. Данная методология уделяет больше внимания стадиям обработки и организации задач, чем собственно их выполнению.
• GTD зациклена на задачах. По этой причине GTD слабо подходит людям творческих профессий, которые на просьбу описать их день с помощью списка четких “следующий действий” могут лишь улыбнуться. Им скорее нужно “три часа тишины и спокойствия для сфокусированной работы над проектом”.
• GTD мелочна. С GTD ты постоянно ощущаешь себя улиткой, продвигающей свои 100+ проектов (нормальное для этой методики количество) по сантиметру за день. К тому же постоянная необходимость расстановки приоритетов для такого количества проектов очень напрягает.
• GTD слишком “приземлённа”. Система не располагает инструментами, позволяющими подняться над рутиной и расставить приоритеты на более высоких уровнях. Главы книги, посвященные этим вопросам, проработаны откровенно слабо. Слепо следуя методологии, вы рискуете превратиться в человека, который автоматически обрабатывает и выполняет любые задачи, попадающие в его Inbox, вместо того, чтобы разобраться и сконцентрироваться на том, чем ему действительно стоит заняться.

Если посмотреть на получившиеся списки достоинств/недостатков, то легко заметить, что все основные проблемы GTD не относятся к сфере продуктивности, а лежат в области личной эффективности. Чтобы убедиться, что мы говорим об одном и том же — вот определения этих понятий, которых придерживаюсь я:

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

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

Суть методики Agile Results

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

Agile Results — это система личной эффективности, которая нацелена на достижение значимых результатов. Согласно Agile Results, ключом к достижению результатов является гибкость (agility), которая определяется как готовность к постоянному совершенствованию на основе получаемой ответной реакции на свои действия. Методологию разработал и описал в книге “Getting Results the Agile Way” J.D. Meier, топ-менеджер в команде разработчиков Microsoft Enterprise Strategy.

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

Просто приучите себя задавать вопрос: “Каких 3-ех результатов я хочу добиться к концу этого дня?

Основой Agile Results является следующий шаблон эффективной недели:

• Планирование в понедельник. В начале недели вы определяете 3 главных Результата Недели, которых хотите достичь к пятнице →
• Ежедневные победы. Каждый день вы формулируете по 3 Результата Дня. В идеале они должны продвигать вас в направлении Результатов Недели →
• Пятничный обзор. В пятницу вы подводите итоги недели, выделяя 3 сферы, дела в которых идут хорошо и 3 сферы, требующие улучшений. Полученный фидбек пригодится при планировании в следующий понедельник.

Третий элемент системы Agile Results — Сфера Влияния — позволяет подняться на уровень выше и расставить приоритеты, оценив свою жизнь с высоты птичьего полета. Сферами Влияния называются ключевые жизненные категории, требующие наибольших инвестиций времени, энергии и внимания, например, Здоровье, Финансы, Отношения и т.д. Ваша цель заключается в том, чтобы знать ответ на вопрос: “Каких результатов я хочу добиться?” для каждой из Сфер.

J.D. Meier предлагает ряд полезных техник для достижения баланса между всеми Сферами Влияния: таймбоксинг, спринты улучшений, радар результатов и др.

Как Agile Results решает главные проблемы GTD

Теперь давайте рассмотрим основные различия Agile Results и GTD и каким образом Agile Results помогает решить вышеобозначенные проблемы.

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

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

Полученные результаты важнее выполненных задач. Можно много времени потратить на вычеркивание различных задач из списка дел, ничего не добившись в результате. Концентрация GTD на задачах приводит к “продуктивности ради продуктивности”: мы делаем много, а добиваемся малого.

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

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

Заключение и полезные ссылки

Для меня интеграция ключевых техник Agile Results в свой GTD-workflow прошла быстро и безболезненно. Эти две методики очень удачно дополняют друг друга: продуктивность начинает работать на благо эффективности.
Благодаря Agile Results в моем RememberTheMilk сейчас значится всего один невыполненный Результат Недели: “Написать хороший топик про Agile Results на Хабр”. И мне не пришлось заниматься глупостями, вроде составления списка дел и выбора оптимального “следующего действия” для этого проекта.

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

И еще: я бы посоветовал обратить особое внимание на Agile Results тем, у кого по тем или иным причинам не срослось с GTD — Agile Results вполне самодостаточна и гораздо более универсальна.

Если есть вопросы — задавайте, с удовольствием пообщаюсь и поделюсь опытом.