Agile Manifest 2.1

Не так давно я узнал, что, оказывается, есть вторая версия всем известного Agile Manifest. Причем существует уже довольно давно. Удивляет, что про неё слышали весьма немногие (как я, например), хотя именно она демонстрирует важный эволюционный шаг вперед с точки зрения философии разработки программного обеспечения. Хочу порассуждать о трактовке 2.1.

1. Команда и ответственность важнее индивидуумов и взаимодействия

Почему старое — неактуально? Потому что раньше, чтобы стать разработчиком, нужно было разбираться не только в структурах данных и алгоритмах, но и немножко сечь в архитектуре. Порог входа был в специальность был намного выше, чем сейчас (почти 20 лет назад): инструментарий языков был беднее, фреймворков было меньше, технологии были сложнее, чтобы изучать тему, приходилось вникать самому или общаться на форумах. В таких условиях хороший разработчик действительно был «высокомотивированным специалистом», который должен уметь взаимодействовать с такими же, как и он, профессионалами. Но сейчас порог входа другой. Рынку нужно больше разработчиков, чем есть в наличии, появилось куча курсов, школ и программ обучения, где все разжевано. Иногда до такой степени, что молодым программистам кажется, что они детально владеют ситуацией, что реальные задачи будут сильно схожи с примерами обучения. В итоге, мы сейчас рынок получил кучу зелёных юнцов, которые хотят дохера, а умеют нихера. Кстати, сейчас подобная ситуация кажется похожей и среди продактов.

Так вот, когда мы имеем полчище «так себе» профессионалов, то, чтобы они заменили одного специалиста-индивидума, нужно из них сделать команду и обозначить ответственность для каждого. Командая работа способствует росту всех своих участников, а хорошая команда почти всегда лучше специалиста-индивидума.

Да и сами команды теперь нужно трактовать намного шире. Это уже не просто совокупность разработчиков, тестировщиков, архитекторов или других технических специалистов, но м продактов, маркетологов, ux специалистов, аналитиков и т.д. Потому что подход к построению продуктов стал другим по причине пункта 2.

2. Бизнес ценность важнее работающего продукта

Концепция «работающего продукта» была выдвинута в первом манифесте в ответ на долгий цикл проектирования (читай написания документации) и разработки ПО, когда первую работающую версию продукта получали ближе к концу проекта. И пока работали в таком ключе над проектом, кто-то более гибкий уже запускал продукт и получал прибыль.

Однако, это хорошо работало, когда на рынке потребность в IT продуктах была выше, чем их предложение. Когда не хватало даже необходимых приложений. Концепция minimum viable product — тоже часть этой эпохи, когда ваше «быстренькое» решение должно было проверить гипотезы необходимости тех или иных фич, чтобы долго не лабать никому не нужный продукт.

Но реальность стала другой. Новые технологии позволили создавать продукты в считанные дни, а весьма неплохие продукты за пару месяцев. Но метафора «сделай хороший продукт, и его будут покупать» почему-то перестала работать. Да хотя бы потому что почти любой стартапер почему-то считает свою идею уникальной, когда на рынке уже есть конкурентных продуктов.

В итоге, даже разработав «гибко» продукт, в нем может тупо не оказаться бизнес-ценности. Поэтому именно поиск и разработка бизнес-ценности (product discovery) стала намного важнее самого программного обеспечения. И если команда концентрируется на её поиске, при этом не написав и строчки кода, это правильный подход.

3. Развитие партнерских отношений важнее сотрудничества с клиентом

Переход от следования условиям контракта к сотрудничеству с клиентом и партнерским отношениям — это путь смещения фокуса с краткосрочных целей на долгосрочное взаимодействие. Когда вы концентрируетесь только на том, чтобы обезопасить себя при помощи пунктов договора, то решаете только свои проблемы, как исполнителя, игнорируя возможность изменения обстановки, связанной с продуктом. С другой стороны, фокусирование только на том, что хочет заказчик разработки / продукта, тоже не несёт ничего хорошего, т.к. можно остаться пребывать в перманентном состоянии разработки, так и не достигнув собственных целей. Партнёрские же отношения подразумевают ситуацию «win-win», когда обе стороны достигают поставленных перед ними целей. Как своих собственных, так и совместных. Смотрели фильм «Игры разума»? Там как раз был эпизод про этот принцип, именуемый равновесием Нэша.

4. Готовиться к изменениям важнее реакции на изменения

Последний принцип показывает переход от реактивного подхода к проактивному подходу. Когда вместо следования плану, мы перешли к реакции на изменения, это значительно сократило время создания бизнес-ценности в условиях неопределенности. Но каким образом можно ещё сократить это время? Нужно готовиться к потенциальным изменениям в продукте заранее. Это значит, что меняется подход к разработке продуктов.

Вспомним историю. Когда ПО строилось по «изначальным планам», выраженным в скучных технических заданиях, его разрабатывали долго. Но знаете… Оно работало! Оно реально работало. С переходом на гибкую разработку, реагирующую на изменения, мы получаем продукты быстрее, но их качество оставляет желать лучшего. В итоге ПО, разрабатываемое таким образом, довольно быстро доходит до пределов возможностей своей бизнес-логики, утопая в техническом и архитектурном долге. После чего приходится пилить новый продукт, который бы решить проблемы старой системы. Тем самым та пресловутая гибкость, о которой говорится в манифесте, оборачивается жёсткими ограничениями в развитии.

«Готовность к изменениям», вместо реакции на них, требует иного подхода к разработке. Помимо моральной составляющей, здесь должна быть и технологическая: каким образом спроектировать и разработать продукт, чтобы при новых вводных, мы не столько его переделывали, сколько переконфигурировали (меняли «настройки», но не бизнес-логику). Это требует иного, платформенного мышления, возможно даже частичного возврата к старым методам «тяжёлой» разработки с предварительной проработкой архитектуры и т.д. Готовность к изменениям подразумевает поиск баланса между тяп-ляпом и детальным учётом потенциальных рисков.

Agile Manifest 2.1: 1 комментарий

  1. Уведомление: Итоги 2018 года

Обсуждение закрыто.