У меня есть увлечение — я собираю разные манифесты и призывы из мира IT. На данный момент собрал уже достаточно много, поэтому решил опубликовать их с моими комментариями.
В статье описаны:
- Manifesto for Agile Software Development
- Agile Manifesto — IBM version
- MoreAgile Manifesto
- Agile Manifesto 2.1
- Manifesto for Half-Arsed Agile Software Development
- Declaration of Interdependence
- Programming, Motherfucker
- Software Craftsmanship Мanifesto
- DevOps Manifesto
Manifesto for Agile Software Development
Кроме ценностей, рекомендую прочитать список принцпов: http://agilemanifesto.org/principles.html
Протесты
Споры по поводу Agile одни из самых жарких и не утихают до сих пор. Предлагаю посмотреть на один из типовых: http://habrahabr.ru/post/142412/#comment_4768622. Кроме самой ветки комментариев, есть еще обсуждение этого же спора в группе AgileRussia.
Прочитайте этот типовой спор для Agile-фанатов и тех, кто хочет открыть им глаза. Из него очевидно, что люди спорят про разные типы проектов и контрактов, про разные отношения между заказчиком и клиентом. В таких спорах нужно обязательно упоминуть про ограничения, которые неминуемо идут с каждой методологией и практикой.
Ограничения
Большие и маленькие компании натыкаются на ошибки при использовании приципов, которые декларирует манифест гибкой разработки. Есть непонимание ограничений, которые приводят к эпичным провалам. Один из последних примеров — разработка Британской системы социальных платежей Universal Credit.
Бывают провалы просто по непониманию. Типичные деревянные самолеты без двигателя, которые не хотят взлетать. Например, из совсем недавнего: «Мы не пишем тесты, мы используем Agile методы, у нас и так хороший код».
Я предлагаю вам посмотреть на ограничения, по которым вы можете оценить, подходит вам Agile или не подходит:
Про критичность, размер команды и кол-во изменений все понятно. Самыми проигнорированными оказываются шкала Квалификация и шкала Культура. Agile подводит к тому, что не стоит уделять слишком много времени жесткому процессу. Может показаться, что это несет некоторые послабления. В какой-то мере так и есть, но это послабление требует гораздо большей ответственности и квалификации от каждого участника процесса разработки ПО. Эта часть ключевая и не надо про нее забывать.
Более подробно про тему ограничений я рекомендую прочитать в книге Balancing Agility and Discipline: A Guide for the Perplexed.
Agile Manifesto — IBM version
Agility@Scale: Strategies for Scaling Agile Software Development
- 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
Этот манифест берет левую часть оригинального AgileManifesto и ставит в противовес каждому утверждению новое. История преобразований получается такая:
- Процессы и инстументы -> Индивидуальности и их взаимодействие -> Команды и ответственность
- Исчерпывающая документация -> Работающий продукт -> Поставка ценности
- Согласования условий контракта -> Сотрудничество с заказчиком -> Партнерство
- Следования первоначальному плану -> Готовность к изменениям -> Принятие изменений
Лично для меня этот манифест не сделал переворот в сознании, а только внес несколько дополнений.
Agile Manifesto 2.1
http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto
Этот манифест является небольшой модификацией предыдущего. Разница несущественная, суть идей взята из предыдущего.
Manifesto for Half-Arsed Agile Software Development
http://www.halfarsedagilemanifesto.org
Начался этот манифест со статьи Ron Jeffries "Beyond Agile: New Principles?". Этот манифест является копией оригинального с дополнениями, которые поясняют, что в реальности нет 100% следования ценностям. Взять к примеру тот факт, что мы готовы к изменениям в планах, но для начала надо сделать сам план, который в будущем будем менять.
Мне нравится этот вариант, т.к. он несет отрезвляющий эффект на фанатиков гибких методологий.
Declaration of Interdependence
Для меня это один из фаворитов по глубине идей. В этой декларации затрагиваются проблемы, которые я считаю ключевыми при разработке ПО:
- неопрделенность — принятие того, что есть неопределенность в проекте и борьба за ее уменьшение занимает много сил и средств.
- взаимозависимость всех участников производства ПО — заказчики (на удивление они вовлечены не всегда), разработчики, QA и т.д. должны быть вовлечены в процесс
- адаптации практик к конкретной ситуации на проекте — речь не идет о конкретной методологии или практике, предполагается, что вы опробовали их все и можете адекватно подбирать нужные под текущие задачи
Более подробно идеи DOI рассмотрены в статье The declaration of interdependence for modern management or DOI.
Programming, Motherfucker
http://programming-motherfucker.com
PM, PO, ScrumMaster и т.п. роли в проектах частенько с фанатизмом навязывают различные методологии, управленческие фреймворки и практики программистам. Самое главное они теряют уважение к разработчикам. Долго это не могло продолжаться, потому что очевидно, что в итоге ценность ПО в том, как оно решит проблемы пользователей. Если вы используете самый совершенный процесс, но ваше ПО не работает, то это приведет к провалу.
Я думаю, чем больше менеджеров на проекте, тем больше программисты будут поддерживать этот манифест. Не так давно я участвовал в проекте, где из 15 человек команды только 4 программировали, это был еще тот зоопарк.
Колонка «They Really Value» является вскрытием мотивов. Частично можно с ними согласится, но я думаю, что они показывают другую слишком радикальную крайность, полную противоположность миру Эффективных Менеджеров.
Манифест, бл@ть!
Локализованная версия предыдущего манифеста. Причем локализована и картинка. В англоязычной версии использовался персонаж из фильма Криминальное чтиво, у нас машет кулаком популярный мем Будь мужиком.
Software Craftsmanship Мanifesto
http://manifesto.softwarecraftsmanship.org
Software Craftsmanship — это ответ разработчиков появлению Agile методологии для ее поддержки со стороны инженеров. Можно считать это адекватной версией манифеста «Programming, Motherfucker».
Я всегда говорил, что без хороших разработчиков невозможен никакой процесс. Предположим, что у вас есть Scrum. Вы планируете итерации, вы пишите код и делаете релизы. Если код плохой, то сколько итераций вы выдержите в хорошем темпе? Не думаю, что очень много. Основой IT-индустрии являются разработчики и этот манифест напоминает нам о том, что нужно постоянно развиваться.
DevOps Manifesto
https://sites.google.com/a/jezhumble.net/devops-manifesto
Все взаимодействие между разработчиками и службой оперативной поддержки ИТ-инфраструктуры обычно сводится к тому, что первые перекидывают первым через «стену» готовые релизы. Разработчики создают что-то новое и вносят изменения, в то время как специалисты по операционным задачам должны обеспечивать стабильность всей инфраструктуры. Это вызывает проблемы и цель движения DevOps — разрушить стену, поместить всех в одну команду.
По этой теме рекомендую посмотреть видео People, Process, Tools – The Essence of DevOps.
Нужно больше манифестов
Наверняка у вас есть парочка любимых манифестов, возможно вы написали свой. Буду рад увидеть эти манифесты в комментариях.
Еще несколько манифестов для размышления:
- The Software Team Leader Manifesto, Roy Osherove
- My Programming Manifesto, Jeremy Miller
- Кодекс Чести
- Убей в себе программиста
Автор: AlexanderByndyu
