Подборка манифестов из мира IT

11 сентября 2013 г.

У меня есть увлечение - я собираю разные манифесты и призывы из мира 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

Кроме ценностей, рекомендую прочитать список принцпов: 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

http://pmdoi.org

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

  • неопрделенность - принятие того, что есть неопределенность в проекте и борьба за ее уменьшение занимает много сил и средств.
  • взаимозависимость всех участников производства ПО - заказчики (на удивление они вовлечены не всегда), разработчики, 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.

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

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

Оригинал статьи на Хабре


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

Комментариев нет:

Отправить комментарий

Моя книга «Антихрупкость в IT»

Как достигать результатов в IT-проектах в условиях неопределённости. Подробнее...