что важнее в принципах agile подхода
Что такое Agile и подойдет ли он вашей компании
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
Четыре ценности и 12 принципов Agile-управления проектами
Приступая к реализации нового проекта, важно использовать рабочую структуру, которая обеспечит вам успех. План тоже важен, но не всегда понятно, с чего начать. К счастью, существует множество проверенных и испытанных подходов к управлению проектами, из которых вы можете выбрать подходящий — они называются методологиями, и многие из них сгруппированы в различные семейства, чтобы организациям было удобнее их использовать
Очень популярны Agile-методологии управления проектами. Если вам интересно, почему, то разгадка кроется в названии — Agile-методологии позволяют руководителям проектов быть проворными и гибкими («agile»), приспосабливаться к возникающим проблемам и быстро находить самый успешный способ выполнения работы
Чтобы эффективно использовать Agile в своей организации, нужно многое знать об управлении проектами. В этом материале мы расскажем о том, что такое Agile, об основных ценностях и принципах Agile, а также о том, как использовать принципы Agile в ваших проектах.
Что представляет собой Agile-методология управления проектами?
Прежде всего, что такое Agile-управление проектами? Проще говоря, это способ управления проектами, при котором успех проекта достигается благодаря использованию ценностей и принципов Agile. Менеджеры проектов руководствуются в своей работе четырьмя ценностями и 12 принципами Agile
Эти ценности и принципы Agile были впервые сформулированы и изложены в т. н. как манифесте Agile, который был написан в 2001 г. на собрании разработчиков и профессионалов в области программирования. Цель манифеста Agile — найти замену старым методологиям и процессам управления проектами, которые показали свою неработоспособность в современных проектах.
Манифест Agile подписали 17 человек — будущий Agile Alliance. После публикации манифеста альянс разросся, сегодня он насчитывает по всему миру более 72 тыс. участников, которые в своей повседневной работе придерживаются ценностей и принципов управления проектами Agile.
Какими же проектами можно управлять с помощью Agile? Хотя изначально методология Agile была разработана специально для проектов в области программирования, она оправдала свое название как проектная методология для самых различных применений в любых отраслях. Методология Agile достаточно гибка и позволяет изменять цели проекта без ущерба для проекта в целом. Такая гибкость означает, что Agile подходит для команд, которые предпочитают работать быстро и не любят большого количества ограничений и сроков. Если ваша команда последовательна в своем общении и предпочитает структурированность адаптивности, возможно, Agile для вас.
Каковы основные ценности и принципы, составляющие методологию Agile? Давайте рассмотрим их.
Каковы четыре ценности Agile?
Сначала о ценностях Agile.
Вот какие ценности лежат в основе процессов и задач, выполняемых согласно методологии Agile. Теперь давайте выясним, что представляют собой 12 принципов, позволяющие еще глубже понять уникальность методологии Agile.
Каковы 12 принципов Agile?
Легко заметить, что многие принципы Agile непосредственно относятся к разработке ПО. Именно из этого исходили многие участники исходного Agile Alliance, именно на этом делается акцент в манифесте Agile. Однако принципы Agile применимы и к проектам в других областях и отраслях, поэтому давайте рассмотрим это подробнее.
Как внедрить цености и принципы Agile в ваше проектное управление
Возможно, вы уже готовы внедрить Agile-управление проектами, и теперь думаете, как воплотить требования манифеста Agile в жизнь.
Не существует единого способа внедрения ценностей и принципов Agile в ваши проекты. Манифест Agile — это интуитивно понятное руководство для команды, и она может использовать его самостоятельно. Если вы сторонник Agile, вы сможете адаптировать эту методологию к потребностям вашего проекта.
Один из способов сделать это — использовать ПО для управления проектами, совместимое с принципами Agile. Такой инструмент управления совместной работой, как Wrike, может помочь вашей Agile-команде успешно выполнять проекты, пользуясь такими функциями, как:
ПО Wrike поддержит вашу Agile-команду на пути к успеху. Загрузите бесплатную двухнедельную пробную версию прямо сейчас!
Да пребудет с вами Agile: гайд по основным терминам + курсы.
Понятия Agile и Scrum давно и прочно вошли в словарь ИТ-специалистов. Но не каждый, кто руководствуется в своей работе принципами манифеста Agile (или так думает), делает это правильно.
Мы составили краткий гайд по Agile в вопросах и ответах и подготовили список курсов, которые помогут разобраться в том, как организовать настоящую команду Scrum и эффективно применять Agile на практике, даже если вы далеки от ИТ.
Понятия Agile и Scrum давно и прочно вошли в словарь ИТ-специалистов. Но не каждый, кто руководствуется в своей работе принципами манифеста Agile (или так думает), делает это правильно.
Мы составили краткий гайд по Agile в вопросах и ответах и подготовили список курсов, которые помогут разобраться в том, как организовать настоящую команду Scrum и эффективно применять Agile на практике, даже если вы далеки от ИТ.
Содержание
Ищем людей, которые проходили образовательные онлайн-курсы и готовы поделиться отзывом о них. Если это вы, напишите нам в чат-бот.
Что такое Agile?
Agile часто определяют как гибкую методологию разработки, что не совсем верно, т. к. Agile — это подход к разработке ПО, совокупность принципов, которые лежат в основе целого набора конкретных фреймворков. Их объединяет сосредоточенность на клиенте и его целях, работа короткими циклами-итерациями, стремление к максимальному упрощению правил, процессов, структур и т. д., большое значение обратной связи и расширение полномочий сотрудников. Другими словами, Agile — это образ мышления, философия и культура, суть которой изложена в Манифесте Agile.
Кто придумал Agile?
Agile, а точнее Agile Манифест или Манифест гибкой разработки программного обеспечения был сформулирован в 2001 году в США группой Snowbird 17, которая состояла из ИТ-специалистов. Их виденье того, как упростить работу и повысить ее эффективность, и легло в основу Манифеста.
Какие основные идеи и принципы Agile?
Главных идей и принципов Agile, которые составляют суть этого подхода и так или иначе определяют любую гибкую методологию разработки, не так уж много.
4 идеи Agile
12 принципов Agile
Какие методологии разработки основываются на принципах Agile?
Это гибкие методологии Scrum, Kanban, экстремальное программирование (XP), DSDM, Crystal, FDD. Самой популярной из них считается Scrum. Ее используют более половины компаний, которые используют Agile-подход.
Scrum представляет собой набор правил, цель которых — создать условия для гибкой, ускоренной разработки и эффективного выстраивания рабочих процессов. В Scrum продукт создается поэтапно, а за адаптацию всех процессов отвечают одна или несколько самоорганизованных команд. У этого фреймворка есть свой набор ценностей, которые помогают создать атмосферу доверия, необходимую для эффективной работы. Это смелость, сосредоточенность, ответственность, уважение и открытость.
Scrum называют эвристической методологией, т. к. в его основе лежит идея о постоянном совершенствовании через обучение и адаптацию. Команда проекта не знает изначально, как точно он будет развиваться. В процессе работы она осваивает навыки самоорганизации, приспосабливается к меняющимся требованиям, анализирует успехи и неудачи и использует полученный опыт для того, чтобы сделать свою деятельность более эффективной.
Как проходит процесс разработки в Scrum?
Процесс создания продукта начинается не с составления или изучения технического задания, которого в принципе нет в Scrum, а с бэклога.
Бэклог — это список задач, составленный на основе желаний и требований заказчика к системе, ее функциональности. Все задачи располагаются в бэклоге в порядке их приоритетности. Это помогает команде понять, какие из них стоит выполнить в первую очередь. Бэклог не создается раз и навсегда: в него постоянно вносятся изменения, т. к. может возникнуть необходимость в добавлении новой функциональности, измениться приоритеты и т. д.
Весь процесс разработки делится на спринты — итерации фиксированной длинны, в течение которых команда выполняет определенный объем работы. Обычно они занимают от 1 до 4 недель.
Команда забирает из бэклога часть задач, которые согласованны и должны быть выполнены за итерацию, и приступает к их выполнению. Такие задачи называются бэклогом спринта. В идеале в конце каждого спринта создается инкремент продукта — готовый к использованию конечный продукт, например, работающая функция ПО, его прототип и т. п.
Бэклог продукта, бэклог спринта и инкремент объединяются термином «артефакты Scrum» — это работа, которую нужно выполнить, чтобы завершить спринт или проект.
Как организована работа команды?
В Scrum очень важно постоянное обсуждение работы, полученных результатов, проблем и вариантов их решения. Поэтому процесс создания продукта включает набор мероприятий или Scrum-событий, на которых члены команды оценивают свои достижения и возникающие сложности.
К ним относятся:
Как распределяются роли в команде Scrum?
Scrum предусматривает три основные роли, которые определяют структуру Scrum-команды. Это Product Owner (владелец продукта), Scrum Master (Scrum-мастер, Scrum-менеджер) и Scrum Development Team (команда разработки, команда разработчиков). Каждая из этих ролей имеет свой набор функций и зону ответственности.
Владельца продукта можно назвать посредником между заказчиком и разработчиками. Он собирает концепцию продукта на основе требований стейкхолдеров, доносит их до технических специалистов, формулирует задачи, определяет их приоритет, ведет бэклог продукта, управляет релизами и заинтересованными сторонами.
Scrum-мастер отвечает за эффективную реализацию методики Scrum. Он помогает наладить групповую коммуникацию, оптимизировать процесс поставки продукта и «защищает» команду от любых отвлекающих факторов. В зону ответственности Scrum-мастера также входит координирование ежедневных процессов: фиксация начала спринта, дедлайнов, добавление оценок и т. д.
Команда разработчиков — специалисты, которые выполняют все технические задачи по созданию продукта. Т. е. под этим термином понимаются не только программисты, но и дизайнеры, аналитики и другие участники команды. Команда разработчиков обычно состоит из 5–7 человек (иногда встречается формула 6 ± 3). Важно, чтобы команда была стабильной и все члены группы понимали, как работает продукт, ведь именно команда разработчиков отвечает за его поставку и качество.
Зачем применять Agile?
Гибкие методологии разработки позволяют максимально быстро реагировать на изменяющиеся требования заказчиков и ситуацию на рынке, а это дает компании конкурентное преимущество и помогает удержать клиентов. Кроме того Agile и Scrum позволяют снизить экономические издержки без ущерба для эффективности работы. Немаловажен и человеческий фактор. Все гибкие методологии подразумевают гуманистический подход: полномочия (и ответственность) сотрудников растут, стимулируя их мотивацию и давая возможности для самореализации, что положительно влияет на результаты работы.
Где и когда стоит использовать Agile-подход?
Несмотря на то, что в Agile-манифесте речь идет о разработке ПО, применять принципы Agile можно не только в ИТ-сфере. Они будут работать практически в любой области, которая связана с проектной деятельностью. Если вам важна ориентация на клиента, его потребности и командная работа, у вас нет точно сформулированных конечных задач, но есть множество факторов, способных повлиять на итоговый результат, а все члены вашей команды мотивированны и организованны, то Agile вам точно подойдет.
Курсы по Agile
spoiler#handleClick»>Примечание редакции
Стоимость указана на момент подготовки материала и носит ориентировочный характер.
Управление по Agile: Scrum, Kanban, Lean (Нетология)
Курс для проджект-менеджеров, тимлидов и владельцев бизнеса, которые хотят научиться применять Agile в своей работе.
Программа обучения включает знакомство с самыми популярными Agile-подходами и предполагает большое количество практики. Всю теорию вы будете отрабатывать во время выполнения заданий в группах или вместе с экспертами на вебинарах. Студенты научатся Agile-планированию, смогут оценивать и декомпозировать задачи, освоят такие инструменты работы над продуктом, как User Stories, Jobs-To-Be-Done, Lean Canvas.
Занятия проходят в формате предзаписанных видеолекций и онлайн-вебинаров. Преподают на курсе ведущие специалисты и практики Agile. На протяжение всего курса доступна поддержка кураторов и экспертов. Выдается удостоверение о переквалификации установленного образца.
Продолжительность: около 3 месяцев (18 марта — 28 июня).
Agile и Scrum в работе над проектами и продуктами (Coursera)
Курс рассчитан на менеджеров проектов и тимлидов, но пользу от него получат все, кто хочет применять в работе Agile и Scrum, даже далекие от ИТ-сферы люди.
Эта программа — совместный продукт Национального исследовательского Томского госуниверситета, Фонда развития онлайн-образования и ScrumTrek, а преподают на курсе аккредитованные ICAgile коучи и тренеры. За несколько недель на доступных примерах вы разберетесь с системой ценностей Agile и принципами Scrum. Изучите основные преимущества Agile-подходов, особенности процесса разработки в Scrum, познакомитесь с сервисом Trello и поймете, как грамотно организовать работу в Scrum-команде.
Продолжительность: примерно 5 недель (по 1-4 часа в неделю).
Как объяснить бабушке, что такое Agile за 15 минут с картинками
«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера
Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.
Это Пэт, владелец продукта. Она не знает технических деталей, зато обладает видением общей картинки, знает, зачем мы делаем продукт, какие проблемы он будет решать и для кого.
Это заинтересованные лица. Они будут использовать продукт, поддерживать его или будут как-то еще вовлечены в разработку.
Это пользовательские истории. В них выражены пожелания заинтересованных лиц. Например, «у системы бронирования авиабилетов у пользователя должен быть поиск по рейсам».
У заинтересованных лиц много идей, и Пэт помогает сделать из идей пользовательские истории.
Это команда разработчиков. Те, кто будет строить рабочую систему.
Пропускная способность
Так как команда использует гибкую методологию разработки, они не копят все эти истории до большого релиза, наоборот, они выпускают их сразу и как можно чаще. Обычно они выпускают 4-6 пользовательских историй в неделю. Это их пропускная способность. Ее очень просто измерить — количество пользовательских историй за 7 дней.
Некоторые истории большие, их можно считать за две, некоторые маленькие, их можно считать за половину.
Для того чтобы поддерживать этот ритм и чтобы не завязнуть в ручном регрессивном тестировании, команда усиленно работает над автоматическим тестированиеми постоянной интеграцией. Поэтому на каждую фичу приходится писать автотесты, и большая часть кода имеет встроенные автотесты.
Проблема заключается в том, что заинтересованных лиц очень много и их запросы невозможно удовлетворить 4-6 историями в неделю.
Каждый раз когда мы реализуем пользовательскую историю, у них появляется еще несколько идей, из которых вытекает еще больше запросов.
Что произойдет, если мы будем делать все, о чем они нас просят? У нас будет перегруз.
Допустим, команда возьмется сделать 10 новых историй за эту неделю.Если на входе 10 а на выходе 4-6, то команда будет перегружена. Будет спешить, переключаться между задачами, терять мотивацию, в итоге снижается производительность и качество. Это заведомо проигрышная стратегия.
Scrum и XP в этом случае используют метод “вчерашняя погода”. Команда говорит: “За последнее время мы делали 4-6 фич в неделю, какие 4-6 фич мы будем делать на следующей неделе?”
Задача владельца продукта в том, чтобы грамотно выбирать, какие именно пользовательские истории будут реализованы на этой неделе.
Kanban рекомендует ограничиться несколькими задачами — WIP limit. Допустим команда решает, что 5 — это приемлемое количество пользовательских историй, над которыми они смогут работать одновременно без перегруза, не перескакивая с одной на другую.
Оба эти подхода хорошо работают и оба они создают очередь задач, которые в Scrum называется Backlog, или приоритезированный список задач.
Этой очередью тоже необходимо управлять.Если заинтересованные лица запрашивают 10 историй в неделю, а команда реализует 4-6 историй, то эта очередь будет становиться все больше и больше. И скоро ваш Backlog будет расписан на полгода вперед. То есть одна история будет ждать выхода 6 месяцев.
Есть только один способ держать список задач под контролем — это слово “нет”
Это наиболее важное слово для владельца продуктом. Он должен тренировать его каждый день перед зеркалом.
Сказать “да” — легко. Но более важная задача — решать, что не надо делать и нести за это ответственность. Владелец продукта так же определяет последовательность, что делаем сейчас, а что позже. Это сложная работа и выполнять ее следует вместе с командой разработки и минимум одним заинтересованным лицом.
Для того, чтобы правильно расставить приоритеты, владелец продукта должен понимать ценность каждой истории и ее объем.
Принятие решений
Некоторые истории крайне необходимы, а некоторые просто бонусные фичи. На разработку одних историй уйдет пару часов, на разработку других — месяцы.
Как соотносится размер истории и ее ценность? Никак. Больше не значит лучше. Ценность и сложность задачи — вот что помогает Пэт расставлять приоритеты.
Как владелец продукта определяет ценность и объем истории? Никак. Это игра в угадайку. И лучше в ней участвовать всем. Пэт постоянно общается с заинтересованными лицами, чтобы знать ценность каждой истории, общается с командой разработчиков, чтобы знать объем работ, но все это приблизительные догадки, никаких точных цифр. Вначале всегда будут промахи и это нормально. Гораздо большую ценность представляет общение, чем сверхточные цифры.
Каждый раз когда разработчики выпускают что то новое, мы узнаем больше информации и можем лучше ориентироваться.
Одной приоритезации недостаточно. Чтобы выпускать истории быстро и часто, нужно разбивать на кусочки, которые можно сделать за пару дней. Мы хотим чтобы в начале воронки были маленькие и четкие истории а в конце — большие и неопределенные. Вовремя делать такую разбивку мы можем воспользоваться нашими последними открытиями относительно продукта и нужд пользователя. Это все называется очистка Backlogа.
Пэт проводит встречу по очистке Backlogа каждую среду с 11 до 12. Обычно на ней собирается вся команда и иногда несколько заинтересованных лиц. Содержание встреч бывает разным. Фокусировка на оценке, на разбивке историй, на критериях приемки.
Владелец ИТ-продукта должен постоянно со всеми общаться
Матерые владельцы продукта выделяют 2 компонента успеха: страсть к работе и общение. Какие задачи владелец продукта решает месте с командой.
Баланс между сложностью разработки и ценностью пользовательской истории
На ранней стадии балансу угрожает неопределенность и сразу несколько рисков.
Риски
Бизнес риск: «Правильную ли вещь мы делаем?»
Социальный риск: «Сможем ли мы сделать то что нужно?»
Технический риск: «Будет ли проект работать на данной платформе?»
Риски со стоимостью и сроками реализации: «Успеем ли и хватит ли денег?»
Знание можно рассматривать как противоположность риску. Когда неопределенность большая, мы фокусируемся на приобретении знаний — прототипах интерфейса, технических экспериментах,
Компромисс между ценностями знания и ценностями для клиента
С точки зрения заказчика кривая выглядит вот так:
С точки зрения ценности для заказчика эта кривая выглядит вот так. По мере того как неопределенности снижаются, мы можем концентрироваться на ценностях для заказчика. Мы знаем что и как делать. Остается только сделать. После того как реализовали основные истории, будем делать бонусные фичи или запускать новый проект.
Компромисс между краткосрочным и долгосрочным мышлением
Что реализовать в первую очередь? Срочно устранять ошибки или начать разрабатывать сногсшибательную фичу, которая поразит пользователей. Или делать сложный апгрейд платформы, который ускорит работу в будущем. Необходимо постоянно соблюдать баланс между реактивной и проактивной работой.
Делать правильные вещи, делать вещи правильно или делать быстро?
В идеале — все три одновременно, но в реальности приходится выбирать.
Предположим мы здесь. Пытаемся создать идеальный продукт с помощью идеальной архитектуры. Если мы потратим много времени, мы можем не попасть в «маркетинговое окно» и у нас появятся проблемы с деньгами.
Мы делаем быстро прототип продукта. Для краткосрочной перспективы это неплохо. В долгосрочной — мы получаем технический риск. И скорость разработки снизится до нуля.
Мы вот здесь, создаем прекрасный храм в рекордные сроки. Но пользователю не нужен был храм, ему нужен был жилой фургон.
Между ролями в Scrum существует здоровое противостояние
Владелец продукта фокусируется на построении правильных вещей. Команда фокусируется на том, чтобы строить вещи правильно. Scrum-мастер или agile-тренер фокусируется на сокращении цикла обратной связи.
Отдельно стоит подчеркнуть важность скорости, так ккак короткий цикл обратной связи ускоряет обучение. Это позволяет нам быстрее узнавать какие вещи правильные и как их правильно построить.
Компромисс между разработкой нового продукта и улучшением старого
Продукт никогда не может быть полностью завершен, потому что ему постоянно нужны изменения. Когда команда начинает работу над новым продуктом, что происходит со старым? Передача продукта от одной команды к другой — очень затратно и рискованно. Обычно команда поддерживает старый продукт, разрабатывая новый. Поэтому скорее понятие “Backlog” относится не к продукту а к команде. Backlog — это список вещей, которые хочет владелец продукта от команды. И набор историй для разных продуктов. Владельце продукта нужно постоянно выбирать актуальные для реализации.
График уничтожения историй
Время от времени, заинтересованные лица будут спрашивать у Пэт: “Когда выпустят мою фичу?” или “Сколько фич выпустят к рождеству?”. Владелец продукта должен уметь управлять ожиданиями пользователя. И управлять ожиданиями реалистично.
Два тренда — оптимистичный и пессимистичный (можно на глаз). Расстояние между трендами показывает насколько нестабильна скорость работы команды. Со временем эти тренды стабилизируются и конус неопределенности будет уменьшаться.
Предположим, заинтересованное лицо спрашивает, когда вот эта фича будет сделана?
Это вопрос с фиксированным содержанием и неопределенным сроком. Для ответа Пэт использует две линии тренда. Ответ — в апреле или мае.
Заинтересованное лицо спрашивает Пэт: «Сколько будет сделано к рождеству?» Это вопрос с фиксированным сроком и неопределенным содержанием. Линии тренда отсекают на вертикальной шкале вероятный отрезок того, что успеют реализовать.
Заинтересованное лицо спрашивает :«Успеем ли мы сделать вот эти фичи к рождеству?» Это вопрос с фиксированными временными рамками и фиксированным содержанием. Ориентируясь на тренды, Пэт отвечает: «Нет». Добавляя: «К рождеству мы успеем сделать столько, а вот столько времени нам понадобится чтобы завершить всю эту работу полностью.»
Обычно лучше уменьшать содержимое проекта, чем увеличивать время. Если мы уменьшаем содержание, у нас будет возможность отодвинуть сроки. Мы можем выпустить кое-что здесь, а остальное — позже.
Владелец продукта делает расчеты еженедельно и использует исключительно эмпирические данные, а не выдает желаемое за действительное. Он честно говорит о неопределенности. Команда поддерживает темп работы, а Пэт не давит на них, заставляя ускориться.
Несколько команд
Пусть у нас несколько владельцев продукта и несколько команд. Модель та же — управление пропускной способностью, коммуникация с заинтересованными лицами, принятие решений по поводу отклонения пользовательских историй. Скорость равна сумме скоростей всех команд. Прогнозирование может быть общее или по каждой команде. У владельцев продуктов появляется дополнительная задача — общение с другими владельцами продукта. Нужно организовать работу над Backlogами так, чтобы минимизировать зависимости и обеспечить синхронизацию. В больших проектах требуется Главный владелец продукта (CPO), чтобы синхронизировать всех остальных.