22 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Автоматизация agile-процессов: управление командой

Содержание

Что такое Agile?

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

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

История Agile

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

В 1990-х годах был разработан ряд гибких методов разработки программного обеспечения в ответ на преобладающие тяжеловесные методы. К ним относятся: с 1991 года — RAD (быстрая разработка приложений); с 1994 года — метод разработки динамических систем (DSDM); с 1995 года — Scrum; С 1996 года, Crystal Clear и экстремальное программирование (XP); А с 1997 года — Feature driven development (FDD). Хотя они возникли до публикации Манифеста Agile Software Development, они все вместе называются гибкими методами разработки программного обеспечения.

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

Манифест Agile

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

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

Основа метода Agile

Основой метода гибкого управления проектами является ряд ключевых элементов:

  1. Визуальный контроль. Участники проекта в ходе работы над проектом используют карточки различных цветов и видов, которые сигнализируют, какой элемент конечного продукта уже разработан, спланирован, завершен и т.д. Таким образом, команда имеет наглядное представление о существующем положении дел. Визуальный контроль обеспечивает одинаковое видение проекта каждым из участников.
  2. Все участники проекта работаю рядом, включая клиента. Такой подход не только ускоряет многие процессы, связанные с информированием участников рабочей группы, но и создает благоприятную атмосферу для сотрудничества и эффективной работы.
  3. Адаптируемое управление. Руководитель проекта – не человек, который раздает указания, а лидер, определяющий основные правила работы и сотрудничества.
  4. Совместная работа. Команда, руководитель проекта и клиент работают сообща, что исключает возможность потери информации и непонимания целей. Также прозрачность всех процессов позволяет моментально исключать появившиеся проблемы и находить удачные решения и улучшения.
  5. Работа, основанная на разделении общего объема проекта на составные части. Такая система работы значительно снижает сложность проекта и позволяет командам сфокусироваться на каждой части в отдельности.
  6. Работа над ошибками. В ходе работы одного цикла команда осваивает новые навыки и анализирует произошедшие ошибки, что исключает их появление в следующем цикле.
  7. Спринты и ежедневные встречи. Спринты – отрезки времени, за которые команды выполняет ряд задач, — позволяют четко видеть результаты работы. Разделив время работы над проектом на спринты, получаем, например, 10 спринтов, каждый по две недели. А ежедневные встречи не более чем на 15 минут помогут каждому члену команды ответить для себя на три вопроса: что я делал вчера, что я буду делать сегодня, что мне мешает выполнять работу?

Таким образом, внедрение гибкого метода Agile возможно при следующих условиях:

  • значение проекта четко обозначено,
  • клиент активно участвует на протяжении всего проекта,
  • возможно пошаговое выполнение общего объема проекта,
  • результат работы важнее, чем документация,
  • рабочая группа составляет не более 7-9 человек.

На данный момент методология Agile широко распространена в IT-сфере и начинает осваивать деловую сферу, в частности маркетинг, менеджмент, обучение и т.д.. Метод гибкого управления проектами используется многими компаниями и госструктурами, например, правительства Норвегии и Новой Зеландии применяют Agile. В России «Сбербанк» осваивает Agile для коммерческой сферы.

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

Существует множество методов, основанных на идеи Agile, самые популярные из них — Scrum и Kanban.

SCRUM

Scrum — это методология управления проектами, в основе которой делается акцент на качественном контроле процесса работы. Хиротака Такэути и Икудзиро Нонака — первые, кто описал подход Scrum, объяснили его как “подход регби”, в котором scrum — это борьба за мяч. Сам метод представляет собой процесс разработки, разделенный на небольшие итерации — спринты, по завершении которых пользователи получают улучшенный вариант ПО. Спринт жестко фиксирован по времени, а его длительность составляет от 2 до 4 недель. Работа в рамках одного спринта состоит из нескольких этапов:

  1. Планирование объемов работы для одного спринта.
  2. Ежедневные совещания на 15 минут для коррекции работы команды и подведения промежуточных итогов.
  3. Демонстрация результатов работы.
  4. Ретроспектива спринта, в которой рассмотрены удачные и неудачные события в рамках прошедшего спринта.

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

Scrum значительно увеличивает производительность и сокращает время до преимуществ по сравнению с классическими процессами «waterfall». Процессы Scrum позволяют организациям плавно адаптироваться к быстро меняющимся требованиям и создавать продукт, отвечающий изменяющимся бизнес-целям. Scrum позволяет:

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

Kanban

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

Kanban основан на трех принципах:

  1. Визуализация задач: видимость всей информации о проекте поможет увидеть недочеты, ошибки и накладки.
  2. Контроль и ограничение WIP (work in progress — работа, выполняемая одновременно): это помогает сбалансировать подход, основанный на потоках, чтобы команды не начинали и не совершали слишком много работы сразу.
  3. Контроль времени на выполнение задачи и оптимизация работы для экономии времени.

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

Любая методология имеет преимущества и недостатки. Рассмотрим плюсы и минусы Agile.

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

1. Больше гибкости по сравнению с методологией Waterfall.

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

2. Меньше дефектов в конечном продукте.

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

Недостатки

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

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

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

3. Частые встречи

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

Внедрение Agile

  1. Выбор методики. Существуют различные гибкие методологии, которые разработаны под определенные условия. Первым этапом работы с Agile необходимо определить цели задачи работы, сроки, количество сотрудников и многое другое и подобрать такую гибкую методику управления проектом, которая будет отвечать всем требованиям.
  2. Обучение персонала. Обучение необходимо для того, чтобы сотрудники понимали базовые принципы Agile и знали как с ними работать. Именно на этом этапе определяются подводные камни, которые могут снизить эффективность Agile. Готов ли коллектив к изменениям? Подходят ли проекты компании для гибких методик? На эти и многие другие вопросы обычно помогают ответить бизнес-тренеры, специализирующиеся на Agile. Помимо прочего будет также составлен список тренингов и план, по которому будет вестись внедрение Agile в компании.
  3. Демонстрация Agile. Своеобразный тест-драйв Agile, которые проводится под контролем специалиста и показывает все этапы работы, объясняет функции ролей, взаимодействие внутри команды и между командами и т.д.
  4. Создание команды. В создание команды помимо подбора сотрудников также входит определение обязанностей, распределение задач, создание графика встреч и т.д. Каждая из методик рассчитана на определенное количество человек в команде.
  5. Выбор инструментов, необходимых для распределения задач, ведения отчетности, аналитики и прочее.
  6. Первый проект с Agile. В первом проекте будут ошибки, несостыковки, отказ от одних инструментов и выбор других. Любая методика требует своеобразной адаптации под особенности компании, в которую она внедряется.
Читать еще:  Взлом WiFi брутфор Используем Crunch

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Автоматизация agile-процессов: управление командой

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

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

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

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

Обычно команде не делегируются (остаются на уровне руководства и заказчиков):

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

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

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

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

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

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

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

При организации обучения обратите внимание на следующие рекомендации:

  • Для людей, не участвовавших ранее в Agile-проектах, необходим «курс молодого бойца» с объяснениями как теории и логики (Agile-manifesto, области применения), так и практики Agile (роли, регулярные встречи, инструменты).
  • Для кандидатов на роли владельца продукта и особенно Scrum-мастера следует подготовить более глубокую и системную программу обучения. Крайне желательно отправить их на стажировку в уже работающую зрелую Agile-команду на 1−2 дня.
  • Хорошей практикой является наличие в организации роли Agile-коуча (это может быть и специалист, привлеченный из другой организации), который в долгосрочной перспективе помогает командам развиваться и двигаться по пути повышения зрелости и осознанности.

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

  • Гарантированно достигается единство целей команды.
  • Команда становится еще более сплоченной и самоорганизованной (участники ощущают, что «они все в одной лодке»).
  • Если кто-то из членов команды «не тянет», это выявляется на уровне команды, не нужно задействовать дорогостоящие сложные инструменты HR-диагностики и т. д.

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

Какие именно командные КПЭ стоит установить в данном конкретном случае, зависит от специфики проекта/задачи, предметной области, корпоративной культуры. Тем не менее можно сформулировать базовые КПЭ, которые применимы всегда или почти всегда (возможно, с определенной модификацией и доработкой). Рекомендуется рассмотреть следующие глобальные (продуктовые) КПЭ:

  • Удовлетворенность потребителей (тех, кто использует продукт) разрабатываемым продуктом — фактически главный КПЭ. Конкретные показатели такой удовлетворенности могут варьировать: например, широко используемые показатели NPS, CSI 61, рейтинги («звезды») в тех или иных независимых реферальных системах или маркет-плейсах (например, AppStore). Считается, что чем больше конечных пользователей имеют возможность объективно оценить продукт, тем надежнее показатель. Заметим, что если продукт недоступен конечным пользователям, то этот КПЭ — ноль. Отлично сделанный продукт, которым никто не пользуется, — это всегда провал.
  • Удовлетворенность заказчика (того, кто финансирует или организует создание продукта) — тоже весомый КПЭ. К сожалению, показатель почти всегда носит субъективный характер, для минимизации субъективности можно привлечь оценки со стороны не индивидуального, а коллективного заказчика (комитета, комиссии и т. д.).
  • Удовлетворенность самой команды также считается важным и вполне весомым КПЭ. Нельзя признать успехом ситуацию, когда продукт сделан, пользователи и заказчики довольны, но часть команды уволилась, часть испытывает депрессию и упадок сил, а остальные перессорились и переругались.
  • Финансовые КПЭ — это, например, объем продаж продукта, прибыль от продукта, стоимость создания новой версии продукта. Существуют разные походы, мнения, методики относительно подобных КПЭ, и окончательное решение должно принимать руководство организации. Однако можно отметить следующие закономерности: хорошие показатели удовлетворенности потребителей всегда положительно коррелируют с готовностью платить за продукт, а значит, положительно влияют на оборот/прибыль.

Рекомендуется использовать также следующие локальные (операционные) КПЭ:

  • Скорость вывода продукта на рынок (time-to-market, T2M) — главный операционный КПЭ. Обычно этот показатель определяется как календарный срок, который нужен, чтобы вывести новый продукт (или версию продукта) на рынок (сделать доступным для использования потребителями). По сути, все нижеперечисленные операционные КПЭ «работают» на T2M, их соблюдение помогает получать хорошую T2M.
  • Регулярное выполнение плана спринта (все элементы бэклога спринта выполнены). С этой точки зрения спринт не сильно отличается от короткого классического проекта, в котором нужно соблюсти ограничения проектного треугольника.
  • Перепланирование (перенос из спринта в спринт) в пределах установленного норматива. Этот норматив вряд ли будет равен нулю (полному отсутствию переноса между спринтами). Перепланирование должно иметь объективный характер (не просто «не успели», «не смогли», а с четкой формулировкой реальной объективной причины).
  • Регулярная демонстрация инкрементов. Команда регулярно демонстрирует инкременты пользователям (раз в спринт или не реже, чем раз в два спринта).
  • Производительность команды. Важно представлять, как много полезной работы команда может сделать за спринт. Предполагается, что производительность хорошей команды должна постоянно повышаться (исключения — моменты перехода на новые технологические стандарты, выполнение ранее не встречавшихся задач и т. д.).
  • «Гигиена» работы с бэклогом. Команда соблюдает «гигиену» работы с бэклогом: бэклог размещен в согласованном месте, всегда актуализирован (команда работает только над теми задачами, которые есть в бэклоге), отдельные элементы бэклога описаны понятно и полно и т. д.
  • Соблюдение процедур. Команда соблюдает существующие процедуры взаимодействия/синхронизации с другими командами/проектами (смежниками) на своем уровне или с командами, направлениями работ, программами на более высоком уровне.
  • Регулярная работа над ошибками и с техническим долгом. Команда регулярно работает над ошибками (то есть включает исправление ошибок в бэклог, не избегает их) и с техническим долгом.
  • Соблюдение всех «правил игры». Проводятся регламентированные совещания, применяются инструменты, об использовании которых договорилась команда или которые определила организация в целом (например, в рамках фреймворка Scrum в команде есть владелец продукта и Scrum-мастер, проводятся ежедневные встречи команды, регулярные ретроспективы и т. д.).

Что такое Agile: методология, команда, оценка эффективности

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

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

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

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

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

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

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

Делай сразу!

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

Читать еще:  Как сделать скриншот на андроиде 7.0 samsung. Как сделать скриншот на андроиде. Приложения из Play Маркет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agile команда 🦸‍♂️ — роли, структура и как организовать работу в команде

Agile-команда — это кроссфункциональная команда, работа которой ведется по принципам agile, с реализацией гибкого фреймворка (например, Scrum или Kanban).

Когда нужна Agile–команда?

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

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

  • Повысим вашу стоимость на рынке труда — вы впишите в резюме 14 новых управленческих навыка.
  • Вы будете решать реальные кейсы из Google, Facebook, Tesla и Amazon в симуляторе на вашем Android и IOS.

Работа в Agile–команде

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

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

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

Конечно, команды стремятся такого избегать.

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

Роли в Agile–команде

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

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

Тем не менее, как правило, роли все–таки выделяются.

В самом распространенном фреймворке — Scrum — таких роли три: 1) Владелец Продукта, 2) Скрам–мастер, 3) Разработчик. Это классические роли Agile–команды.

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

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

Нужен ли коучинг Agile–команд?

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

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

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

Как Agile помогает в проектах автоматизации бизнеса

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

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

Наша компания занимаемся проектами автоматизации бизнес-процессов наших клиентов и со дня создания компании мы используем философию Agile на большинстве наших проектов.

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

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

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

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

  1. Аренда SaaS продукта для управления проектами.
  2. Покупка коробочного продукта и его внедрение.
  3. Разработка продукта под заказ и его внедрение.

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

После обсуждения требований клиент уточнил, а есть ли готовые продукты на платформе 1С для управления проектами, которые удовлетворяют его требованиям? Дело в том, что у клиента уже используется продукт 1С для ведения бухгалтерского учета и логично было обсудить вариант автоматизации оперативного учета на базе продукта от 1С. Такие продукты конечно есть, но функциональность этих продуктов будет использоваться клиентом на 10-20%, при этом часть требований в них не была реализована. Не очень хороший вариант с учетом того, что платить придется за весь функционал, да и стоимость коробочных продуктов с учетом их доработки под требования клиента оказалась выше, чем 2-годичная аренда Easy Projects.

Перешли к обсуждению третьего варианта: разработка продукта на платформе 1С под заказ. В течение одного часа мы с коллегами по компании оценили объем работ и бюджет на разработку решения, полностью удовлетворяющего всем требованиям клиента. После этого, обсудили бюджет проекта с клиентом и разделили требования на 2 части: требования, которые должны войти в первый релиз продукта, и требования, которые, возможно, войдут во второй релиз (если он будет). Стоимость первого релиза оказалась меньше, чем стоимость аренды Easy Projects на На все обсуждения ушло около 10 часов работы нашей команды. После этого мы подписали договор на первый релиз, разработали Устав проекта и стартовали проект, по условиям которого релиз должен был быть сделан за один месяц. В течение этого месяца было три демонстрации прототипа продукта клиенту, по итогу которых мы взяли в работу пару дополнительных требований.

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

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

Читать еще:  Потерялся приемник от беспроводной мыши jet. Что делать если потерял USB-приёмник от беспроводной мышки? Какие устройства совместимы с приемниками Logitech Unifying

Почему использование фреймворка Scrum в этом проекте дало выигрыш по срокам минимум в три месяца:

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

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

Что было на старте проекта: процессы работы железнодорожного узла у клиента не описаны и было понятно, что они будут изменяться по ходу проекта, большинство сотрудников компании не работали ранее в программных продуктах на платформе 1С. Это был наш четвертый проект с данной группой компаний и к нам у руководства группы компаний клиента сформировался высокий уровень доверия. Наша команда решила реализовывать проект без технического задания, используя тот же Scrum. Для договора мы зафиксировали перечень из функциональных блоков, которые должны быть реализованы. А для оценки объемов работ провели предварительный сбор требований за один месяц, при чем техническое задание не оформляли как документ. Мы реализовали этот проект за пять месяцев, уточняя требования перед каждым спринтом. В результате проекта мы разработали коробочный продукт для управления работой железнодорожного узла на базе 1С. На текущий момент программный продукт готов и мы начали работы по его внедрению у клиента.

Какие бонусы дало использование философии Agile и подхода Scrum в этом проекте:

  1. Сэкономили больше месяца на описании бизнес-процессов «как есть» и согласовании модели процессов «как будет» с клиентом (и приличную сумму денег).
  2. Сэкономили около 2-3 месяцев на сборе и анализе требований и разработке технического задания и около 2-3х месяцев на разработку документа по описанию технической реализации требований.

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

Какие факторы позволили нам сделать этот проект успешно:

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

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

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

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

А 24 сентября приглашаю вас на бизнес-курс «Школа руководителей проектов», где я буду рассказывать, какие есть еще инструменты project management, которые помогают организовать не только бизнес, но и собственную жизнь.

Как создать Agile команду в компании

поделитесь заметкой с друзьями и знакомыми ⤵️

Как создать Agile команду в компании

Agile команда это действительно круто и эффективно, но в 90% случаев Agile команды работают не правильно, а оставшиеся 10% приходятся на ИТ кампании, что обычному бизнесу не интересно. С точки зрения многих моментов Agile и Scrum команды ничем не отличаются, поэтому не будем путаться в терминах, а разберемся с командообразованием в Agile проектах.

Содержание статьи [бизнес блог]

Agile команда

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

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

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

Командообразование по Agile

Давайте рассмотрим некоторые характеристики работы участника Agile команды, помните такое понятие как Sprint, т.е. возможность …….

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

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

Там есть время для работы и для обратной связи.

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

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

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

Существует инструменты в виде Scrum и Kanban доски, которые требуют постоянного обновления и дают возможность быстро скорректировать работу Agile команды под горязую проблематику.

Agile процесс

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

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

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

Работа с «бункером навыков» дает вам не только доступ к ресурсам, но и возможность создавать новые комбинации и сценарии.

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

Agile методы управления характеризуются:

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

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

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

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

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

А наша поговорка: одна голова хороша, а две лучше, отлично характеризует работу Agile команды.

Мотивация сотрудников в Agile команде

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

Следующие правила построения командной работы в Agile проекте позволяют увидеть секрет мотивации команды:

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

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

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

Ссылка на основную публикацию
Статьи c упоминанием слов:

Adblock
detector