что такое agile manifesto

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

Назовём их вечными.

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

Ты можешь обложить себя «Главредами» и «Орфограммками», использовать «Слово*б», чтобы подобрать ключевые слова для статьи. Это, в принципе, неплохо. Однако не стоит за всем этим забывать о здравом смысле и необходимости «полевых» работ. Никто лучше тебя, человек, не проведёт анализ ЦА, не выявит конкурентов и не интерпретирует полученные данные. Да, сервисы (например, PR-CY) облегчат рутинные операции, но сделать выводы и познакомить с ними клиента можешь только ты сам.

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

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

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

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

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

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

Принципы Agile

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

Наивысшим приоритетом является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения

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

Иногда нашему брату нужно работать на упреждение. Если же мы говорим про новостной контент, то этот принцип отрабатывает на все 146 %.

Изменение требований приветствуется, даже на поздних стадиях разработки

Если ты должен внести существенные правки в текст за 15 минут до публикации, сделай же это! Да, это может «поранить» структуру, отвлечь тебя от более приятных занятий. Но положительный читательский отклик все окупит сторицей. Проверено.

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

В случае с коммерческим писательством — ещё чаще — каждый день, а то и несколько раз в день. Разный по тематике и формату контент привлекает больше людей. Тут главное «не перекормить» читателей.

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе

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

С самого начала работайте с клиентом. У вас общая задача — заработать как можно больше денег

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

Большой и сложный проект предполагает работу команды из редактора (редакторов) и коллектива авторов. Например, в веб-агентстве «Текстерра» мы с друзьями-коллегами писали книгу о разработке сайтов для начинающих, в работе над которой участвовал ваш покорный слуга. Мы с самого начала разделили обязанности – кто и какую главу пишет, кто и чьи тексты редактирует. В итоге получился отличный продукт, на который до сих пор приходят благодарные отзывы.

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды

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

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

Коммерческий автор, как и программист, «измеряется» выполненными работами. Говорить, что ты что-то делал, «а эти вон всё запороли» — профессиональный моветон. Сделал — покажи, не сделал — промолчи.

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

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

В нашем деле нужно фигачить, чтобы хотя бы стоять на месте

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

У нашего брата-писателя это означает создание и развитие редакционной политики блога — добавляйте новые требования и убирайте старые, чтобы все работало на рост качества контента.

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

Если что-то можно сделать автоматизированным способом, сделайте это! Следуйте правилам редполитики, и это существенно облегчит жизнь и вам, и редакторам с клиентами.

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

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

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

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

Та же редполитика — не раз и навсегда определенный документ. Если она не работает в текущих реалиях — в пекло её! Создавайте новое, берите «свежих» авторов, не бойтесь ЦА: сегодня они гневно реагируют на ваши контент-новинки, а завтра репостят их везде, где только можно.

Послесловие

4 ценности и 12 принципов Agile, как видите, хорошо ложатся на коммерческое писательство. Подставьте сюда «медицина», «строительство», «военное дело»: стоит только чуть-чуть подумать и сформулировать свои мысли, чтобы понять, что в феврале 2001 года семнадцать программистов дали миру универсальный набор правил ведения профессиональной деятельности. Аминь.

Статью подготовил Алексей Александров, коммерческий автор, писатель и сценарист. Профили автора: «ВКонтакте», Facebook.

Источник