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


24

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

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


1
Я не слышал об этом раньше, но мне это кажется немного противоречивым. Они говорят: «... формальность и правила ограничивают креативность и продуктивность», но в то же время они регулярно проводят постоянные встречи (как часть методологии?). Я не могу поверить, что описание такой методологии начинается с установления правила.
Джорджио

Читая об этом в первый раз, мне кажется, это было сделано человеком или людьми, которые имели опыт работы только с наполовину Agile. Потому что эта «Анархия разработчика» является примером из учебника «Agile сделано правильно». Например. правильно реализована гибкая.
Эйфорическая

Кажется, первая ссылка, на которую вы ссылаетесь, уже содержит все, что вы ищете.
Майкл Боргвардт

2
Какое прекрасное модное слово!
CesarGon

1
@CesarGon: умные слова легче придумать, чем действительно новые методологии. ;-)
Джорджио

Ответы:


46

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

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

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

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

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

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

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

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

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


14
«Однако сегодня слишком много вещей, которые считаются обязательными, и« гибкая »методология спускается в систему, в которой больше процессов, чем в старых методах!»: Вы попали в важный момент (+1). Я работал со SCRUM в команде опытных разработчиков, и, по нашему мнению, через два года ... мы были более проворными раньше, когда у нас не было ежедневных встреч (мы встречались два раза в неделю) и многих других мероприятий. произошло «когда команда решает, что они нужны», а не «когда методология предписывает их».
Джорджио

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

Gahhh ... этот цикл звучит точно и удручающе.
Грэм


1
@syrion: Вы можете быть правы. Я где-то читал, что гибкие практики работают на опытных программистов. Тогда такие опытные программисты, которые обучали неопытные команды, должны были написать правила для них (потому что непрерывное обучение стоит дорого, и лучше записать некоторые правила в книгу). Таким образом, были разработаны новые методологии, такие как SCRUM и тому подобное: теперь люди могут продавать книги или сертификаты. Но настоящий дух гибкости заключается в применении вашего собственного здравого смысла вместо правил, написанных другими. Правила - это руководящие принципы, но многие считают их религией.
Джорджио
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.