Причина провала большинства проектов кроется в ошибках процесса разработки. Agile подходы были придуманы для того чтобы снижать риски проектов и улучшать результативность команд.

Agile или гибкая разработка – один из наиболее эффективных способов разработки сайтов. Ключевые отличия от старых проектных подходов заключаются в том что процесс разработки строится с прицелом на быстрые результаты и долгосрочную основу.

Манифест Agile

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

Благодаря проделанной работе мы смогли осознать, что: 

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

То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.

Основополагающие принципы Agile-манифеста

Мы следуем таким принципам:

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Методологии Agile

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

Scrum

Скрам подход был раньше Agile, но именно его автор понимая сложность обучения участвовал в становлении Agile принципов.

Потому что прежде чем вникать даже в базовый скрам-гайд который очень короткий, надо сначала хорошо уловить 12 базовых принципов. Иначе даже читая простой скрам гайд можно наломать дров. Понять все не так и употребляя умные слова – убить весь процесс и завалить проект.

Самый популярный элемент Agile который пришел из Скрам – это спринты. Сегодня спринты есть во многих командах.

Kanban

Kanban – это практика Agile, которая помогает организациям улучшить производительность и эффективность процессов управления проектами и производством.

В Agile практику из Канбан пришли доски – доски очень удобный для визуализации процесса, синхронизации задач и фокусировке команды на результатах.

GTD

Методика Getting Things Done (GTD) предлагает простой и эффективный подход для управления задачами и достижения целей.

Лучше прочитать книгу оригинал чтобы понять базу.

Но самая важная штука которую я от туда взял и которую наблюдаю в Agile командах – это чек листы.

Чек листы по проекту, чек листы по задаче – если описывать результат проекта и результаты по задачам через чек листы – это существенно повышает эффективность разработки.

GIST

GIST фреймворк – это очень интересный способ организации процесса разработки, который описывает подходы как работать с целями, идеями, проектами и задачами – максимально эффективно.

Он ничего не заменяет сам собой, но если его изучить и понять его ключевые фишки – он сильно помогает поднять эффективность разработки.

Про GIST я лично узнал из подскаста основателей WordPress & Twitter. Там основатель WordPress сказал что эта методология одна из тех которые ему нравится больше всего.

Я попробовал – и да теперь почти все мои проекты делаются с учетом этой методологии. По секрету скажу что для организации столь сложной штуки я использую Notion.

OKR

Методология которая получила известность после взлета Google. Но была придумана в основе Intel. Суть ее в том что команды и отделения могут применять все что угодно, но вся организация в целом управляется через дерево OKR.

Все начиная с ген директора пишут свои OKR. Описывают свои цели и ключевые показатели на будущий период. Важно описать цель как смысл и далее 3-4 метрики которые докажут что эта цель достигнута.

Это комбинация субъективных и объективных аспектов. Одна из самых сложных делем в управлении разработкой.

Sociocracy 3.0

Пожалуй это самая новая технология Agile разработки, которая собрала в себя плюсы от всех предыдущих.

• в отличие от Скрама она бесплатна и разрабатывается по принципам OpenSource – всем миром
• в отличие от OKR & GIST – она более комплексная и охватывает больше аспектов процесса разработки
• ее наверное можно сравнить с Kanban – но она моложе и зародилась изначально в среде ИТ, и не тащит за собой хвосты из мира производства автомобилей

Но при этом всем – она же наверное самая сложная для изучения. Тут очень много всего. Однако вдумчиво изучив материалы этой темы – можно существенно лучше организовать процессы.

Многие ошибки понимания которые присущи другим методологиям – тут раскрыты и описаны лучше.

А причем тут вообще WP?

Это сложный философский вопрос )

Начнем с того что WP стал №1 в мире и занял почти 50% всего веб интернета.

Многие думают что причина в том что просто вот так само случилось. Случайная череда событий и везение.

Но реальность в том что случайности не случайны и WP побеждает из-за следования принципам Agile. Умение идти туда где быстрые результаты, и умение думать про ценности.

1. работающий продукт важнее документации – вся архитектура WP сфокусирована на том чтобы быстро получать работающий сайт – будь то сайт организации, блог или магазин
2. вся разработка ведется множеством мотивированных команд и они сами решают как достигать результатов
3. соблюдается GIST подход – есть четкие цели, большой поток идей как что можно улучшить и фокус на том что важно в данный момент времени – проекты и задачи
4. Работающий продукт следует выпускать как можно чаще – в большинстве случаев удается построить процесс так, что от появления задачи до получения результата – проходят часы или дни

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

В рамках гибкой разработки принято разделять проект на несколько итераций (можно сказать спринтов), в рамках каждой из которых необходимо реализовать определённые цели и задачи. Каждая итерация может представлять из себя полноценный проект, даже не связанный с предыдущей итерацией. Основные преимущества гибкой разработки заключаются в следующем:

• Удобное планирование проекта – размер проекта и время его реализации проще оценить по итерациям.
• Быстрый получение результата – каждая итерация даёт возможность оценить результат.
• Долгосрочной сотрудничество – команда будет более стабильной с минимальными рисками потерять разработчиков

Существует множество подходов и практик которые можно назвать гибкими.

Сегодня наиболее популярны следующие Agile идеологии:

• Scrum
• Kanban
• Sociocracy 3.0

Но в основе их всех лежит базовый Agile манифест…

История Agile манифеста

Agile манифест был сформулирован опытными разработчиками с мировым именем, в ответ на ошибки, которые допускают начинающие заказчики и разработчики.

Попытка применять устаревшие подходы к разработке приводит к множеству проблем, конфликтам, потерям денег и провалам.

В 2000 году влиятельные ребята из мира IT, среди которых были Роберт Мартин (автор принципов SOLID и огромного числа книг про программирование) и Джеф Сазерленд (один из авторов Scrum), встретились, чтобы, как говорится, лучше узнать друг друга в надежде, что тесное общение приведет к чему-то интересному.

Каждый из присутствующих был или автором легковесных методик вроде XP или Crystal Methods, или признанным экспертом в разработке ПО. И несмотря на совершенно разные инструменты, выяснилось, что в основе этих подходов лежат общие идеи. Квинтэссенцией этих идей стал Agile Manifesto.

В формулировки приняли участие 12 разработчиков. Манифест переведен на более чем 60 языков мира. Он содержит экстракт опыта из лучших мировых практик.

Прочтение этих принципов не дает гарантии их понимания. Но их важно знать, и пытаться применять. С практикой придет понимание. А с пониманием – придется умение обходить проблемы стороной и добиваться результатов с минимальными рисками и затратами.

Заключение

Самое важное это изучить базовые принципы Agile. Прочитать 7 раз и 10 раз осмыслить. Подумать. Потом еще раз перечитать и еще раз подумать.

Я над этими идеями думаю уже 5 лет и каждый раз замечаю что то новое – нечто упущенное ранее.

Затем можно эксперементировать с другими практиками: Scrum, Kanban, OKR, GIST, Sociocracy …

В целом все будет в плюс и полезно для эффективности и результатов.

Бывает 2 ловушки в которые часто попадают люди:

• не знать в целом что такое Agile и какие практики тут бывают
  • пытаться делать проект за 1 раз – в надежде что получится все и сразу
  • а потом удивляться почему проект еле жив и разработчики разбежались
• думать что Scrum это Agile, что есть только Scrum и следовать ему до буквы
  • в целом лучше чем ничего
  • но тоже бывает веселый цирк и как правило остаются в нем только клоуны

Ловушки приводят к тому что в лучшем случае эффективность команд растет слабо, а в целом бывает так что эффективность команды падает кратно, даже если вы изучили Скрам от корки до корки.

Потому важно 10 раз перечитать Agile манифест, и затем изучить более менее хотя бы 3-4 методологии. Так можно будет увидеть общее и отделить первостепенное от второстепенного.