У меня есть увлечение — я собираю разные манифесты и призывы из мира IT. На данный момент собрал уже достаточно много, поэтому решил опубликовать их с моими комментариями.
В статье описаны:
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.
Agility@Scale: Strategies for Scaling Agile Software Development
Это несколько модифицированная версия Agile Manifesto, которая является личным мнением одного из сотрудников IBM. Они попытались переложить манифест на рельсы больших корпораций. Автор заменил «software» на «solutions» и «customer» на «stakeholder». Лично мне нравятся эти уточнения, хотя они могли казаться очевидными. Мы делаем не просто ПО, а поставляем решение для пользователей. У нас не просто заказчики, а множество заинтересованных сторон, которые хотят получить работающее решение.
Кроме того, по ссылке на статью есть еще модифицированный список принципов. В него добавлено несколько пунктов про Lean.
http://blog.xebia.com/2010/12/23/moreagile-manifesto
Этот манифест берет левую часть оригинального AgileManifesto и ставит в противовес каждому утверждению новое. История преобразований получается такая:
Лично для меня этот манифест не сделал переворот в сознании, а только внес несколько дополнений.
http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto
Этот манифест является небольшой модификацией предыдущего. Разница несущественная, суть идей взята из предыдущего.
http://www.halfarsedagilemanifesto.org
Начался этот манифест со статьи Ron Jeffries "Beyond Agile: New Principles?". Этот манифест является копией оригинального с дополнениями, которые поясняют, что в реальности нет 100% следования ценностям. Взять к примеру тот факт, что мы готовы к изменениям в планах, но для начала надо сделать сам план, который в будущем будем менять.
Мне нравится этот вариант, т.к. он несет отрезвляющий эффект на фанатиков гибких методологий.
http://pmdoi.org
Для меня это один из фаворитов по глубине идей. В этой декларации затрагиваются проблемы, которые я считаю ключевыми при разработке ПО:
Более подробно идеи DOI рассмотрены в статье The declaration of interdependence for modern management or DOI.
http://programming-motherfucker.com
PM, PO, ScrumMaster и т.п. роли в проектах частенько с фанатизмом навязывают различные методологии, управленческие фреймворки и практики программистам. Самое главное они теряют уважение к разработчикам. Долго это не могло продолжаться, потому что очевидно, что в итоге ценность ПО в том, как оно решит проблемы пользователей. Если вы используете самый совершенный процесс, но ваше ПО не работает, то это приведет к провалу.
Я думаю, чем больше менеджеров на проекте, тем больше программисты будут поддерживать этот манифест. Не так давно я участвовал в проекте, где из 15 человек команды только 4 программировали, это был еще тот зоопарк.
Колонка «They Really Value» является вскрытием мотивов. Частично можно с ними согласится, но я думаю, что они показывают другую слишком радикальную крайность, полную противоположность миру Эффективных Менеджеров.
пиши-код-блять.рф
Локализованная версия предыдущего манифеста. Причем локализована и картинка. В англоязычной версии использовался персонаж из фильма Криминальное чтиво, у нас машет кулаком популярный мем Будь мужиком.
http://manifesto.softwarecraftsmanship.org
Software Craftsmanship — это ответ разработчиков появлению Agile методологии для ее поддержки со стороны инженеров. Можно считать это адекватной версией манифеста «Programming, Motherfucker».
Я всегда говорил, что без хороших разработчиков невозможен никакой процесс. Предположим, что у вас есть Scrum. Вы планируете итерации, вы пишите код и делаете релизы. Если код плохой, то сколько итераций вы выдержите в хорошем темпе? Не думаю, что очень много. Основой IT-индустрии являются разработчики и этот манифест напоминает нам о том, что нужно постоянно развиваться.
https://sites.google.com/a/jezhumble.net/devops-manifesto
Все взаимодействие между разработчиками и службой оперативной поддержки ИТ-инфраструктуры обычно сводится к тому, что первые перекидывают вторым через «стену» готовые релизы. Разработчики создают что-то новое и вносят изменения, в то время как специалисты по операционным задачам должны обеспечивать стабильность всей инфраструктуры. Это вызывает проблемы и цель движения DevOps — разрушить стену, поместить всех в одну команду.
По этой теме рекомендую посмотреть видео People, Process, Tools – The Essence of DevOps.
Наверняка у вас есть парочка любимых манифестов, возможно вы написали свой. Буду рад увидеть эти манифесты в комментариях.
Еще несколько манифестов для размышления:
В статье описаны:
- 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
Кроме ценностей, рекомендую прочитать список принцпов: 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.
Нужно больше манифестов
Наверняка у вас есть парочка любимых манифестов, возможно вы написали свой. Буду рад увидеть эти манифесты в комментариях.
Еще несколько манифестов для размышления:
- The Software Team Leader Manifesto, Roy Osherove
- My Programming Manifesto, Jeremy Miller
- Кодекс Чести
- Убей в себе программиста
