Agile инструменты: Топ-5 инструментов управления Agile-проектами / DataArt corporate blog / Habr – Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Содержание

Топ-5 инструментов управления Agile-проектами / DataArt corporate blog / Habr

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Agile-манифест

Испытывают ли разработчики ПО необходимость в инструментах для управления проектом? Могут ли такие инструменты помочь в написании качественного продукта?

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

Идеальный рабочий процесс.

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

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

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

Эффективность и качество разработки зависят от целого ряда факторов:

индивидуальная продуктивность разработчиков;

стабильность выпускаемого релиза

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

использование удаленных ресурсов;

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

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

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

Обзор

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

В опросе участвовали 39 человек из 32 проектов, их роли распределились следующим образом:

Роли респондентов.

Среди инструментов управления Agile-проектами самыми популярными стали:

Jira

Version One

Rally

Spreadsheet

Параметр
Лицензия	Proprietary/Free community licenses for open source and academic projects	Proprietary, hosted	Proprietary/Free trial	Proprietary, Commercial	ICU license
Цена	Гибкая ценовая политика/бесплатная пробная версия	Гибкая ценовая политика/бесплатная пробная версия	Гибкая ценовая политика/бесплатная пробная версия	Гибкая ценовая политика	бесплатная
Платформа	Web-Based/Installed	Web-Based	Web-Based	Web-Based/Installed	Web-Based
Предполагаемые пользователи	фрилансеры крупный/средние/мелкие компании, некоммерческие компании	фрилансеры крупный/средние/мелкие компании, некоммерческие компании	фрилансеры крупный/средние/мелкие компании	крупный/средние/мелкие компании	фрилансеры, мелкие компании
Управление бэклогом через Drag-and-drop	Полная поддержка	Полная поддержка	Полная поддержка	Полная поддержка	Отсутствует
Просмотр доски задач	Присутствует	Присутствует	Присутствует	Присутствует	Присутствует

Диаграмма сгорания задач на итерацию	Присутствует	Присутствует	Присутствует	Присутствует	Отсутствует
Epics (hierarchy of backlog items)	Частичная поддержка	Полная поддержка	Частичная поддержка	Частичная поддержка	Отсутствует
Поддержка Rollup’ов	Частичная поддержка	Полная поддержка	Частичная поддержка	Частичная поддержка	Отсутствует
Планирование и отслеживание релиза/итерации	Частичная поддержка	Полная поддержка	Полная поддержка	Полная поддержка	Частичная поддержка
Роадмаппинг продукта(multiple releases)	Отсутствует	Полная поддержка	Полная поддержка	Отсутствует	Частичная поддержка
Несколько продуктов/проектов	Полная поддержка	Полная поддержка	Полная поддержка	Полная поддержка	Частичная поддержка
Portfolio planning	Отсутствует	Полная поддержка	Полная поддержка	Частичная поддержка	Отсутствует
Управление процессом тестирования (Acceptance and Regression)	Частичная поддержка	Полная поддержка	Полная поддержка	Полная поддержка	Частичная поддержка
Средства оповещения	Email	Email	Email	Email	Отсутствует
Отслеживание сдерживающих факторов	Отсутствует	Полная поддержка	Полная поддержка	Полная поддержка	Частичная поддержка
Отслеживание дефектов	Частичная поддержка	Полная поддержка	Полная поддержка	Полная поддержка	Частичная поддержка
Пользовательские роли	Отсутствует	PO, SM, Team Member, Stakeholder, plus custom roles.	SM, PO, Team Member.	Отсутствует	Отсутствует
Интеграция, API(s), SDK	Присутствует(REST API)	SDK.Java, SDK.NET, SDK.Python, SDK.Javascript	SDK.Java, SDK.NET, SDK.Ruby, SDK.Nodejs	SDK.Java, SDK.NET	SDK.Java, SDK.NET
Поддержка	Email/Phone Community Website	Email/Phone Community Website	Email/Phone Community Website	Email/Phone Community Website	форумы
Дополнительный сервис	Отсутствует	Тренинги и сертификация	Отсутствует	Тренинги и сертификация	Отсутствует
Документация	****	**	**	**	***
Удобство использования	***	**	***	***	***
Плюсы	Большое пользовательское сообщество, поддержка различных языков,, 600+ plugins and add-on, мобильный	Бесплатная пробная версия для команды до 10 человек. Обеспечивает поддержку работы кросс-функциональных команд; проработанный интерфейс для планирования, позволяющий осуществлять трекинг эпиков, юзер-стори и проектов	Обеспечивает поддержку для работы кросс-функциональных команд; Наличие roll-up для юзер стори и фич; Наличие интегрированного в среду инструмента для менеджмента дефектов	Обладает полезными фичами для управления agile проектами	Отлично подходит для небольших команд и относительно простых процессов
Минусы	Недостаточно информативный бэклог и средства по sprint management tools отсутствие burndown и информативного репортинга из коробки	Сложный User Interface Отсутствие возможности работать с мобильного девайса; высокий порог вхождения. Требуется приложить немало усилий, чтобы использовать инструмент на всю катушку	Сложный юзер-интерфейс, нет простого механизма для линковки стори и фич к айтемам более высого уровня. Отсутствие удобного средства доя репортинга из коробки	решение очень сильно завязан на другие продукты из линейки Microsoft	Много ручной работы

VersionOne

URL: www.versionone.com
Ключевые особенности VersionOne

управление Agile Portfolio;

репортинг и аналитика;

планирование и роадмаппинг продукта;

планирование и роадмаппинг релиза;

планирование спринта;

управление процессом тестирования;

открытый API для интеграции.

Краткий обзор VersionOne

Универсальный инструмент управления проектами и командами любого размера. VersionOne считаются пионерами в производстве ПО для управления Agile-продуктами. По сей день они остаются компанией, всецело преданной философии Aglie.

Тарифы VersionOne
www.versionone.com/pricing_and_editions

Team	Catalyst	Enterprise	Ultimate
10 user pack free	20 user pack($175/month)	$29 user/month	$39 user/month

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

Преимущества использования

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

Скриншоты

JIRA

Ключевые особенности JIRA

Контроль проекта.

Agile, Scrum, Kanban.

Планирование проекта.

Учет ошибок (Issue Tracking).

Возможность интеграции с кодом.

Служба техподдержки.

Доступность с мобильных девайсов.

Возможность кастомизации рабочего процесса.

Составление отчетности.

Аутентификация через LDAP и Active Directory.

Система учета ошибок (Bug Tracking).

Интеграция с Git.

1000+ всевозможных дополнений, расширений, плагинов.

Email-уведомления.

Возможность самостоятельно определять и изменять вычислительные потребности (On Demand).

Бесплатна для Open source-проектов.

Краткий обзор JIRA

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

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

Отслеживание проекта: JIRA позволяет централизованно управлять всеми проектами, не теряя из виду общую картину.

Разработка ПО

После системы контроля версий JIRA — самое важное приложение в для команды разработчиков, поскольку позволяет достаточно легко адаптироваться к использованию scrum и Kanban.

Рабочий процесс

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

Работа внутри команды

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

Сбор ошибок

С JIRA Service Desk команда получает современный гибкий сервис поддержки, который способен оптимально организовать запросы от клиентов.

Детали

Потенциальные пользователи	Крупные предприятия, предприятия среднего бизнеса, некоммерческие организации, государственные органы, предприятия малого бизнеса
Поддерживаемые страны	Азия, Австралия, Канада, Китай, Европа, Индия, Латинская Америка, Ближний Восток и Африка, Соединенное Королевство, Соединенные Штаты Америки
Поддерживаемые языки	Китайский (традиционный), чешский, датский, английский, французский, немецкий, итальянский, японский, польский, португальский, русский, испанский
Варианты поддержки	FAQs, Forum, Knowledge Base, Online Support, Phone Support, Video Tutorials
Категории	Project Management Software • Project Collaboration Software • Issue Tracking Software • Agile Project Management Software • Startup solutions Software •Bug Tracking Software

Тарифы JIRA
www.atlassian.com/software/jira/agile

Облако

10 users	15 users	25 users	50 users	100 users	500 users	2,000 users
$ 10/mo	$ 25/mo	$ 50/mo	$ 100/mo	$ 150/mo	$ 250/mo	$500/mo

Сервер

10 users	25 users	50 users	100 users	101+ users
$ 10 Starter	$ 600	$ 1,100	$ 2,000	$4,000

Механизм ценообразования: подписка.
Бесплатная пробная версия: доступна.

Преимущества использования:

Agile в масштабе

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

Движок для создания рабочего процесса.

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

Пользовательский опыт

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

Гибкие панели мониторинга (Dashboards)

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

Мощный инструмент поиска и отчетности

Используйте JIRA’s Query Language (JQL) с автозаполнения для создания расширенных запросов. Такие запросы позволяют отслеживать статус проекта, включать необходимые метрики в отчеты, отслеживать прогресс команды.

Варианты развертывания

Доступны инсталлеры под Windows и Linux для решения OnPremise. Есть возможность начать с JIRA OnDemand а позже перейти на OnPremise.

Интеграция

Получите больше от JIRA с гибким REST и Java API — плюс более 600 плагинов и дополнений в Atlassian Marketplace, чтобы соединиться с приложениями и инструментами, которые вы используете каждый день.

Скриншоты

Rally Software

Ключевые особенности Rally Software

Гибкая ценовая политика.

Дополнения и расширения Rally Apps.

Краткий обзор Rally Software

Rally Software — инструмент управления проектами, которая использует Agile- и lean-методы, чтобы помочь предприятиям в разработке ПО. С акцентом на Aglie-методологии, ралли помогает предприятиям всех размеров постепенно внедрять полезные практики, позволяющие сокращать циклы разработки и улучшать сотрудничать в распределенных командах.

Под влиянием Agile и Lean принципов, Rally представляет первое решение для управления Agile-портфолио, которое позволяет:

оставаться на связи и сотрудничать с заинтересованными сторонами для уточнения новых идей;

ралли позволяет расставить приоритеты работы в соответствии с его значением и поддерживает стратегическое планирование;

перераспределять ресурсы развития, чтобы максимизировать рост портфолио;

улучшать управление на основе компромиссных решений.

Скриншоты

Тарифы Rally Software

Механизм ценообразования: Фримиум, подписка

Community	Enterprise	Unlimited
10 user, 5 projects	$35 user/month	$49 user/month

FREE for up to 10 users

Преимущества использования

приоритизация заданий с акцентом на прибыль;

планирование разработки с учетом инвестиционных планов;

оценка статуса разработки с точки зрения бизнеса;

реалистичный роадмэп;

управления на основе базы.

TFS

Ключевые особенности

Система контроля версий.

Agile-планирование.

Управление тест-кейсами.

Репортинг.

Управлять репозиториями, выстраивать процессы, инфраструктуру тестирования и развертывания, получать статус и репортинг — все это легко с Team Foundation Server, инструментом управления жизненным циклом приложения в Visual Studio. Оно позволяет всем заинтересованным сторонам участвовать разработке, используя единое решение. Используйте TFS, чтобы управлять разнородными проектами и командами.

Система контроля версий

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

Agile-планирование и взаимодействие

Адаптируйте Agile-практики в подходящем вам темпе, используя шаблоны для Scrum, Agile или CMMI®. Можно скачать шаблоны процессов или создать собственные. Все участники проекта вовлекаются в рабочий процесс с помощью Kanban-досок и постоянно получают друг от друга обратную связь.

Билды

TFS помогает выявить ошибки и проблемы с качеством продукта на ранней стадии. Настройка непрерывной интеграции (continuous integration) с запуском интеграционных тестов повышает уверенность в качестве билдов.

А еще TFS позволяет получить информацию о статусе последней сборки и на домашней странице проекта, и через Visual Studio.

Веб интерфейс для управления тест-кейсами

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

Отчетность

Механизм репортинга в Team Foundation Server 2013 отслеживает различные виды работ, чтобы создавать отчеты на основе текущего состояния. А шаблоны для получения информации можно брать готовые или составлять самим.

TFS Цена

Покупка	Upgrade
$ 499	$ 399

Ценовая политика: подписка, бесплатная 90-дневная версия.

Скриншоты

Google Docs

Особенности

Бэклог и диаграмма сгорания продукта.

Бэклог и диаграмма сгорания для спринта.

Бэклог для сдерживающих факторов.

Burndown chart, team velocity.

Специально созданные Scrum-темплейты помогают управлять небольшим проектом. Самое главное достоинство решения — простота: не требуется никакой дополнительной инсталяции и настройки. Google Docs — отличный выбор для распределенных команд.

Скриншоты

Цена Google Docs
Ценовая модель: бесплатно (1 Гб дискового пространства).

Заключение

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

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

Есть ли сотрудники, работающие удаленно.

Насколько решение масштабируемо при росте количества пользователей.

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

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

У рассмотренных продуктов (кроме Google Docs) есть бесплатная пробная версия. За это время команда может проверить инструмент в действии на реальном проекте и посмотреть, насколько инструмент помогает в решении вопросов разработки и планирования.

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

Microsoft TFS не отстает от конкурентов. Преимущества продукта особенно ощутимы, когда команда уже использует другие решения от Microsoft.

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

Google Docs — удобный инструмент для небольших команд со сравнительно простыми процессами. Основное преимущество (кроме бесплатности) — легкость в использовании и интуитивно понятные интерфейс.

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

Автор: Евгений Толбаков.

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Agile («аджайл») — слово, которое последнее время звучит из каждого утюга. Но что такое Agile и, главное, зачем этот Agile нужен?

Если открыть толковый словарь, например, Оксфордский, то можно прочитать там, как минимум, два определения:

Able to move quickly and easily.
Able to think and understand quickly.

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

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

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

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

Фокусировка на нуждах и целях клиентов

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

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

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

Примеры подобных инструментов — Lean Canvas, Impact Mapping, User Story Mapping и другие Agile-методы описания гипотез и процессов.

Упрощение оргструктуры и процессов

Один из краеугольных камней Agile — это предельная простота. И оргструктура организации, и процессы, по которым работают люди, и правила должны быть настолько простыми, насколько это возможно. Это позволит людям сфокусироваться на своей работе, на ценности, которую они создают, а не на соблюдении регламентов и правил. Прекрасные примеры такого подхода можно найти во множестве команд, работающих по Scrum — самому популярному способу организации рабочего процесса в Agile. Фактически, все договорённости и правила команды в 10-11 человек, текущие задачи на пару недель, цели, а также стратегические планы легко могут поместиться на 2-3 листа бумаги А0. На одном листе может быть так называемый «бэклог спринта», перечень всего, что команда собирается сделать в ближайшую итерацию. Если повесить такой в помещении, где идёт работа, можно избавить себя от необходимости всё это запоминать. То же самое касается и процессов. Скажем, в Скраме место и время проведения всех встреч жестко фиксируются. Любой участник точно знает, что, например, в понедельник в 10-00 планируется ближайшая итерация, а в пятницу в 17-30 — встреча по улучшению процесса работы.

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

Примеры упрощения (и уплощения, но это тема отдельного разговора) в Agile — Scrum, Nexus, LeSS (Large-Scale Scrum, или Скрам на больших масштабах), а также сам Agile-манифест.

Работа короткими циклами

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

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

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

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

Ещё одно преимущество такого подхода, помимо раннего выхода на рынок и внесения изменений на ранних стадиях работы, — это возможность более точно измерять прогресс. Мы не просто «сделали 15% всей работы», что довольно абстрактно. Мы «сделали 15% функционала», который уже работает.

Все процессные подходы в Agile имеют короткие циклы, будь то упомянутые ранее Scrum, Nexus, LeSS, SAFe или XP, плюс необходимость работы такими циклами упомянута и в самом манифесте Agile.

Активное, системное использование обратной связи

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

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

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

Примеры, опять-таки, есть везде: ретроспективные встречи в Scrum, Kanban, Nexus и LeSS, циклы I&A в SAFe, подход к созданию продуктов Design Thinking, циклы обратной связи в DevOps и т.д.

Повышение полномочий сотрудников

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

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

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

В-третьих, это всё та же скорость. Если человек может сам, на своём месте, никого не спрашивая, решить какую-то проблему, это сокращает время принятия решений. Не надо больше отправлять вопрос «вверх» и ждать ответа от менеджмента. Это преимущество не так заметно, если у вас работает 3 человека, но если вас 30, или 300, или 3000… В больших организациях, построенных сугубо на иерархическом принятии решений, паралич воли может быть довольно частым явлением.

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

Гуманистический подход

Зачем относиться к людям по-человечески? То есть, моральная сторона дела ясна, а какую пользу это принесёт владельцу предприятия?

Ответ довольно простой. Если создание того, что вы продаёте, не требует умственного труда, а только механический действий — можете не заморачиваться. Просто платите соразмерно сделанной работе, и всё. Но как только в дело вступает мозг работников — придётся считаться с принципами мотивации умственного труда. А они говорят, что для людей важны возможность самореализации, повышения своего мастерства, принесения чего-то ценного в мир, самостоятельности в решениях и ещё ряда факторов. И человек мотивированный (не путать с человеком простимулированным!) будет вкладываться в работу сильнее, и результат будет качественнее и быстрее. Да и в целом, приятная обстановка на работе добавляет желания туда приходить и работать — с этим тоже вряд ли кто поспорит.

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

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

Agile — это не конечное состояние, а образ мышления и жизни

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

И если всё удалось: люди в компании понимают и разделяют ценности и принципы Agile и работают согласно им, — тогда менеджменту не придётся «тащить» на себе любые изменения или «пинать» работников, чтобы они начали что-то делать по-другому. Предприятие станет единым организмом, управление которым будет отнимать меньше сил и приносить больше удовольствия.
А там, где больше удовольствия от работы, и результат выше. Это касается не только специалистов, но и менеджмента, причём в ещё большей степени.

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

AGILE – гибкая система управления проектами

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

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

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Манифест Agile

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

Идеи Agile:

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

Принципы Agile:

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

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

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

Ключевые моменты в применении Agile

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

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

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

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

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

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

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

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

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

Что я делал вчера?
Чем я буду занят сегодня?
Что мешает мне работать?

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

Четко обозначается значение проекта
В процессе реализации активно участвует клиент
Общий объем работ выполняется пошагово
Ориентироваться следует на конкретный результат
Численность одной рабочей группы: от 7 до 9 человек

В настоящее время проект-менеджмент с поддержкой Аджайл по большей части распространен в IT-сфере, однако и деловая сфера его начинает осваивать. Эта система применяется в обучении, маркетинге, бизнесе. Гибкое управление проектами берется на вооружение множеством компаний и государственных структур.

Примеры: правительство Новой Зеландии, правительство Нигерии, Норвежский пенсионный фонд, компания Return Path (программное обеспечение), компания Oreo (производство печенья), компания Aviasales (крупнейший поисковик авиабилетов), компания Hewlett-Packard (крупнейшая американская IT-компания), «Сбербанк» (наверное, знаете, что это).

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

Плюсы и минусы Agile

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

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

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

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

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

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

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

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

Внедрение Agile

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

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

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

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

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

Заключение

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

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

Agile–инструменты — инструменты в гибких подходах

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

Спринты

Один из наиболее распространенных фреймворков agile–подхода — Scrum — предписывает работу спринтами — ограниченными во времени промежутками времени.

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

Распределение ролей

Распределение ролей позволяет каждому носителю определенной роли заниматься своим делом, и сфокусировать все свое внимание и силы на достижение результата именно на этой роли и её функционале.

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

Например, в Scrum: 1) Product Owner следит за тем, чтобы делать правильный продукт;
2) Scrum Master следит за тем, чтобы продукт делался правильно, 3) Разработчик делает продукт.

Фокусировка на ценности и прибыльности продукта

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

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

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

Какими инструментами достигается такая фокусировка? Например:

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

Customer Development позволяет максимально точно попасть в интересы клиентов и запросы рынка. Этот agile–инструмент позволяет бизнесу быть гибким на самом раннем этапе — в момент формулирования гипотезы о том, что именно нужно клиентам и миру. Этот инструмент позволяет бизнесу экономить время, силы и деньги при запуске нового продукта.

Scrum предписывает целый ряд мероприятий, которые позволяют систематично отслеживать достижение бизнес–целей, и верность проверяемых гипотез. В результате продукт, подобно алмазу, последовательно “шлифуется”, и становится все лучше с каждой новой версией. А новые версии продукта Scrum позволяет выпускать достаточно быстро за счёт работы спринтами.

Сокращение регламентов и правил, упрощение процессов

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

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

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

Как же тогда контролировать результативность, эффективность команды? За результат команды говорит готовый продукт.

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

Сокращение задач и фокусировка

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

Один из наиболее распространенных agile–фреймворков, в котором используется этот инструмент — Kanban.

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

Резюме

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

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

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Edison corporate blog / Habr

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Перевод сделан при поддержке компании EDISON.
В зависимости от проекта мы успешно применяем каскадный или гибкий цикл разработки.

Роли

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

Пропускная способность

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

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

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

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

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

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

Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.

Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”

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

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

Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.

Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.

Есть только один способ держать список задач под контролем — это слово “нет”

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

Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.

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

Принятие решений

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

Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.

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

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

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

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

Владелец ИТ-продукта должен постоянно со всеми общаться

Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.

Баланс между сложностью разработки и ценностью пользовательской истории

На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.

Риски

Бизнес риск: «Правильную ли вещь мы делаем?»

Социальный риск: «Сможем ли мы сделать то что нужно?»

Технический риск: «Будет ли проект работать на данной платформе?»

Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»

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

Компромисс между ценностями знания и ценностями для клиента

С точки зрения заказчика кривая выглядит вот так:

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

Компромисс между краткосрочным и долгосрочным мышлением

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

Делать правильные вещи, делать вещи правильно или делать быстро?

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

или

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

или

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

Между ролями в Scrum существует здоровое противостояние

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

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

Компромисс между разработкой нового продукта и улучшением старого

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

График уничтожения историй

Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.

Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?

Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»

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

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

Несколько команд

Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.

Большая картинка

Исходник — Agile Product Ownership in a nutshell

видео на английском

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

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

9 января 2019

9118 просмотров

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

Что такое Agile в работе?

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

Как применить Agile к жизни?

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

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

Назначение проекта. Высокоуровневые цели

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

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

Применение SMART-метода

Аббревиатура SMART расшифровывается так: конкретный, измеримый, делегирующий, реалистичный, своевременный (Specific, Measurable, Assignable, Realistic, Timely).

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

Конкретный (Specific)

Отвечает на вопрос «Что это значит?» Вы определяете суть проекта, и каких результатов вы хотите достичь. Приведу пример.

Как только я определила для себя обтекаемую цель, скажем, выучить английский, я даю определение результата: «Мне нужно знать язык на уровне профессора-лингвиста или общения стандартными фразами со словарем будет достаточно? Сколько времени у меня есть? Какой результат мне нужен за эти сроки? А действительно ли мне нужно упирать на грамматику, если английский мне нужен для того, чтобы вести праздные разговоры в отпуске на пляже? И вообще, нужен ли мне английский, если я мечтаю жить в Испании?» Цель «выучить иностранный язык» не является уникальной. Но редко кто определяет для себя конкретный результат. Поставив цель, мы стремимся тут же браться за реализацию, пока запал не иссяк, заносим в таблицу маленьких шагов пункты вроде «учить по 10 слов в день» и «пройти столько-то юнитов в учебнике», но по истечении нескольких месяцев оказываемся не удовлетворены результатами либо вообще к этому времени забросили цель. Причина — на начальном этапе не было четкого определения результата. В моем примере с английским языком таким определением может быть «читать книги и статьи в оригинале с пониманием 80-90%».

Измеримый (Measurable)

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

На этом этапе таблица маленьких шагов становится мощным союзником. Как только я определила для себя конкретную цель, что мне все-таки нужен английский, потому что я хочу читать книжки на языке оригинала, я разбиваю данную цель на понятные действия. Так как меня интересует чтение, то не стоит делать большой упор на слушание. Я начинаю Стодневку, посвященную этой цели. Имея средний уровень и уделяя занятиям час в день, через 100 дней я хочу сформировать словарный запас примерно в 5000 слов. Для этого мне нужно читать минимум одну статью в день, выписывать неизвестные слова и заучивать самые частоупотребляемые.

Читать статью Инструменты стодневки: табличка маленьких шагов

Делегирующий (Assignable)

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

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

Реалистичный (Realistic)

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

В примере с изучением языка можно поставить цель заниматься ежедневно в течение 100 дней и пополнить словарный запас на 1000 слов к сотому дню. Однако, можно заболеть и пропустить неделю, и если 1000 слов еще можно как-то нагнать, увеличив изучение количества слов в день, то цель заниматься 100 дней подряд однозначно обречена на провал. Некоторые начинают корить себя в неудаче и забрасывают изучение языка на неопределенный срок. Давление становится гораздо меньше, если в начале планирования учесть вероятность болезни, рабочих авралов и других внештатных ситуаций, и выделить на пропуск, скажем, 10 дней из 100. Армен в Стодневке советует поступать именно так.

Своевременный (Timely)

Ограничения во времени заставляют нас быть эффективными. Я придумываю разумные сроки для идеального исполнения каждой задачи, причём обязательно закладываю определённый запас времени, чтобы не стать жертвой неправильного планирования. К примеру, если у вас начальный уровень владения языком, не стоит ставить планку смотреть и понимать фильмы без титров и перевода через 100 дней. Вряд ли за 100 дней кому-либо удастся прокачать навык до такого уровня, а вот разочарования не избежать.

В целом, СМАРТ идеально подходит для проработки идеи проекта и разрешения какой-то глобальной проблемы. Однако, этот метод не всегда эффективен, если дело доходит до ежедневной работы.

План в воскресенье — пятничный обзор

Многие предпочитают планировать в понедельник утром, но я предпочитаю воскресенье вечер.

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

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

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

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

Инструменты для приоритизации

MoSCoW

«Обязательно», «Необходимо», «Желательно и «Хотелось бы» (Must, Should, Could, Want)

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

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

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

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

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

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

Матрица Эйзенхауэра

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

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

Матрицу Эйзенхауэра легче всего продемонстрировать на рисунке:

Читать статью Планирование в рамках квадрата

Принцип Парето

Съесть десерт первым, или что при наименьших усилиях дает 80% результата? После того, как я расставила приоритеты в необходимости и важности каждого дела, я начинаю оценивать дела на соотношение усилий и результата. Например, у меня уже довольно прокачанный английский, и я легко запоминаю фразы из фильмов. У меня несколько приоритетных задач на ближайшую неделю: выполнить упражнение по грамматике, прочитать статью и выучить 10 фраз. Первым делом я посмотрю фильм, получу удовольствие, и возможно запомню даже 20 фраз, почти не затратив усилий. Т.е. через 1,5 часа у меня в копилке уже минимум +10 фраз. Статью я буду читать последней, потому что на усвоение текста у меня уходит немного больше времени, и для результата нужно намного больше усилий.

Оценка времени, которое нужно затратить на каждую задачу

Я отношусь к тактильному типу, поэтому каждую задачу записываю на отдельный стикер и приклеиваю на стену перед собой. Прежде чем приклеить стикер на стену, я оцениваю примерное время, которое мне нужно затратить на поставленную задачу и записываю в правом верхнем углу. Это очень помогает, когда неожиданно появляется свободное время и сразу можно определить, какое полезное действие можно совершить в данную минуту. Например, на прочтение статьи у меня уходит 1 час, на упражнение по грамматике 10 минут, а на тест — 30 минут. Если у меня появляются свободные полчаса, рациональнее всего будет выполнить тест.

Timeboxing — меньше, значит больше

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

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

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

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

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

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

Канбан-доска для личных проектов

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

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

Я использую стену напротив своего рабочего стола. Нужно визуально разделить ее на три части: «Сделать», «В процессе», «Сделано».

Читать статью Инструменты стодневки. Поэтапное руководство для учета времени подручными средствами

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

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

Кайдзен — результаты дня

Кайдзен дословно означает «изменение и усовершенствование», — это философия, суть которой составляет постоянное улучшение существующего положения, медленное, но постоянное движение вперед.

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

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

Читать статью Как откайдзенить себя и свою жизнь

Чтобы стало понятнее, приведу пример.

Давайте отвлечемся от языка и займемся спортом. Ежедневно мы выходим на пробежку и бежим 3 км. Есть ли здесь кайдзен? Нет. Задачу нужно постоянно усложнять и совершенствовать. Если вы пробежали сегодня 3 км, то завтра нужно пробежать 3 км и 1 метр. И так каждый день: нагрузка хоть ненамного, но должна увеличиваться.

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

Спайки — эксперименты

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

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

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

Читать статью Как Agile Results помогает интересно жить

Саморазвитие #Agile Results #Инструменты #опыт_стодневщиков #Планирование

кратко о методологиях Agile / ИТ Гильдия corporate blog / Habr

Разработка программного обеспечения — это труд, который требует своевременного принятия правильных решений. 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 году.

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

Разработка через тестирование (Test-driven development)

Игра в планирование (Planning game)

Заказчик всегда рядом (Onsite customer)

Парное программирование (Pair programming)

Непрерывная интеграция (Continuous integration)

Рефакторинг (Design improvement)

Частые небольшие релизы (Small releases)

Простота проектирования (Simple design)

Метафора системы

Коллективное владение кодом (Collective code ownership)

Стандарт оформления кода (Coding standard)

40-часовая рабочая неделя (Sustainable pace)

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

Однако 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. Еще несколько статей из нашего корпоративного блога:

Agile инструменты: Топ-5 инструментов управления Agile-проектами / DataArt corporate blog / Habr – Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Топ-5 инструментов управления Agile-проектами / DataArt corporate blog / Habr

Обзор

VersionOne

JIRA

Rally Software

TFS

Google Docs

Заключение

Что такое Agile-подход и зачем он нужен бизнесу? — статья в блоге ScrumTrek

Фокусировка на нуждах и целях клиентов

Упрощение оргструктуры и процессов

Работа короткими циклами

Активное, системное использование обратной связи

Повышение полномочий сотрудников

Гуманистический подход

Agile — это не конечное состояние, а образ мышления и жизни

AGILE – гибкая система управления проектами

Метод Agile: определение и краткая история

Манифест Agile

Ключевые моменты в применении Agile

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

Метод Scrum

Метод Kanban

Плюсы и минусы Agile

Внедрение Agile

Заключение

Agile–инструменты — инструменты в гибких подходах

Спринты

Распределение ролей

Фокусировка на ценности и прибыльности продукта

Сокращение регламентов и правил, упрощение процессов

Сокращение задач и фокусировка

Резюме

Как объяснить бабушке, что такое Agile за 15 минут с картинками / Edison corporate blog / Habr

Роли

Пропускная способность

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

Есть только один способ держать список задач под контролем — это слово “нет”

Принятие решений

Владелец ИТ-продукта должен постоянно со всеми общаться

Баланс между сложностью разработки и ценностью пользовательской истории

Риски

Компромисс между ценностями знания и ценностями для клиента

Компромисс между краткосрочным и долгосрочным мышлением

Делать правильные вещи, делать вещи правильно или делать быстро?

Между ролями в Scrum существует здоровое противостояние

Компромисс между разработкой нового продукта и улучшением старого

График уничтожения историй

Несколько команд

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

Что такое Agile в работе?

Как применить Agile к жизни?

Назначение проекта. Высокоуровневые цели

Применение SMART-метода

Читать статью Инструменты стодневки: табличка маленьких шагов

План в воскресенье — пятничный обзор

Инструменты для приоритизации

Читать статью Планирование в рамках квадрата

Читать статью Инструменты стодневки. Поэтапное руководство для учета времени подручными средствами

Читать статью Как откайдзенить себя и свою жизнь

Читать статью Как Agile Results помогает интересно жить

кратко о методологиях Agile / ИТ Гильдия corporate blog / Habr

Scrum

Extreme Programming

Канбан

Добавить комментарий Отменить ответ

Рубрики