Методология eXtreme Go Horse (XGH)

Обсуждая Agile-маркетинг и Agile в целом с иностранным другом, я понял, что люди за пределами Бразилии не знакомы с методологией eXtreme Go Horse. Несмотря на то, что мы видели, что это применимо ко многим компаниям (таким как Tesla), очевидно, что эта широко используемая глобальная методология была подробно описана бразильскими разработчиками только формально. Вот:

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

Источник (португальский): http://sou.gohorseprocess.com.br/extreme-go-horse-xgh/

Перевод: https://gist.github.com/banaslee/4147370

1. Думаю, значит, это не XGH.

В XGH вы не думаете, вы делаете первое, что приходит вам в голову. Второго варианта нет, так как первый быстрее.

2. Есть 3 способа решить проблему.

Правильный путь, неправильный путь и путь XGH; который в точности похож на неправильный, но быстрее. XGH быстрее, чем любой известный вам процесс разработки (см. Аксиому 14).

3. Вам всегда нужно будет делать все больше и больше XGH.

На каждую ошибку, решаемую с помощью XGH, создается еще семь. Поскольку все они будут решаться с помощью XGH, то его полезность стремится к бесконечности.

4. XGH полностью реактивен.

Ошибки возникают только тогда, когда их замечают.

5. В XGH все идет.

Решает проблему? Это скомпилировано? Вы совершаете это и больше об этом не думаете.

6. Вы всегда совершаете фиксацию перед обновлением.

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

7. У XGH нет расписаний.

Расписания, предоставленные вам вашими клиентами, почти важны. Вы ВСЕГДА сможете реализовать ВСЕ вовремя (даже если это означает доступ к базе данных через какой-нибудь сумасшедший скрипт).

8. Будьте готовы покинуть корабль или обвинить кого-то еще, когда он упадет.

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

9. Будьте искренними. XGH не следует шаблонам.

Пишите код так, как считаете нужным. Если это решит проблему, зафиксируйте и забудьте об этом.

10. Не бывает рефакторинга, просто доработка.

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

11. XGH анархичен.

В менеджере проекта нет необходимости. Хозяина нет, и каждый делает все, что хочет, когда появляются проблемы и требования.

12. Всегда верьте обещаниям улучшения.

Помещение комментариев TODO в код в качестве обещания, что код будет улучшен позже, помогает разработчику XGH. Он / она не почувствует вины за то дерьмо, которое он / она натворил. Разумеется, никакого рефакторинга не будет (см. Аксиому 10).

13. XGH является абсолютным.

Сроки доставки и стоимость - вещь абсолютная. Качество относительно. Никогда не думайте о качестве, а думайте о минимальном времени, необходимом для реализации решения. Вообще-то… не думай! Делать! (см. Аксиому 1)

14. XGH - это не прихоть.

Scrum, XP? Это просто тенденции. Разработчики XGH не следят за временными тенденциями. XGH всегда был и всегда будет использоваться теми, кто презирает качество.

15. XGH не всегда является WOP (Программирование, ориентированное на обходное решение).

Многие WOP требуют умного мышления. XGH не требует мышления (см. Аксиому 1).

16. Не пытайтесь идти против течения.

Если ваши коллеги используют XGH, а вы единственный упрямый трус, который хочет делать все правильно, бросьте его! Для любого шаблона проектирования, который вы примените правильно, ваши коллеги сгенерируют в 10 раз больше гнилого кода, используя XGH.

17. XGH не опасен, пока вы не увидите в нем порядок.

Эта аксиома очень сложна, но она говорит о том, что проект XGH всегда находится в хаосе. Не пытайтесь навести порядок в XGH (см. Аксиому 16), это бесполезно. Вы потратите много драгоценного времени, и дела пойдут быстрее.

Не пытайтесь управлять XGH, потому что он самодостаточен (см. Аксиому 11), как хаос.

18. XGH - твой братан. Но это мстительно.

Пока вы этого хотите, XGH всегда будет на вашей стороне. Но будьте осторожны, чтобы не бросить его. Если вы начнете что-то с использованием XGH, а затем обратитесь к какой-нибудь модной методологии, вы облажаетесь. XGH не допускает рефакторинга (см. Аксиому 10), и ваша новая жесткая система рухнет. Когда это произойдет, только XGH может вас спасти.

19. Если он работает, не беспокойтесь.

Никогда не меняйте - и даже не задавайте вопросов - рабочий код. Это пустая трата времени. Тем более, что рефакторинга не существует (см. Аксиому 10).

Время - двигатель XGH, а качество - бессмысленная деталь.

20. Тесты для кисок.

Если вы когда-нибудь работали с XGH, вам лучше знать, что вы делаете. А если вы знаете, что делаете, зачем тогда тестировать? Тесты - пустая трата времени. Если он компилируется - хорошо.

21. Привыкайте к ощущению "жизни на грани".

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

Проект провалился. Вы чему-то научились? Тогда для вас это был успех!

22. Проблема возникает только тогда, когда ваше имя указано в кодовой документации.

Никогда не прикасайтесь к классу кода, автором которого вы не являетесь. Когда член команды умирает или остается в стороне слишком долго, он в конечном итоге выходит из строя. Когда это произойдет, используйте Axiom 8.

— —

Нравится это? Прочтите другие мои истории, например:

Креативность в эпоху данных - Как стартапы и крупные компании могут извлечь выгоду из смешения этих двух миров?