Что такое agile manifesto

История создания Agile-манифеста

11–13 февраля 2021 исполнилось 20 лет Манифесту Agile-разработки ПО. Давайте вспомним, какие подходы существовали до него, почему возникла потребность в таком манифесте, как он создавался, кто в этом участвовал, как появился термин «agile», и что думают авторы о полученном результате.

Уже существовали итеративные подходы.

Весной 2000 Kent Beck (один из авторов eXtreme Programming и TDD) на встречу с названием «Extreme Programming Leadership Conference» в The Rogue River Lodge недалеко от города Медфорд в штате Орегон пригласил:

На встрече в числе других вопросов обсуждали:

Идея была холодно поддержана некоторыми участниками. Поэтому (Uncle) Bob Martin и Martin Fowler в перерыве договорились организовать встречу с представителями более широкого круга методов, включая Scrum и Crystal.

Bob Martin и Martin Fowler составили предварительный список. Примерно в то же время Alistair Cockburn собирал похожую встречу. Два списка объединили, да и вообще постарались собрать всех активных, кому может быть интересно. Рабочим названием встречи стало «Lightweight Methods Summit», а в качестве цели в приглашении указали:

Создание манифеста, описывающего общие характеристики легковесных подходов.

Организацию логистики подхватил Alistair Cockburn. Он предложил встретиться недалеко от Солт-Лейк-Сити в штате Юта. Вместе с Jim Highsmith они организовали проживание, питание и активности.

20 приглашённых приехать не смог, например, Grady Booch (один из авторов языка UML) и «Big Dave» Thomas (тёзка другого Дейва — «Pragmatic Dave» Thomas, который приехать смог).

11–13 февраля 2001 года 17 «умников» экспертов-практиков разработки ПО собрались в кондоминиуме The Lodge горнолыжного курорта Snowbird в горах Уосатч в штате Юта — это в западной части континентальных США недалеко от Солт-Лейк Cити.

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

Встречу начал Боб Мартин, поделившись своим взглядом на общие моменты в существующих легковесных процессах, и предложил цель — зафиксировать эти общие характеристики во благо всей отрасли для создания полезного ПО. Далее фасилитировать встречу стали Martin Fowler & Ward Cunningham. Кстати, знаменитую фотографию, выложенную на странице Манифеста, сделал именно Уорд.

Ожидания от встречи у всех были разными, но не завышенными.

Я не ожидал, что конкретно эта группа сможет договориться о чём-то значительном.

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

«Дядя Боб» Мартин впоследствии охарактеризовал их так:

Договорились о многих аспектах разработки ПО, и поэтому решили оформить этот общий базис в виде боевого клича для всей отрасли. Хотели показать, что отстаивают и чему сопротивляются.

Вообще-то, это я и Мартин Фаулер, рисуя на доске во время обеда, сформулировали первые 3 сравнения. Группа расширила их до 5, а затем сократила до 4.

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

Группа оформила зафиксированные 4 ценности в виде «Манифеста Agile-разработки ПО».

Надеюсь, что Манифест прояснит, что является и не является agile.

Почему именно «Манифест»? Почему именно «Agile»? Читайте в статье «Почему Agile так называется?»

Черновик 12 принципов группа записала во второй части встречи.

Группа назвала себя «The Agile Alliance».

После встречи группа ещё пару месяцев дорабатывала формулировки 12 принципов. Ward Cunningham (изобретатель технологии wiki) позднее создал страницу AgileManifesto.org.

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

В конце 2001 они организовали НКО Agile Alliance для развития Agile-методов.

Я очень доволен результатом.

Думаю, я никогда не участвовал во встрече, на которой группа так сохраняла фокус и достигла целей с лёгкостью и минимумом конфликтов.

Лично я в восторге от итоговой формулировки Манифеста. Я был удивлён, что и другие так же довольны итоговыми фразами. Так что, мы всё же договорились о чём-то значительном.

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

Статистика применения Agile-подходов собирается по большей части с компаний, их использующих: «по результатам онлайн-опроса 100% россиян пользуются интернетом». Поэтому скажу из своего опыта работы с ИТ-компаниями. С каждым годом Манифест выглядит всё менее революционным:

Участники тренингов, знакомясь с Манифестом, отвечают: «Ну, так это логично. У нас почти так и есть.» И это хорошо! Значит, движемся в хорошем направлении: от формализма и бюрократии к людям и крутым продуктам!

Источник

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

Источник

Манифест 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, преодолении разрозненности и развитии эмпатии.

Источник

Что такое Аджайл Манифест

Аджайл Манифест — это документ, который определяет ценности Аджайла. Он содержит четыре фундаментальные идеи:

Аджайл не отрицает важности того, что справа, но больше ценит то, что слева.

Идеи кажутся простыми, но если пытаться сходу использовать их в работе, начинаются проблемы. Сложно понять, что именно означают «взаимодействия», «работающие продукты», «сотрудничество» и «готовность к изменениям». Разберём идеи Аджайл Манифеста на примере.

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

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

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

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

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

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

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

Представим, что компания Nintendo решила выпустить новую часть игры про водопроводчика Марио: Super Mario. У неё есть две команды: обычная и аджайловая. Какая из них быстрее приступила к разработке игры?

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

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

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

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

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

В игре Super Mario разработчики применили новую технологию для реалистичного движения персонажей. Чтобы не забыть, новую технологию нужно описать. Как её описали?

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

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

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

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

В Nintendo настали тёмные времена: доллар упал, и денег на игру почти не осталось. Руководство захотело прекратить разработку. Как повели себя команды?

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

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

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

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

Тем не менее план необходим. Он проясняет, что, как и в какой последовательности делать, и снимает ступор перед задачей. План — помощник, а не ориентир.

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

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

В дополнение к Аджайл Манифесту его создатели написали 12 принципов Аджайла. Мы объяснили каждый принцип.

Катя Кондратьева Редактор Unusual Concepts

Источник