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

В статье описаны:

1. Manifesto for Agile Software Development
2. Agile Manifesto — IBM version
3. MoreAgile Manifesto
4. Agile Manifesto 2.1
5. Manifesto for Half-Arsed Agile Software Development
6. Declaration of Interdependence
7. Programming, Motherfucker
8. Software Craftsmanship Мanifesto
9. DevOps Manifesto

Manifesto for Agile Software Development

http://agilemanifesto.org ^[1]

Кроме ценностей, рекомендую прочитать список принцпов: http://agilemanifesto.org/principles.html ^[2]

Протесты

Споры по поводу Agile одни из самых жарких и не утихают до сих пор. Предлагаю посмотреть на один из типовых: http://habrahabr.ru/post/142412/#comment_4768622 ^[3]. Кроме самой ветки комментариев, есть еще обсуждение этого же спора в группе AgileRussia ^[4].

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

Ограничения

Большие и маленькие компании натыкаются на ошибки при использовании приципов, которые декларирует манифест гибкой разработки. Есть непонимание ограничений, которые приводят к эпичным провалам. Один из последних примеров — разработка Британской системы социальных платежей Universal Credit ^[5].

Бывают провалы просто по непониманию. Типичные деревянные самолеты без двигателя, которые не хотят взлетать ^[6]. Например, из совсем недавнего: «Мы не пишем тесты, мы используем Agile методы, у нас и так хороший код».

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

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

Более подробно про тему ограничений я рекомендую прочитать в книге Balancing Agility and Discipline: A Guide for the Perplexed ^[7].

Agile Manifesto — IBM version

Agility@Scale: Strategies for Scaling Agile Software Development ^[8]

• Individuals and interactions over processes and tools
• Working solutions over comprehensive documentation
• Stakeholder collaboration over contract negotiation
• Responding to change over following a plan

Это несколько модифицированная версия Agile Manifesto, которая является личным мнением одного из сотрудников IBM. Они попытались переложить манифест на рельсы больших корпораций. Автор заменил «software» на «solutions» и «customer» на «stakeholder». Лично мне нравятся эти уточнения, хотя они могли казаться очевидными. Мы делаем не просто ПО, а поставляем решение для пользователей. У нас не просто заказчики, а множество заинтересованных сторон, которые хотят получить работающее решение.

Кроме того, по ссылке на статью есть еще модифицированный список принципов. В него добавлено несколько пунктов про Lean.

MoreAgile Manifesto

http://blog.xebia.com/2010/12/23/moreagile-manifesto ^[9]

Этот манифест берет левую часть оригинального AgileManifesto и ставит в противовес каждому утверждению новое. История преобразований получается такая:

• Процессы и инстументы -> Индивидуальности и их взаимодействие -> Команды и ответственность
• Исчерпывающая документация -> Работающий продукт -> Поставка ценности
• Согласования условий контракта -> Сотрудничество с заказчиком -> Партнерство
• Следования первоначальному плану -> Готовность к изменениям -> Принятие изменений

Лично для меня этот манифест не сделал переворот в сознании, а только внес несколько дополнений.

Agile Manifesto 2.1

http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto ^[10]

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

Manifesto for Half-Arsed Agile Software Development

http://www.halfarsedagilemanifesto.org ^[11]

Начался этот манифест со статьи Ron Jeffries "Beyond Agile: New Principles? ^[12]". Этот манифест является копией оригинального с дополнениями, которые поясняют, что в реальности нет 100% следования ценностям. Взять к примеру тот факт, что мы готовы к изменениям в планах, но для начала надо сделать сам план, который в будущем будем менять.

Мне нравится этот вариант, т.к. он несет отрезвляющий эффект на фанатиков гибких методологий.

Declaration of Interdependence

http://pmdoi.org ^[13]

^[14]

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

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

Более подробно идеи DOI рассмотрены в статье The declaration of interdependence for modern management or DOI ^[15].

Programming, Motherfucker

http://programming-motherfucker.com ^[16]

^[17]

PM, PO, ScrumMaster и т.п. роли в проектах частенько с фанатизмом навязывают различные методологии, управленческие фреймворки и практики программистам. Самое главное они теряют уважение к разработчикам. Долго это не могло продолжаться, потому что очевидно, что в итоге ценность ПО в том, как оно решит проблемы пользователей. Если вы используете самый совершенный процесс, но ваше ПО не работает, то это приведет к провалу.

Я думаю, чем больше менеджеров на проекте, тем больше программисты будут поддерживать этот манифест. Не так давно я участвовал в проекте, где из 15 человек команды только 4 программировали, это был еще тот зоопарк.

Колонка «They Really Value» является вскрытием мотивов. Частично можно с ними согласится, но я думаю, что они показывают другую слишком радикальную крайность, полную противоположность миру Эффективных Менеджеров.

Манифест, бл@ть!

пиши-код-блять.рф ^[18]

Локализованная версия предыдущего манифеста. Причем локализована и картинка. В англоязычной версии использовался персонаж из фильма Криминальное чтиво, у нас машет кулаком популярный мем Будь мужиком ^[19].

Software Craftsmanship Мanifesto

http://manifesto.softwarecraftsmanship.org ^[20]

Software Craftsmanship — это ответ разработчиков появлению Agile методологии для ее поддержки со стороны инженеров. Можно считать это адекватной версией манифеста «Programming, Motherfucker».

Я всегда говорил, что без хороших разработчиков невозможен никакой процесс. Предположим, что у вас есть Scrum. Вы планируете итерации, вы пишите код и делаете релизы. Если код плохой, то сколько итераций вы выдержите в хорошем темпе? Не думаю, что очень много. Основой IT-индустрии являются разработчики и этот манифест напоминает нам о том, что нужно постоянно развиваться.

DevOps Manifesto

https://sites.google.com/a/jezhumble.net/devops-manifesto ^[21]

Все взаимодействие между разработчиками и службой оперативной поддержки ИТ-инфраструктуры обычно сводится к тому, что первые перекидывают первым через «стену» готовые релизы. Разработчики создают что-то новое и вносят изменения, в то время как специалисты по операционным задачам должны обеспечивать стабильность всей инфраструктуры. Это вызывает проблемы и цель движения DevOps — разрушить стену, поместить всех в одну команду.

По этой теме рекомендую посмотреть видео People, Process, Tools – The Essence of DevOps ^[22].

Нужно больше манифестов

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

---

Еще несколько манифестов для размышления:

• The Software Team Leader Manifesto ^[23], Roy Osherove
• My Programming Manifesto ^[24], Jeremy Miller
• Кодекс Чести ^[25]
• Убей в себе программиста ^[26]

Автор: AlexanderByndyu

Источник ^[27]