Эджайл менеджмент: Что такое Agile и Scrum и как с ними работать – Что такое Agile, зачем и где используется, разница Scrum и Kanban

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой.  Часть 1

Алена Лепилина

Agile — гибкий подход к разработке, включающий разные методологии (Scrum, Канбан, ХР, Lean и другие). Об этом знают многие. Но есть десятки мелочей и всяких интересных штук, которые не лежат на поверхности.

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

Большой взрыв проектов

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

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

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

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

Манифест Agile

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

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

Как устроены процессы

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

1. Выберите владельца продукта — это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой — от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

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

4. Составьте бэклог продукта — соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, — источник.

5. Запланируйте спринты — отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

6. Проводите ежедневные встречи на 15 минут (и ни минутой больше)

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

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

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

Более подробно о том, как внедрить скрам и повысить эффективность команды, читайте в этой статье.

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

Знать Agile в лицо

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

1. Минимизация рисков — это главная цель в рамках любого гибкого подхода.
2. Итеративная разработка — работа в коротких циклах.
3. Люди и коммуникация — самое важное.

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

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

• Команде на руку общение с заказчиком и коллегами (чтоб без этого: «Вы меня неправильно поняли — переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

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

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

Кому это может не понравиться?

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

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

Читайте продолжение:

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2
Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 3

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

Десяток Книг по Agile, Которые Точно Понадобятся Менеджеру Проекта в 2020 Году

Профессиональная литература с термином «Agile» в названиях стала появляться на полках IT-экспертов после 2001 года, когда термин был использован во время представления Манифеста Agile.

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

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

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

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

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

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

Лучшие книги по теме Agile Project Management

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

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

Agile Project Management for Dummies

Автор: Mark C. Layton

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

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

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

Знания, описанные в книге, подарят вам и вашей команде возможность эффективно завершить любой проект. Agile Project Management for Dummies пополнит навыки руководителей проектов, членов проектной команды и всех заинтересованных сторон.

The Lean Product Playbook: How to Innovate with Minimum Viable Products

Автор: Dan Olsen

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

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

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

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

The Lean Startup

Автор: Eric Ries

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

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

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

The Software Project Manager’s Bridge to Agility

Авторы: Michele Sliger, Stacia Broderick

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

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

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

Coaching Agile Teams: A Companion for Scrum Masters, Agile Coaches, and Project Managers in Transition

Автор: Lyssa Adkins

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

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

Project Management the Agile Way: Making it Work in the Enterprise

Автор: John Goodpasture

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

Project Management the Agile Way предлагает читателям четкое объяснение различных методов и способов применения Agile в проектах компании, а также помогает определить важнейшие критерии, необходимые в выборе инструмента для управления проектами.

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

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

Theory of Constraints

Автор: Eliyahu M. Goldratt

Автор этого произведения известен также своими другими бестселлерами, такими как «Critical Chain».

Представленная в нашем обзоре книга, «Theory of Constraints» широко известна во всем мире и активно используется в процессе обучения в колледжах, университетах и бизнес-школах. Вы можете найти издание на одном из 23 языков.

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

Founders at Work: Stories of Startups’ Early Days

Автор: Jessica Livingston

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

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

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

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

Agile Retrospectives: Making Good Teams Great

Авторы: Esther Derby, Diana Larsen

Making Good Teams Great — удивительная книга, которая предлагает читателям проверенные инструменты и методы для решения любых задач, возникающих при разработке программного обеспечения в рамках Agile проектов.

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

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

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

User Stories Applied: For Agile Software Development

Автор: Mike Cohn

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

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

Книга учит тому, как сделать отличную user story и научиться быстро понимать, что делает ее плохой.

Что такое Аджайл и Скрам — Справочная

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

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

Что такое Аджайл

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

Аджайл-коуч — специалист, который учит ценностям и помогает компаниям расти. Такого коуча можно найти в консалтинговом агентстве. Например — Unusual Concepts или Scrum Trek.

Аджайл-коуч расскажет о четырёх принципах:

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

Игорь Беляк, тимлид команды разработки интеллектуальных решений DIRECTUM:

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

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

Как применять Аджайл

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

Влада Беганова, скрам-мастер в команде разработки банка Точка:

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

Ценности и установки Аджайл выполняются, когда есть чёткие правила. Такие правила называются фреймворками. Фреймворк — каркас, на котором строится рабочий процесс. Фреймворков, позволяющих внедрить Аджайл, несколько: Скрам, Канбан, Нексус. Новичкам проще использовать Скрам: у него есть чёткий перечень правил. Рассказываем, как применять Скрам, чтобы получить результат.

Инструменты Скрама

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

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

Скрам работает, когда есть распределение ролей. Всего их три.

Команда. Это самоорганизованная группа из 3−9 человек. Вклад отдельного сотрудника не оценивается. Важно только то, какого результата добилась команда совместными усилиями.

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

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

Бэклог продукта

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

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

Бэклог спринта

В Скраме есть понятие «спринт». Это точный отрезок времени (обычно д

Опыт внедрения Agile в компании Ticketland — статьи на Skillbox

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

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

 1ч. 32 мин.

статья

 13 мин.

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

 1ч. 19 мин.

Попытки создать идеальную систему управления данными начались еще в середине девяностых годов прошлого века. Даже ФБР попыталось придумать что-то новое для замены каскадной модели управления (Waterfall), но, потратив600 млн долларов, отказалось от этой затеи. Почему же за10 лет так ничего и не удалось сделать? Проблема была в самой методике работы «по каскадам» (ступеням), когда следующий этап запускается только после того, как реализован предыдущий: если останавливался один из этапов, то замирал весь проект.

В 2001 году появился «Манифест гибкой методологии разработки программного обеспечения» (англ. Agile Manifesto), и ситуация изменилась. За счет итерационной модели удалось наладить непрерывную работу всех участников проекта, и проклятье Waterfall исчезло. А пример ФБР и выброшенных на ветер600 млн долларов научил всех.

Важно!

С помощью старых подходов нельзя решать современные задачи.

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

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

• Устаревшее программное обеспечение, заменить которое казалось практически невозможным из-за сложной работы сервиса.

• «Сакральные» знания о проекте сосредоточены в руках нескольких сотрудников. Это делало их практически незаменимыми: когда люди уходили, компания сталкивалась с трудностями.

• Низкая скорость разработки и низкое качество продуктов.

• Отставание от конкурентов в технологическом плане и потеря ключевых клиентов.

• Текучка среди разработчиков. Молодые специалисты зачастую уходили, не проработав в компании даже года. Это проблема всего рынка.

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

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

Agile — это гибкая методология в разработке ПО. В ее основе лежит4 принципа:

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

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

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

В Agile как таковых руководителей нет, но у каждой команды есть ответственное лицо — Product Owne

Они оказались не нужны в чистом виде. Им нужно было или быть разработчиками, или становиться Product Ownerʼами.

Важно!

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

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

Например, сервис отчетов, которым пользуются клиенты компании, устарел; решили создать новый и красивый. Раньше руководитель мог отдать приказ: сделайте новый сервис отчетов. Но теперь в компании стали работать иначе. Сперва Product Owner обсуждает с клиентами разные гипотезы — например, как может выглядеть новый сервис отчетов. То есть осуществляет сбор пожеланий пользователей.

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

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

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

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

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

В Agile нет места хаосу, каждое нововведение должно быть четко обосновано

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

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

Человек должен объяснить, почему хочет работать в компании. Если у него нет никакой цели в жизни, никакого плана — это плохой знак, его надо будет «качать».

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

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

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

Схематическое отображение t-shape

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

Важно!

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

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

Положение Product Owner в бизнес-процесса и в команде

Ключевые навыки Product Owner:

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

• является владельцем бэклога продукта;

• умеет расставлять приоритеты;

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

• представляет пользователя;

• взаимодействует с командой;

• принимает продукт.

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

Схематическое отображение пользовательской истории

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

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

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

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

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

Независимое обновление

Масштабирование

Возможность экспериментов

Поддержка любым разработчиком

Сложно выкатывать

Сложно тестировать

Респределительная система

Сложно эксплуатировать

Несогласованная БД 

Все поставленные задачи были решены. Сервис Ticketland вошел в двадцатку Forbes, компанию оценили в 84,2 млн долларов. Для бизнеса такого рода это отличный результат.

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

Есть кейсы других крупных компаний. Посмотрите на них и задайте себе вопрос: «Зачем ездить по асфальту на коньках, если можно ехать на BMW?» Для современных проектов лучше работают современные работающие методологии.

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

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

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

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

«Что такое описание процесса в agile?» – Яндекс.Кью

Agile — это образ мышления, основанный на ценностях и принципах Agile–манифеста.

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

Agile-манифест разработки программного обеспечения

Мы постоянно открываем для себя более совершенные методы разработки

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

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

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:

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

Ага ага, какая разница-то? / Habr

Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?

Получая много вопросов в прошлом, я решил расставить все точки над “и”.

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

Мэри и Том Поппендик адаптировали принципы “Бережливого Производства” для разработки программного обеспечения, и я верю, что эти идеи являются основами и причинами того, как agile работает:

1. Устранение потерь.

2. Повышение качества.

3. Создание знаний.

4. Отсроченные обязательства.

5. Быстрая поставка.

6. Уважение людей.

7. Полная оптимизация.

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

Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.

Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.

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

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

Ценности Agile – это:

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

Принципы Agile – это:

1. Наивысший приоритет — удовлетворение пользователей.

2. Изменение требований приветствуется.

3. Работающий продукт следует выпускать как можно чаще.

4. Представители бизнеса и разработки должны работать вместе ежедневно.

5. Над проектом должны работать мотивированные профессионалы.

6. Непосредственное общение является наиболее практичным и эффективным.

7. Работающий продукт — основной показатель прогресса.

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

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

10. Простота — искусство минимизации лишней работы — крайне необходима.

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

12. Команда должна систематически анализировать возможные способы повышение эффективности и соответственно корректировать стиль своей работы.

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

Наиболее общие это: Scrum или Kanban (или гибрид из обоих) для “Управленческих практик”. Экстремальное программирование (XP) для Технических практик (с новыми практиками становится популярным, во многом из-за Lean Statup, такие как непрерывное развертывание и тестирование на проде).

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

Благодарности: Спасибо Юрию Прокудину, Екатерине Кивелевой за помощь в подготовке текста.

крупнейшая идеологическая проблема в IT / Издательский дом «Питер» corporate blog / Habr

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.

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

Интересно, что в манифесте Agile не делается попыток артикулировать какие-либо конкретные методы работы, правила, процессы, системы или структуры, которые помогали бы разрабатывать ПО в стиле Agile. Это и неудивительно: ведь манифест Agile никогда и не претендовал на подробное описание того, как достичь целей этого манифеста. Такая явная размытость ничуть не убавила популярности Agile: фактически, стремительный рост спроса на конкретные методы и инструменты Agile привел к возникновению метаиндустрии на основе ресурсов Agile. Этот интерес стимулировал внедрение Agile, проникновение в новые отрасли самой идеологии Agile и ее производных. Наиболее отчетливо проявили себя тщательно определенные методологии Agile (например, Scrum и Kanban—т.e., детализированные описания процессов, которых нужно придерживаться для воплощения принципов манифеста Agile) и специализированные софтверные платформы, специально разработанные для поддержки Agile-разработки. Австралийская технологическая компания Atlassian продает целый ряд таких продуктов, предназначенных для поддержки процессов разработки ПО в стиле Agile; особого упоминания заслуживают Confluence и Jira, уже де-факто ставшие стандартами в индустрии. Для тех, кто не варится в технологическом сообществе, такие продукты кажутся весьма таинственными. Появился целый ряд поясняющих статей, прежде чем Atlassian попала в списки NASDAQ и непосредственно после этого. Статьи были призваны объяснить, что же именно продает Atlassian, и почему компания добилась такой высокой рыночной капитализации.

Подобно программным продуктам Atlassian, лексикон, описывающий процессы Agile и повседневные рабочие приемы, также стал все более непроницаемым для непосвященных. Практикующие Agile говорят о спринтах, досках Kanban, диаграммах сгорания задач, скоростях, пользовательских историях, эпиках и ретроспективах — значение всех этих слов зачастую меняется в зависимости от контекста, а сами эти термины могут быть аффилированы с одной или несколькими явно определенными методологиями Agile. Стоит ли удивляться, что, по мере усложнения методологии Agile, множится и когорта специалистов-консультантов, помогающих все это осмыслить. В Bain & Company к услугам клиентов – около 1000 практиков Agile. Пожалуй, это самый надежный индикатор, демонстрирующий, какой прибыльной стала индустрия Agile-консалтинга. Однако, если манифест Agile столь прост, каким кажется на первый взгляд, то зачем же столько консультантов? Насколько ощутимо услуги любого из них отражаются на качестве и эффективности работы в типичной технологической компании?

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

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

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

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