Что такое манифест agile

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

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

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

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

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

дизайн сайта и оформление © 2001, Ward Cunningham
Перевод выполнили: Алексей Солцнев, Сергей Мовчан, Сергей Евтушенко,
Андрей Мудрый, Тим Евграшин, Роман Кононов, Лина Шишкина, Антон Марюхненко и Алек Козлов,
при поддерже сообщества Agile Ukraine

Источник

Что такое 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 («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.

Источник

Манифест agile все еще имеет вес?

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

История создания

В начале 2001 года на фоне гор Уосатч в городе Сноуберд, штат Юта, собрались 17 человек, чтобы обсудить будущее разработки программного обеспечения. Участников этой группы объединяло беспокойство по поводу текущего положения дел в отрасли. При этом их не пугало, что все они по-разному представляли оптимальное решение.

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

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

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

Просмотр тем

12 принципов Манифеста agile: культура, определения

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

Сам Манифест появился в то время, когда требовалось найти точки соприкосновения между Scrum, экстремальным программированием, Crystal Clear и другими методиками.

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

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

Манифест разработки программного обеспечения по методологии agile

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

Благодаря проделанной работе мы смогли осознать следующее.

Люди и взаимодействие важнее процессов и инструментов.

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

Сотрудничество с заказчиком важнее согласования условий контракта.

Готовность к изменениям важнее следования плану.

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

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

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

Длительные дебаты вокруг методологии agile

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

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

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

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

«Эти принципы можно истолковать, но для их точного перевода требуется глубокое понимание», — говорит Бьюкенен.

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

Промышленный комплекс agile

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

«Существует карго-культ Agile, когда вы делаете и говорите правильные вещи, но не понимаете основных принципов. В итоге вам не удается достичь результатов», — говорит Бьюкенен.

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

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

Рон Джеффрис, участник Snowbird 17, попытался решить эти отклонения с помощью следующего примечания.

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

Но если учесть широкое (и порой некорректное) внедрение Agile, имеет ли смысл по-прежнему ссылаться на Манифест?

Манифест по-прежнему актуален?

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

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

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

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

Дейв Уэст, генеральный директор Scrum.org, отмечает, что принципы Agile существовали и раньше. Просто они стали применяться по-другому.

«Когда я смотрю на принципы, лежащие в основе Манифеста, я вижу, что мы не изобретали их», — говорит Уэст. — «Это принципы научного метода, применявшиеся еще Галилеем и Архимедом».

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

Что все это значит?

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

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

«Манифест во многом определяет направление беседы, — говорит Уортэм. — Я понимаю его вот так. А как понимаете его вы? Хорошо, давайте выясним, как нам работать вместе».

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

«Думаю, если мы сделаем все правильно, мир сможет нас удивить. Мы сможем победить рак. Возможно, мои дети доживут до 150 или 175 лет, — говорит Уэст. — Я считаю, что нам это под силу и мы справимся».

Особая благодарность Аманде О’Каллаган, Иэну Бьюкенену, Дэну Радигану, Дэвиду Уэсту и Таннеру Уортэму за то, что поделились своими мыслями и опытом для этой статьи.

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

Источник

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

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

Введение

Далее приводим перевод оригинального манифеста дословно…

Сам Манифест

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

Благодаря проделанной работе мы смогли осознать, что:

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

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

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

Материалы по теме Agile

Нужен ли KPI и стратегия в Бизнесе? Евгений Чичваркин

Нужен или нет план в бизнесе? Интересные мысли от опытного бизнесмена про KPI и подобные методы управления. Хочешь рассмешить Бога — расскажи ему о своих планахпоговорка

Ценообразование в ИТ-разработке: Fixed Price или T&M?

Ценовые модели работы с ИТ-аутсорсерами: T&M, Fixed Price.

Мастер-класс «Управление проектами по Agile»

Как организовать проектную работу каждого отдела: маркетинга, продаж, разработки и даже бухгалтерии?

Сторипоинты и идеальные дни – в чем разница при оценке задач в разработке?

В разработке часто встречается путаница при выборе подхода оценки задач – выбирать сторипоинты или идеальные дни?

Как оценить эффективность команды? Доклад Алексея Катаева из Skyeng

Интересный доклад о том как оценивать эффективность команды? Как считать выполнение плана? Как оценивать факапы?

Разновидности Scrum: СкрамБат, СкрамБан и Срам

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

Сколько нужно энергии для работы Scrum Master, Product Owner и Agile Coach?

Чек-листы в Agile-разработке: DoD, DoR, CoS (AC) & ToDo

В руководстве про Скрам-разработку и просто в статьях о Agile практиках разработки часто встречаются методы чек листов типа DoD, DoR, CoS и ToDo. Давайте разберемся что это такое и как ими пользоваться.

Барабан-буфер-канат (ББК) – из методов ТОС

Барабан-буфер-канат (ББК) (drum-buffer-rope (DBR)) – метод TOC для планирования и управления производством при наличии внутреннего ресурса-ограничения. О применении в ИТ-разработке.

Место Agile-команд в компании

Схема scrum — ежедневная работа внутри спринта

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

Источник