Что такое анархия разработчика?

Я читал об анархии разработчика (или программиста), которая, как представляется, выставлена ​​как методология пост-гибкой разработки. Я нашел несколько ресурсов ( 1 , 2 ), но, похоже, их там немного .

Мне было интересно, есть ли у кого-нибудь хорошие ресурсы, где я мог бы узнать больше об этом _ как реализовать это, плюсы и минусы, сравнение с другими методологиями и т. Д.

Я могу указать вам на мысли Элистера Кокберна об этом аспекте «настоящих» гибких проектов:

Один из членов методологии семейства Crystal - Crystal Clear. Crystal Clear можно описать слушателю 3-го уровня следующими словами:

«Поместите 4-6 человек в комнату с рабочими станциями и досками и доступом для пользователей. Попросите их предоставлять работающее, протестированное программное обеспечение пользователям один или два месяца, а в остальном оставляйте их в покое ».

На самом деле я описал Crystal Clear в этих словах опытному спонсору проекта. Он следовал этим инструкциям и через пять месяцев сообщил: «Мы сделали то, что вы сказали, и это сработало!»

Несколько месяцев спустя я взял интервью у руководителя группы, и его доклад был примерно таким же коротким, как мои инструкции:

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

это то, что было гибким, и, похоже, это подход, использованный методологией Анархии - суть в том, что, если у вас есть опытные парни , то вы можете сказать им, чтобы они «убирались и заставляли это работать», и они будут делать именно это , (это не работает с менее опытными людьми, вы не позволите команде юниоров сделать это без какого-либо надзора).

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

Однако сегодня слишком много вещей, которые считаются обязательными, и «гибкая» методология спускается в систему, которая имеет больше процессов, чем старые методы!