Agile метод – Scrum, Kanban, PRINCE2 и другие

Содержание

Agile умер, да здравствует… Agile / Habr

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

Несмотря на то, что Agile появился около 20 лет назад, более-менее активно применять его начали только в течение последних восьми лет. Гибкие принципы возникли как альтернатива традиционным методам разработки с целью уменьшения затрат на производство ПО, готового для отправки заказчику (potentially shippable software), за счёт повышения эффективности совместной работы и клиентоориентированности. То есть набор принципов формировался под решение задач бизнеса – для ускорения процесса разработки и достижения максимального результата от команды без увеличения затрат на производство.
Да, гибкая методология позволяет выжать из команды максимальный КПД, но есть два нюанса, которые при сложившихся обстоятельствах снижают Agile-эффект. Во-первых, принципы действительно работают только в небольших командах. Кроме того, если в команде все специалисты очень сильные, то совершенно не факт, что получится существенно увеличить их производительность.

Как это работает?


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

Традиционно целью Agile был первый этап разработки – написание кода. В конце далёких 90-х именно этот этап рассматривался как требующий улучшения и серьёзных изменений. Тогда же получила известность одна из наиболее распространённых имплементаций Agile — Scrum. Справедливости ради стоит отметить, что Scrum вышел в свет в 1986 году, за 15 лет до того, как был адаптирован для Agile в 2001 году.

Scrum приносит выборку того, что нужно писать, позволяет отследить процесс разработки, выявить недостачи и противоречия на начальных этапах. Без технического задания программист не знает, какой именно продукт должен получиться в результате. Например, если речь идет о Google или Facebook, то у разработчиков того или иного сервиса вопросов не возникает. Они делают продукт для себя — сами являются его заядлыми пользователями и понимают, что и как должно выглядеть и что нужно сделать, чтобы новый функционал был удобным. Другое дело, например, система биллингa. Программист не знает того огромного количества нюансов, которые необходимо учесть для корректной работы сервиса как регуляционных, так и маркетинговых, как, например, различные модели расчётных операций.


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

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

Например, в июле 2015 после очередного обновления ПО были остановлены торги на Нью-Йоркской фондовой бирже. Этот сбой сотряс мировую экономику, в частности, снизил на 1% фондовый индекс США на весь день, а также затормозил переговоры Греции с ее кредиторами на целую неделю! Ещё один яркий пример – обновление системы продажи авиабилетов в компании «Дельта». После выпуска нового ПО в продакшен информация вообще перестала поступать в диспетчерскую службу. В результате авиакомпания отменила все рейсы и понесла существенные финансовые и репутационные потери. Несомненно, в обоих случаях многие проверки перед запуском были пройдены и, тем не менее, ещё многие были бы сделаны, если бы занимали меньше ресурсов и времени.

Пробел с обеспечением качества кода сегодня очень актуален и он будет постепенно заполняться. По оценкам Gartner, в ближайшие три года по крайней мере 75% IT–корпораций будут вынуждены развить автоматическое тестирование, интегрирующее бизнес-процессы. Определенные надежды на решение проблемы качества возлагаются на такие технологии и методологии, как контейнеры и BDD (behavior driven development) – Docker, Cucumber и прочие.

У кого это работает?


На сегодняшний момент принципы Agile имплементированы в большинстве компаний, где это было возможно сделать без особых рисков для бизнеса. И все, кто смог выстроить новые процессы, в целом довольны результатами, например: Google, Zara, Ikea. Однако стоит обратить внимание, что эти компании действуют по принципу «разделяй и властвуй» — то есть работа разделена на проекты, которыми занимаются относительно небольшие самостоятельные команды. Кроме того, по Agile в этих компаниях работает в первую очередь бизнес-подразделение (особенно это касается Zara и Ikea), а не только отдел разработки. Они изменили не только организацию процесса, но и бизнес, поэтому естественным образом соответствуют Agile-модели.

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

То есть в тех областях, где цена ошибки очень высока, компании пока опасаются что-то менять. Да, они понимают, что Waterfall себя изжил и, работая по-старому, можно в какой-то момент остаться далеко позади от конкурентов и всё потерять. Они бы и рады перейти на новые методы работы, но пока риски гораздо выше, чем потенциальная выгода от нововведений. Кроме того, зачастую необходимы большие вложения, чтобы перевести бизнес на гибкие методологии и далеко не факт, что всё сразу заработает хорошо. Это касается в первую очередь тех компаний, где большинство бизнес-процессов построено на ПО, написанном десятки лет назад на языках программирования, не столь модулярных, как Java, Scala, GO и пр.

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

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

Как повысить эффективность?


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

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

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

На чем стоит и куда движется Agile


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

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

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


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

1. Появление возможности для запуска бизнес-тестов без особых затрат,

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

Когда наступит «золотой век» Agile?


С начала своего существования Agile перевоплотился из набора принципов в ассортимент методологий, процессов и даже стандартов. Сегодня поле деятельности этих методологий не ограничено командами разработчиков. Гибкие процессы успешно внедряются практически во все отделы IT и даже бизнес руководствуется стандартами Agile. Среди наиболее известных можно отметить Scrum, Scrumban, SAFe, [email protected], Continuous Delivery, Lean, Prince2 Agile и многие другие.

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

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

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

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

habr.com

популярные мифы о гибкой разработке / Mail.ru Group corporate blog / Habr

Методологии гибкой разработки (Agile) прижились и в IT, и в не-IT, обросли своими приметами, стереотипами, суевериями и мифологией. Редакция блога Mail.Ru Cloud Solutions решила поговорить об этой мифологии с Agile-коучем Василием Савуновым из ScrumTrek.

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

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

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

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

Миф 1. Agile — это только для IT


Уже нет. Достаточно посмотреть на список компаний, от лица которых выступают спикеры на конференциях Agile Days и Agile Business Conference: «Газпромнефть», «Ростелеком», «Северсталь», PTG-Group, 12Storeez. Эти и масса других организаций, не относящихся к IT-индустрии, более чем успешно используют Agile-подходы.

Миф 2. Agile — не для проектов с фиксированным бюджетом


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

Миф 3. Agile — панацея для бизнеса и разработки: внедри, что-нибудь да улучшится


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

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

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

Миф 4. Scrum, Lean, Kanban не пересекаются между собой


Следует разделять методологии и инструменты. Методология — это алгоритм построения рабочего процесса. Инструменты – это те «кирпичики», которые в этом алгоритме используются.

Разные методологии могут включать в себя одни и те же инструменты, но в разной компоновке. Часто можно увидеть, как при реализации Scrum прибегают к инструментам XP (экстремального программирования) или Kanban. И это нормально, так как все они отвечают ценностям Agile, и позволяют сделать рабочий процесс создания продукта гибким.

Если рассуждать о конкретных Agile-подходах, которые сейчас получили наибольшее распространение, то это, безусловно, Scrum и Kanban. Другие — FDD, XP, RUP и так далее, либо сошли со сцены, либо редко применяются целиком, но отдельные инструменты из их арсенала задействуются при реализации Scrum или Kanban.

Методологии гибкой разработки

Миф 5. Scrum — это как быстро и дёшево сделать продукт


Насчёт «быстро» всё верно, а вот насчет «дёшево» — нет. Судите сами: вам нужно сформировать полноценную команду, выделив в неё на 100% нужные компетенции. Эти люди будут заняты только разработкой вверенного им продукта и ничем другим, а значит, придётся либо нанять таких специалистов, либо «оторвать» их от какого-то отдела. То же самое касается бизнес-части: хочешь, не хочешь, а потребуется выделить владельца продукта, который 50–80% своего времени будет уделять только этой команде и её продукту.

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

Спринты

Спринт — термин из арсенала Scrum. Это фиксированный отрезок времени, в течение которого команда делает часть продукта, имеющую ценность для заказчика. Смысл — в том, что за каждый спринт команда должна сделать ещё один шаг, к цели, который можно «пощупать», оценить по реальному результату. Чаще всего длина спринта составляет 2 недели.


Спринт включает 4 обязательных встречи: планирование, реализация, релиз, спринт-ревью с ретроспективой. Кроме того, каждый день проводятся короткие встречи (stand-up meetings), на которых члены команды в едином формате «сверяют часы» и согласуют свои действия. Добавлять новые задачи в открытый спринт нельзя — это приучает команду к планированию и страхует от возникновения управленческого хаоса.

Миф 6. Канбан — это доски с вывешенными на них задачами


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

Если в двух словах, то главный смысл Канбана — в том, чтобы:

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

Миф 7. Scrum и Канбан можно насадить в любых проектах и компаниях


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

При этом, алгоритм прививания Scrum и Канбан — разный.

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

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

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

Миф 8. Scrum рассчитан только на проекты, которые делаются с нуля


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

Например, один из создателей Scrum Джефф Сазерленд в своей книге «Scrum: The Art of Doing Twice the Work in Half the Time» рассказывал, как он применил Scrum для разработки автоматизированной системы учёта данных ФБР. Когда он взялся за проект, разработка шла четвёртый год, ни одну функцию не довели до релиза и ни конца, ни края проекту не было видно. Джеффу удалось радикально ускорить разработку и сделать её прозрачной для заказчиков. Через полгода увидела свет первая рабочая версия продукта, а в течение двух лет разработка была успешно завершена.

Пара слов о книге Джеффа Сазерленда

Scrum: The Art of Doing Twice the Work in Half the Time. В русском переводе — «Scrum: революционный метод управления проектами». Впервые изданная в 2014 году, книга описывает предпосылки к созданию методологии, её базовые принципы, инструментарий и примеры внедрения. За 20 лет, прошедшие с тех пор, как автор книги Джефф Сазерленд и Кен Швайбер системно описали концепцию Scrum, они приложили немало усилий к тому, чтобы распространить методологию за пределы IT-отрасли и поставить её на службу нетехнологическим компаниям — финансовым, промышленным и так далее.


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


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

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

UPD. А вот и продолжение: Все дело в Agile — 2: особенности внедрения гибкой разработки

Нет времени объяснять, материал бескорыстно и с любовью подготовила команда Mail.Ru Cloud Solutions.

habr.com

Как рассказать что такое Agile на заводе? Agile методология.

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

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

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

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


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

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

ru.yougile.com

методология, команда, оценка эффективности — статьи на Skillbox

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.

Курс «Управление Digital-проектами»

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

  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

skillbox.ru

Как использовать Agile и Scrum для управления проектами — руководства на Skillbox

запись вебинара

 1ч. 40 мин.

статья

 10 мин.

Экономия времени

 1ч. 30 мин.

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

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

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

Плюсы методологии:

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

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Scrum — это метод управления проектами, он входит в философию Agile. Ключевое отличие от классической, водопадной схемы создания ПО заметно сразу — для начала разработки не нужно техническое задание.

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

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

Удобно вести бэклог задач в Trello или Excel.

Лайфхак — обратите внимание на столбец Приоритет на примере. Используйте не привычный список 1, 2, 3, 4. Попробуйте четырехзначные цифры — так вы сможете просто добавить строку между ними и выставить подходящий приоритет. Например, между 1 000 и 2 000 напишите 1 050.

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

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

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

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

Сделайте список версий продукта — от ПО с минимумом функций до полностью реализованного. Укажите к каждой версии прогноз по сроку выполнения.

Так выглядит бэклог со спринтами.

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

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

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

Член команды разработки, отвечающий за выполнение ежедневных процедур и за соблюдение интересов команды. Этот человек фиксирует дедлайны и начало спринта, добавляет оценки, отчитывается перед заинтересованными лицами об этапах проекта. Растите scrum-мастера внутри команды.

Команда разработки

Люди, которые непосредственно создают и тестируют код. 

К разработчикам есть несколько требований:

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

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

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

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

  • Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
  • Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.
Стройте график планового и фактического расхода времени на задачи. Через несколько спринтов столбцы станут примерно одинаковыми.

В Scrum от сотрудников требуется минимальная отчетность. Каждый день человек должен ответить на три вопроса:

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

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

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

Все идеи должны быть измеримы — например, «Ребята, давайте добавим серверов». Предложение просто работать лучше — не идея.

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

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

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

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

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

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

Работать по системе можно даже на бумаге. Отлично подходит и таблица в Google Docs. Создайте свою рабочую область вручную или попробуйте специальные сервисы:

  • Trello — подходит для маленьких проектов, быстро и удобно.
  • Scrumban — есть разные доски, вложенные задачи и подзадачи. Удобно для средних и маленьких проектов.
  • Jira — есть версионность, удобно для больших и долгих задач. Поддерживает массу типов разработки. Попробуйте, она вам понравится.
  • Научиться вести бэклог и расставлять приоритеты.
  • Проводить спринты.
  • Формировать стабильную и постоянную команду, решать трудности, растить внутри группы scrum-мастера.
  • Контролировать работу с помощью диаграммы сгорания проекта.
  • Организовать работу — каждый день интересоваться делами команды, проводить ретроспективу и закладывать время на тикет с запасом.
  • После каждого спринта демонстрировать проект.
  • Изучить инструменты и найти самый удобный.

Теперь вы знаете основы Agile и Scrum и можете начать внедрять их в реальные проекты. Но для эффективной работы с командой этого мало — нужно уметь делать это осмысленно, знать тонкости методологий и не теряться в сложных моментах. Всему этому учат на курсе Skillbox. Одновременно с обучением сможете использовать полученные навыки в работе.

Курс «Руководитель digital-проектов»

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

  • Живая обратная связь с преподавателями
  • Неограниченный доступ к материалам курса
  • Стажировка в компаниях-партнёрах
  • Дипломный проект от реального заказчика
  • Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

skillbox.ru

Гибкая методология разработки (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 — один из самых распространенных подходов гибкой разработки программного обеспечения, определяет правила управления процессом разработки с применением существующих практик разработки. Упор осуществляется на вовлеченность Заказчика в процесс (возможность после каждого этапа менять или уточнять требования к создаваемому продукту), что позволяет вовремя определить отклонения и внести необходимые изменения.

Организация: см. авторов
Сайт организации: http://agilemanifesto.org
Страны: все страны

mahamba.com

Как разработать “проект-огонь” с методологией Agile?

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

Что такое Agile?

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

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

Термин впервые употребили в 2001 году в США в штате Юта во время собрания 17 разработчиков, которые обсуждали свои идеи и программные подходы. Совокупность ценностей и принципов, предложенных ими, легла в основу Манифеста гибкой методологии разработки.

Что такое методология Agile в разработке программного обеспечения? 12 принципов Манифеста методологии

Как пользоваться Agile?

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

6 этапов Agile-разработки:

  • План. После того, как определена идея, проектная группа должна спланировать основной функционал. Главная цель этого этапа заключается в грамотном разделении идеи на разные части.
  • Анализ требований. Этот этап подразумевает постоянные встречи с менеджерами и пользователями с целью выявления потребностей и задач бизнеса. Важно отмечать все детали. Например, кто будет пользоваться продуктом и для чего. Требования должны быть измеримыми и актуальными.
  • Дизайн/разработка. После определения требований, можно работать с дизайном программного обеспечения и думать о том, как продукт будет выглядеть в конечном результате.
  • Внедрение, кодирование и развитие. А также создание и начальное тестирование основных функций.
  • Тестирование. Специалисты проверяют код, чтобы убедиться, что продукт соответствует потребностям клиента. Этот этап включает в себя тестирование модулей, интеграций и систем.
  • Выпуск. После всех видов тестирования, продукт передается заказчику.

Что такое гибкая методология разработки?

Инструменты Agile сконцентрированы на гибкости и усовершенствовании. Здесь мы объединили несколько основных преимуществ методологии Agile.

Как это работает? 6 ключевых преимуществ Agile для менеджеров проектов:

  1. Приспособиться к изменениям в ходе реализации проекта с более короткими циклами планирования не составляет труда. Вы всегда можете уточнить и изменить приоритеты по отстающим вопросам. Также позволить команде вносить изменения в проект.
  2. Конечная цель может быть невидимой. Методология Agile может быть полезна для проектов с неопределенными конечными целями.
  3. Высокое качество и быстрые стандарты доставки. Из-за разбивки проекта на итерации, команды могут быть сфокусированы на разработке и тестировании.
  4. Сильное взаимодействие команды. Методология обеспечивает прямое взаимодействие. Люди могут работать вместе и совместно брать на себя ответственность.
  5. Клиенты могут работать в тесном сотрудничестве с командой. Они могут внести свой реальный вклад и оказать воздействие на продукт.
  6. Постоянное улучшение. Проекты на основе метода Agile подразумевают обратную связь от пользователей и членов команды.

Читайте также: Критерии успешности проекта.

5 главных недостатков метода

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

  1. Процесс планирования может быть менее конкретным. Иногда бывает трудно определить конкретную дату поставки. Некоторые элементы, запланированные к реализации, могут не быть завершены в срок. Это происходит потому, что менеджеры часто вносят изменения приоритетов при решении текущих задач.
  2. Команда должна знать все детали и факты. Как правило, команды Agile-проектов небольшие, и их участники должны быть «подкованы» в разных областях.
  3. Время для развития. Успешное Agile-движение происходит тогда, когда команда полностью посвящена проекту.
  4. Команды часто забывают о документации. Лучше всего найти баланс между бумажными вопросами и личными встречами.
  5. Конечный продукт может сильно отличаться от того, что было изначально задумано. Вы можете добавлять новые итерации, поскольку метод подразумевает гибкость.

Основные обязанности менеджера Agile-проектов:

  • Поддержание всех активностей и ценностей в проектной команде.
  • Устранение помех и препятствий.
  • Проведение и модерирование всех совещаний.
  • Обсуждая путей преодоления препятствий.
  • Работа с приоритетами, усиление отстающих вопросов в рамках процессов.
  • Мотивирование. Руководители проектов должны быть основными мотиваторами для своих команд.

Читайте также: О методе критического пути (critical path method) и иерархической структуре управления.

Сравнение гибких методологий

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

Список методов Agile:

XP (Extreme Programming)

Extreme Programming представляет собой специфический метод разработки программного обеспечения, который предназначен для повышения оперативности и качества обслуживания для развития потребностей клиентов. Он выступает за частые «выпуски» в коротких циклах разработки.

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

FDD (Feature driven development)

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

ASD (Adaptive system development)

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

Kanban

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

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

Crystal Clear

Crystal Clear – еще один пример методологии Agile. Он чаще всего используется командами из 6- 8 разработчиков. Crystal Clear преимущественно сфокусирован на людях, а не на процессах.

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

Scrum

Scrum лучше всего отражает функции Agile-управления. Спринты длятся 1-2 недели и позволяют командам поставлять программное обеспечение на регулярной основе.

Scrum-разработка: участники процесса

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

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

5 ресурсов для работы с Agile-проектами

JIRA

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

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

HP Agile Manager

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

GanttPRO

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

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

Basecamp

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

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

Bipulse

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

Пример работы с проектом в JIRA:

Пример работы с проектом в GanttPRO:

А вы использовали методологию Agile в своей работе?

Что вы можете сказать о результатах вашего проекта?

Получился ли тот самый “огонь”?!

spark.ru

Отправить ответ

avatar
  Подписаться  
Уведомление о