Не так давно я узнал, что, оказывается, есть вторая версия всем известного Agile Manifest. Причем существует уже довольно давно. Удивляет, что про неё слышали весьма немногие (как я, например), хотя именно она демонстрирует важный эволюционный шаг вперед с точки зрения философии разработки программного обеспечения. Хочу порассуждать о трактовке 2.1.
1. Команда и ответственность важнее индивидуумов и взаимодействия.
Почему старое - неактуально? Потому что раньше, чтобы стать разработчиком, нужно было разбираться не только в структурах данных и алгоритмах, но и немножко сечь в архитектуре. Порог входа был в специальность был намного выше, чем сейчас (почти 20 лет назад): инструментарий языков был беднее, фреймворков было меньше, технологии были сложнее, чтобы изучать тему, приходилось вникать самому или общаться на форумах. В таких условиях хороший разработчик действительно был "высокомотивированным специалистом", который должен уметь взаимодействовать с такими же, как и он, профессионалами. Но сейчас порог входа другой. Рынку нужно больше разработчиков, чем есть в наличии, появилось куча курсов, школ и программ обучения, где все разжевано. Иногда до такой степени, что молодым программистам кажется, что они детально владеют ситуацией, что реальные задачи будут сильно схожи с примерами обучения. В итоге, мы сейчас рынок получил кучу зелёных юнцов, которые хотят дохера, а умеют нихера. Кстати, сейчас подобная ситуация кажется похожей и среди продактов.
Так вот, когда мы имеем полчище "так себе" профессионалов, то, чтобы они заменили одного специалиста-индивидума, нужно из них сделать команду и обозначить ответственность для каждого. Командая работа способствует росту всех своих участников, а хорошая команда почти всегда лучше специалиста-индивидума.
Да и сами команды теперь нужно трактовать намного шире. Это уже не просто совокупность разработчиков, тестировщиков, архитекторов или других технических специалистов, но м продактов, маркетологов, ux специалистов, аналитиков и т.д. Потому что подход к построению продуктов стал другим по причине пункта 2.
2. Бизнес ценность важнее работающего продукта
Концепция "работающего продукта" была выдвинута в первом манифесте в ответ на долгий цикл проектирования (читай написания документации) и разработки ПО, когда первую работающую версию продукта получали ближе к концу проекта. И пока работали в таком ключе над проектом, кто-то более гибкий уже запускал продукт и получал прибыль.
Однако, это хорошо работало, когда на рынке потребность в IT продуктах была выше, чем их предложение. Когда не хватало даже необходимых приложений. Концепция minimum viable product - тоже часть этой эпохи, когда ваше "быстренькое" решение должно было проверить гипотезы необходимости тех или иных фич, чтобы долго не лабать никому не нужный продукт.
Но реальность стала другой. Новые технологии позволили создавать продукты в считанные дни, а весьма неплохие продукты за пару месяцев. Но метафора "сделай хороший продукт, и его будут покупать" почему-то перестала работать. Да хотя бы потому что почти любой стартапер почему-то считает свою идею уникальной, когда на рынке уже есть конкурентных продуктов.
В итоге, даже разработав "гибко" продукт, в нем может тупо не оказаться бизнес-ценности. Поэтому именно поиск и разработка бизнес-ценности (product discovery) стала намного важнее самого программного обеспечения. И если команда концентрируется на её поиске, при этом не написав и строчки кода, это правильный подход.
3. Развитие партнёрских отношений важнее сотрудничества с клиентом
Переход от следования условиям контракта к сотрудничеству с клиентом и партнерским отношениям - это путь смещения фокуса с краткосрочных целей на долгосрочное взаимодействие. Когда вы концентрируетесь только на том, чтобы обезопасить себя при помощи пунктов договора, то решаете только свои проблемы, как исполнителя, игнорируя возможность изменения обстановки, связанной с продуктом. С другой стороны, фокусирование только на том, что хочет заказчик разработки / продукта, тоже не несёт ничего хорошего, т.к. можно остаться пребывать в
