Начало создания agile-процесса | Atlassian

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

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

Освоение рабочих процессов agile

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

Завершено

Работа, которая полностью завершена и отвечает командным критериям по части выполнения

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

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

Готово к слиянию

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

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

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

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

Оптимизация рабочего процесса

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

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

  • Какую работу команда уже завершила?
  • Увеличивается ли объем работы в бэклоге или остается на прежнем уровне при поступлении задач?
  • Сколько задач находится в каждом статусе?
  • Есть ли проблемные места, замедляющие работу команды?
  • Сколько времени в среднем уходит на выполнение задания?
  • Сколько рабочих задач не соответствовало стандартам качества при первой проверке?

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

Проблемы, возникающие при масштабировании рабочего процесса

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

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

Профессиональный совет

Jira Software, система отслеживания задач от Atlassian, позволяет командам использовать один рабочий процесс, но по-разному представлять его на свой agile-доске. Она дает широкие возможности визуализации, не мешая при этом следовать общему рабочему процессу.

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

Dan Radigan

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

Scrum — что это такое, как это работает и в чем преимущества

Платформа

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

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

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

Артефакты Scrum

Сначала определим три артефакта Scrum. Артефакт — это то, что мы создаем, например инструмент для решения проблемы. В Scrum существует три артефакта: бэклог продукта, бэклог спринта и инкремент с вашими критериями готовности. Эти три постоянные присутствуют в каждой команде Scrum, мы постоянно к ним обращаемся и уделяем им время.

  • Бэклог продукта — это главный список задач, которые необходимо выполнить. Его ведет владелец либо менеджер продукта. Это постоянно меняющийся перечень функциональных возможностей, требований, улучшений и исправлений, из которого составляются задачи для бэклога спринта. В общем и целом это список задач команды. Владелец продукта постоянно обращается к бэклогу продукта, меняет в нем приоритеты и поддерживает его актуальность, потому что может появиться новая информация или могут произойти изменения на рынке, из-за чего пропадет смысл выполнять имеющиеся задачи или появятся новые способы решения проблем.
  • Бэклог спринта — это список рабочих задач, пользовательских историй или исправлений багов, отобранных командой разработчиков для реализации в текущем цикле спринта. Перед каждым спринтом проводится собрание по планированию спринта (его мы обсудим далее в статье), на котором команда выбирает, какие задачи из бэклога продукта нужно выполнить в рамках спринта. Бэклог спринта может не быть фиксированным и может меняться по ходу спринта. Однако ничто не должно мешать достижению основной цели спринта — того, чего команда хочет добиться за текущий спринт.
  • Инкремент (или цель спринта) — это готовый к использованию конечный продукт по итогам спринта. В компании Atlassian принято представлять инкремент на демонстрации в конце спринта, на которой команда показывает, что она сделала за спринт. Слово «инкремент» не так уж широко встречается в повседневной жизни. Его часто определяют как принятые в команде критерии готовности продукта, контрольную точку, цель спринта или даже полную версию или поставленный эпик. Все зависит от того, какими критериями готовности руководствуется ваша команда и как выбираются цели спринта. Например, некоторые команды предпочитают выпускать что-нибудь для своих клиентов в конце каждого спринта. Для них слово «готово» означает «поставлено». Однако для других команд это может быть непрактично. Представьте, что вы работаете над серверным продуктом, который можно поставлять клиентам лишь раз в три месяца. Вы по-прежнему можете разбивать работу на двухнедельные спринты, но для вас продукт будет «готов», когда вы завершите работу над частью большей версии, которую планируете поставить целиком. Однако не будем забывать, что чем больше времени уходит на выпуск ПО, тем меньше шансов у этого ПО снискать успех.

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

Собрания или мероприятия Scrum

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

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

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

  2. Планирование спринта. На этом собрании команда разработчиков под руководством Scrum-мастера планирует работу (объем спринта), которую необходимо выполнить в течение текущего спринта. На нем выбирается цель спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда соотносятся с целью. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта.

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

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

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

  4. Ежедневное Scrum-совещание, или стендап. Это очень короткое ежедневное собрание, которое для удобства проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, однако это лишь рекомендация. Такое собрание также называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное Scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от цели и получал план работы на ближайшие 24 часа.

    Стендап — подходящее время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

    • «Что мне удалось сделать вчера?»
    • «Что я планирую сделать сегодня?»
    • «Может ли мне что-то помешать?»

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

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

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

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

Начните бесплатно с шаблоном Scrum для Jira

Использовать шаблон

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

Scrum-мастер

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

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

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методика, что слова Scrum и Agile многие ошибочно используют как синонимы. Но есть и другие популярные методики, например Kanban. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

За что мы любим Scrum?

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

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

И все же, чтобы освоить Scrum, может понадобиться какое-то время, особенно если команда разработчиков привыкла к стандартной каскадной модели. Новой команде предстоит выбрать scrum-мастера, освоиться в мире коротких итераций, ежедневных scrum-собраний и обзоров итогов спринта. Это может стать настоящим сотрясением основ.

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

Чтобы изучить Scrum с помощью Jira Software, прочитайте это руководство.

Claire Drumond

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

Глоссарий и терминология Agile | Agile Alliance

Все термины глоссария

A / B / C / D / E / F / G / I / K / L / M / N / O / P / Q / R / S / T / U / V

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

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

Антипаттерны — это распространенные решения общих проблем, решение которых неэффективно и может привести к нежелательным последствиям. (подробнее)

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

⇑ наверх

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

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

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

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

⇑ наверх

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

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

Непрерывная интеграция — это практика объединения изменений кода в общий репозиторий несколько раз в день с целью выпуска версии продукта в любой момент. Для этого требуется воспроизводимая и автоматизированная процедура интеграции. (узнать больше)

Карточки Class Responsibility Collaborator (CRC) — это метод объектно-ориентированного проектирования, который команды могут использовать для обсуждения того, что класс должен знать и делать, а также с какими другими классами он взаимодействует. (см. подробнее)

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

⇑ наверх

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

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

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

⇑ наверх

Эпопея — это большая пользовательская история. (подробнее)

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

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

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

⇑ наверх

Фасилитатор — это человек, который выбирает или получает явную роль ведения собрания. (подробнее)

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

⇑ наверх

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

⇑ наверх

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

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

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

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

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

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

⇑ наверх

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

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

⇑ наверх

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

⇑ наверх

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

Минимальная рыночная функция — это небольшая автономная функция, которую можно быстро разработать и которая представляет значительную ценность для пользователя. (подробнее)

Минимально жизнеспособный продукт — это, как сказал Эрик Райс, «версия нового продукта, которая позволяет команде собрать максимальное количество подтвержденных данных о клиентах с наименьшими усилиями». (узнать больше)

Мобильное программирование — это подход к разработке программного обеспечения, при котором вся команда работает над одним и тем же, в одно и то же время, в одном месте и на одном компьютере. (см. подробнее)

Мок-объекты (обычно используемые в контексте создания автоматизированных модульных тестов) состоят из создания экземпляров тестовой версии программного компонента. (подробнее)

⇑ наверх

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

⇑ наверх

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

⇑ наверх

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

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

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

Agile-команды обычно предпочитают выражать оценки в единицах, отличных от проверенных временем «человеко-часов». Возможно, самая распространенная единица — это «очки истории». (подробнее)

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

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

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

⇑ наверх

Когда выбор «простого дизайна» имеет далеко идущие последствия, два или более разработчиков встречаются для быстрого сеанса проектирования у доски. (подробнее)

⇑ наверх

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

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

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

Правила простоты — это набор критериев в порядке приоритета, предложенный Кентом Беком для оценки того, является ли исходный код «достаточно простым». (подробнее)

⇑ наверх

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

Scrumban — это смесь Scrum и Kanban.

Чтобы узнать больше о Scrumban, см. этот пост, написанный создателем метода Scrumban Кори Ладасом.

Скрам-мастер отвечает за то, чтобы команда придерживалась agile-ценностей и принципов и следовала практикам, которые команда согласилась использовать. (подробнее)

Техника масштабирования Scrum до больших групп (более десятка человек), состоящая из разделения групп на Agile-команды по 5–10 человек. (подробнее)

Члены группы Agile-разработчиков обычно сами выбирают, над какими задачами работать, а не получают задание от менеджера. (подробнее)

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

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

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

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

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

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

⇑ наверх

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

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

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

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

«Карта, Разговор, Подтверждение» — это формула, которая фиксирует компоненты пользовательской истории. (см. подробнее)

Three amigos относится к основным точкам зрения для изучения части работы до, во время и после разработки. Этими перспективами являются Бизнес, Разработка и Тестирование. (узнать больше)

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

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

⇑ наверх

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

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

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

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

Шаблон пользовательской истории является одним из наиболее часто рекомендуемых вспомогательных средств для написания пользовательских историй: Как… Я хочу… Чтобы… (см. подробнее)

⇑ наверх

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

Контроль версий не является строго Agile-практикой, поскольку в настоящее время он широко распространен в отрасли в целом. Но он упоминается здесь по нескольким причинам. (узнать больше)

⇑ наверх

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

⇑ наверх

Что такое Agile Development? | ИксДФ

Популярные похожие запросы

Фильтры

Вся литература

Заказ литературы по: Самые распространенные в этой теме Последняя литература по UX в этой теме Проверьте значение и повторите попытку.

Простое введение в Lean UX

Lean UX — невероятно полезная техника при работе над проектами, где используется метод разработки Agile. Традиция

  • 1,2 тыс. акций
  • 1 год назад

Создание самой маленькой вещицы

Мы провели исследование с сотнями людей, работающих в agile-командах, об их опыте, чтобы понять некоторые

  • 674 акции
  • 1 год назад

Гибкая разработка юзабилити

Agile Usability Engineering — это концепция, описывающая сочетание методов и практик гибкой разработки и использования Глава 9 книги0005

Инновации против постепенных улучшений

Не все команды создают продукты в крайне неопределенной среде или пытаются создавать передовые новые функции.
Автор записи

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *