Гибкая программа что это

Agile

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

История зарождения Agile

Изначально термин Agile относился к ИТ-индустрии и употреблялся в контексте гибких методологий разработки программного обеспечения: экстремального программирования (XP), Crystal Clear, DSDM, Feature driven development (FDD), Scrum, Adaptive software development, Pragmatic Programming, быстрая разработка приложений (RAD) и других адаптивных методов, суть которых состоит в ускорении процессов создания продукта путем микропланирования, коротких производственных циклов и оперативного реагирования на изменения. Ключевой смысл этих Agile-практик отражен в манифесте гибкой разработки программного обеспечения (Agile Manifesto), который был выпущен инициативной группой программистов в феврале 2001 года в американском штате Юта [1]. Эта дата считается началом повсеместного распространения эджайл как практики управления проектами и организации бизнес-процессов не только в ИТ-отрасли, но и в других прикладных областях. Дополнительным драйвером развития Agile-подходов является микросервисная архитектура приложений, когда весь проект состоит из набора независимых слабосвязанных модулей, которые взаимодействуют друг с другом через открытые API-интерфейсы [2]. Популярность облачных технологий (SaaS-, PaaS-, IaaS- и других сервисных моделей) также стимулирует распространение эджайл.

Гибкие технологии управления ИБДА РАНХиГС

Гибкость против жесткости: Agile vs Waterfall

В отличие классического Project Management (PM), когда проект жестко регламентирован заранее установленными требованиями (контрактами), Agile предполагает быстроту реагирования, а также гибкую адаптацию к внешним и внутренним изменениям. Это достигается с помощью итеративной разработки продукта и эффективного межличностного общения. В водопадной (каскадной) модели PM, которая считалась стандартом де-факто, проект состоит из функциональных задач, где каждая последующая работа четко регламентирована и начинается строго после окончания предыдущей, например, тестирование начнется только после того, как написан весь код. Жесткая определенность и обилие регламентирующей документации обусловливают длину производственного цикла. При этом продукт считается готовым лишь после выполнения всех этапов [3].

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

Вебинар: «Руководство по гибкой логике: советы и примеры реализации»

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

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах Agile Manifesto [1]:

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

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта. Scrum-мастер управляет процессом организации разработки по Agile-принципам: проводит общие собрания (meetings, митинги), мотивирует и поддерживает команду.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

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

Канбан, как и другие практики бережливого производства, пришедшие из Японии, направлен на достижение баланса и выравнивание нагрузки исполнителей. Эффективность работы оценивается по среднему времени жизни задачи, от начальной до конечной стадии. Если задача прошла весь путь быстро, то команда проекта работала продуктивно и слаженно. Иначе – необходимо решать проблему: искать, где и почему возникли задержки и чью работу надо оптимизировать [4].

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Где, как и кем используется Agile

Сегодня эджайл применяется не только в управлении ИТ-проектами, а используется как эффективная практика организации труда небольших групп и творческих команд вместе с либеральными и демократическими методами менеджмента [1]. В частности, одной крупной телеком-компании благодаря внедрению Agile-практик в процессы кросс-функциональное взаимодействия всего за 3 месяца удалось достичь следующих результатов [6]:

• рост от продажи устройств на 45%;
• сокращение сроков запуска рекламных кампаний в 2 раза;
• рост плановой ежемесячной выручки от разработки продуктов на 20%;
• в 1,5 раза больше запущено рекламных кампаний по направлению В2В.

Гибкие практики управления также активно применяются и в банковском секторе. Например, за год в проектном офисе ЦентроБанка в 2 раза увеличилась скорость достижения результатов, повысилась вовлеченность сотрудников, улучшилась прозрачность и управляемость изменений [7]. Подобным опытом делится Райффайзен-Банк [8] и Сбербанк [9].

Предприятия нефтегазовой промышленности также активно используют Agile для повышения эффективности своих бизнес-процессов, открывая новые офисы и выстраивая работу филиалов по адаптивным принципам [10]. Кроме того, в рамках государственных проектов цифровизации, идеи и принципы эджайл используются в бюджетных и правительственных организациях [11]. В частности, правительство Новой Зеландии, Норвегии и США изучали методы Scrum для внедрения в своих министерствах [12].

Источники

1. https://ru.m.wikipedia.org/wiki/Гибкая_методология_разработки
2. https://ru.wikipedia.org/wiki/Микросервисная_архитектура
3. https://ru.m.wikipedia.org/wiki/Каскадная_модель
4. https://rb.ru/story/agile-scrum-kanban/
5. https://habr.com/ru/company/dataart/blog/290340/
6. https://onagile.ru/industries/telecommunication/agile-in-telecom
7. http://www.tadviser.ru/index.php/Проект:Agile_в_Банке_России
8. http://www.tadviser.ru/index.php/ Статья:Интервью_с_CIO_Райффайзенбанка_Андреем_Поповым
9. https://vc.ru/sberbank/38179-agile-na-11-000-sotrudnikov
10. https://vc.ru/office/37191-shtab-kvartira-ofis-kompanii-gazprom-neft-v-sankt-peterburge
11. http://bujet.ru/article/375271.php
12. https://biz.mann-ivanov-ferber.ru/2016/05/24/kak-agile-ispolzuyut-v-pravitelstve-norvegii-novoj-zelandii-i-ssha-ili-o-vazhnosti-izmenenij/

Источник: www.bigdataschool.ru

Гайд по Agile: как работать, несмотря ни на что (на примере маркетинга)

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

1233 просмотров

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

Что такое Agile?

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

Немного истории

Понятие Agile как свод принципов появилось в 2001 году в США, штат Юта. Команда разработчиков занималась развитием и внедрением разных методик для роста эффективности работы, например, Каскадной модели и Экстремального программирования. Эти программисты объединили правила реакции на изменения условий и выработали манифест Agile, а затем создали некоммерческую организацию Agile Alliance, цель которой – продвигать и внедрять «гибкие» технологии управления процессами.

Разработчики и инженеры, которые были у истоков методологии Agile

Манифест Agile: 4 основных принципа

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

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

Раскроем каждый принцип подробнее.

Принцип 1. Коммуникация важнее инструментов и процессов

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

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

На отношениях вовне этот принцип реализуется через ориентированность на человека в создании продукта: в центре всех процессов стоят потребности аудитории.

Принцип 2. Работающий продукт важнее документации

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

Принцип 3. Диалог с заказчиком важнее договоров

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

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

Принцип 4. Изменения и адаптация важнее следования плану

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

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

Диана Тананова, руководитель отдела маркетинга, Веб-Центр
Чем полезна методика Agile для компаний

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

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

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

Agile на практике
✔ Цикл работы

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

Цикл работы по Agile

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

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

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

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

✔ Минимально жизнеспособный, или МЖП

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

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

5 признаков, что внедрение Agile прошло успешно

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

❌ Кому противопоказана гибкая система Agile

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

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

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

Игорь Баннюк, руководитель отдела продаж, Веб-Центр

• Вы постоянно внедряете инновации в процессы и продукты.
• Вы тесно сотрудничаете с заказчиком на протяжении всё работы.

Вам точно не подойдет и даже будет вреден гибкий подход, если:

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

Как применять Agile в маркетинге

1. Все, что помогает компании расти и привлекать новые деньги – оправдано и должно быть задействовано. В то же время не забывайте: люди работают для людей, остальное вторично. При разработке стратегии продвижения у вас должны быть ответы на эти вопросы: • Какие проблемы клиентов мы решаем своим продуктом? • Как нам стать незаменимыми? • Почему мы лучше конкурентов?
2. Лучше провести много маленьких экспериментов, чем один большой. Тестируйте гипотезы чаще.
3. Корректируйте стратегию, исходя из данных, а не мнений. Чтобы получать данные, настраивайте каналы обратной связи от вашей команды.
4. Выстраивайте сотрудничество с клиентом, а не стройте жесткую иерархию.
5. Запускайте адаптивные кампании вместо больших и сложных.
6. Изучайте клиентов: отзывы и реакции – основа для изменений.

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

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

Источник: vc.ru

«Гибкая разработка»: кратко о методологиях Agile

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

Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.

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

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

/ Flickr / Sebastian Sikora / CC

Scrum

Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

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

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

На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

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

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

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

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

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

Extreme Programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

1. Разработка через тестирование (Test-driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous integration)
6. Рефакторинг (Design improvement)
7. Частые небольшие релизы (Small releases)
8. Простота проектирования (Simple design)
9. Метафора системы
10. Коллективное владение кодом (Collective code ownership)
11. Стандарт оформления кода (Coding standard)
12. 40-часовая рабочая неделя (Sustainable pace)

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.

/ Flickr / U.S. Army / CC

Канбан

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

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

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

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

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

P.S. Еще несколько статей из нашего корпоративного блога:

• IT Operations Management – управление ИТ-инфраструктурой
• Как внедрить процесс управления конфигурацией. Часть 1
• Как внедрить процесс управления конфигурацией. Часть 2

Источник: habr.com

Лучшие инструменты для Agile управления проектами в 2022 году

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

Что такое project-менеджмент и для чего он нужен

Цель любого проекта – воплотить идею. Project-менеджмент нужен, чтобы каждый проект достигал цели.

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

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

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

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

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

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

Традиционный и гибкий методы управления проектами

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

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

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

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

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

Обычно гибкая разработка состоит из 6 этапов:

1. Исследование. В этот период команда изучает, что и для кого следует сделать, что уже есть на рынке в этом направлении.
2. Создание прототипа. В начале вполне достаточно примерной схемы работы продукта.
3. Разработка. Это уже прямая работа над продуктом, к которой подключена вся команда.
4. Тестирование. В гибких методологиях разработка и тестирование идут параллельно, чтобы максимально быстро увидеть, что идет неверно и исправить.
5. Релиз. Это момент, когда готовый продукт представляют аудитории, которая будет им пользоваться.
6. Мониторинг. Целью является анализ того, насколько продукт пользуется спросом, наблюдаются ли в его работе недостатки и т.д.

Project-менеджер выбирает методологию с учетом поставленных целей и определенных ресурсов.

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

Типы гибкого управления проектами

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

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

Scrum

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

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

Kanban

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

Экстремальное программирование (eXtreme Programming — XP)

Фокусируется на технических аспектах разработки программного обеспечения. Этот тип управления проектами подходит только для IТ-отрасли. ХР сосредоточено вокруг следующих процессов: кодирование, тестирование, дизайн и коммуникация. В этой методологии работают преимущественно senior-специалисты.

Автор подхода Кент Бек предложил 12 практик работы над проектом: игра в планирование, короткие релизы, метафора системы, простой дизайн, пользовательские тесты, рефакторинг, парное программирование, общее владение кодом, постоянная интеграция кода, 40-часовая неделя, постоянная связь с заказчиком, стандарты кодировки. Однако экстремальное программирование не эффективно в больших проектах.

Adaptive Project Framework — APF

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

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

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

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

Worksection

Платформы: Web, Windows, iOS, Android.

Особенности: Это действительно гибкий таск-менеджер, который подойдет командам разных размеров. С ним удобно работать над несколькими проектами одновременно. Есть диаграммы Ганта, доски Канбан, тайм-трекер и наглядный Дашборд, показывающий на одном экране положение дел в проекте. Также предусмотрены встроенные интеграции с GoogleDocs, Slack, Telegram, Viber, CRM-системами.

Недостатки: Отсутствие оффлайн-версии и не всегда идеальная работа мобильной версии.

Тарифы: Есть бесплатный вариант для 5 пользователей и 2 проектов. Платные пакеты стоят от $29 до $199 в месяц. Вы можете протестировать выбранный пакет в течение 14 дней без оплаты.

Рейтинг на Capterra: 4,9 из 5.

ClickUp

Платформы: Web, iOS, Android, Windows, Mac, Linux.

Особенности: Функциональный продукт имеет много инструментов, полезных в гибкой разработке: чаты, вики-документы, интеграции с Google Workspace, Dropbox, Zapier. Можно настроить фильтрацию по календарю, таймлайну задач.

Недостатки: Не всех устраивает качество работы мобильной версии.

Тарифы: Если использовать только 3 доски, за продукт можно не платить. Более продвинутые тарифы стоят от $5 в месяц. Также есть пробный период на 14 дней.

Рейтинг на Capterra: 4,7 из 5.

Smartsheet

Платформы: Web, iOS, Android.

Особенности: Среди гибких инструментов управления проектами этот выбирают те, кому нравится работать с таблицами. Также здесь есть диаграммы Ганта, календарь и напоминания, интеграция с Jira, продуктами Google и Microsoft.

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

Тарифы: Продукт стоит от $7 за пользователя в месяц. Есть бесплатный триал.
Рейтинг на Capterra: 4,5 из 5.

Teamwork

Платформы: Web, iOS, Android, Windows, Mac, Linux.

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

Недостатки: Некоторым интерфейс кажется слишком сложным. Есть проблемы в работе API.

Тарифы: Для пользователей, работающих с 1 или 2 проектами, есть бесплатная версия. Также можно воспользоваться 30-дневным триал-периодом. Платные тарифы обойдутся от $10 до $18 за пользователя в месяц.

Рейтинг на Capterra: 4,5 из 5.

ProofHub

Платформы: Web, iOS, Android.

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

Недостатки: Не всем нравится интерфейс и навигация, оповещения бывают чрезмерно назойливыми.
Тарифы: Использование продукта обойдется в $45 в месяц. Есть бесплатный тестовый период.
Рейтинг на Capterra: 4,5 из 5.

Atlassian Jira

Платформы: Web, iOS, Android, Windows, Mac, Linux.

Особенности: Один из самых популярных среди разработчиков инструмент для agile-менеджмента. Доски Канбан и Scrum, удобные отчеты, адаптированные для работы по спринтам функции, задачи с разными уровнями приоритета и многое другое.

Недостатки: Из-за обилия функций пользователям иногда сложно разобраться в интерфейсе и найти то, что им нужно.

Тарифы: Команды, имеющие не более 10 работников, могут использовать инструмент без оплаты. Остальные должны платить $7 в месяц. Чтобы оценить функционал, можно подключить триал-версию.

Рейтинг на Capterra: 4,4 из 5.

Active Collab

Платформы: Web, iOS, Android, Windows, Mac, Linux.

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

Недостатки: Не всем достаточно функций в базовой версии трекера, есть сложности в настройке интеграции с календарем.

Тарифы: Для мини-команд с 3 и менее сотрудников продукт бесплатный. Платные тарифы стоят от $11 за 3 участника в месяц. Доступный бесплатный тестовый период.

Рейтинг на Capterra: 4,5 из 5.

Axosoft

Платформы: Web, iOS, Windows, Mac, Linux.

Особенности: Удобный инструмент для планирования спринтов, отслеживания багов и работы с ними. Также есть возможность работы с вики-документами и приема обращений от клиентов.

Источник: worksection.com