[Перевод] Спринты — самая большая ошибка в программной инженерии, примите eXtreme Go Horse
Да, давайте немного поговорим о том, как быть Agile и о бразильском определении Agile, которое в современном состоянии породило методологию «eXtreme Go Horse» («лошадью ходи).
Заблуждения
Прежде всего, нужно избавиться от распространенных заблуждений.
Agile о том, как двигаться быстро
К настоящему времени мы все знаем, что Agile — это не про то, чтобы быть быстрее. Речь идет о том, чтобы скорее и в постоянном режиме предоставлять ценность и иметь возможность раньше реагировать и менять курс.
Спринт — это выполнение всего в отведенное время
Итак… вы говорите, что Agile — это не про быстроту, но в нем так же есть наличие… спринтов?
Возможно, это неудачный термин, который использовали разработчики Scrum, но он определенно не помогает всем тем, кто считает, что «Agile — это быть быстрым».
Однако спринты — это всего лишь временные рамки для выполнения определенного объема работы.
Проблема
Руководители настаивают на Agile и Scrum, потому что они думают о быстроте, спринтах!
Но самая большая проблема заключается в том, что создание программного обеспечения — это не спринт, а марафон.
И если вы человек, то вы знаете, что марафон нельзя пробежать спринтами. Это очень плохая идея.
Черт! Большинство людей не могут пробежать даже короткую дистанцию спринта. И это также относится к программному обеспечению.
Результат — люди
Выгорание. Проще говоря, профессия теряет много хороших людей из-за выгорания.
Не путайте с графиком «burndown» из Scrum, но почему-то он не вызывает недоумения у тех же людей, ожидающих от разработчиков все большего и большего.
В свое время в компаниях было слишком много разработчиков, многие из которых занимались в основном раздуванием функций программного обеспечения и «не создавали достаточной ценности». Затем начались массовые увольнения (или они продолжаются до сих пор), и теперь разработчики еще больше перегружены работой.
Результат — программное обеспечение
Поскольку люди вынуждены работать быстро, а потом еще быстрее, качество падает, а «быстро и грязно» становится нормой.
Нет времени на тестирование, нет времени на качество кода, на чистый код и хорошие практики, но всегда есть время и сверхурочные для исправления ошибок.
Создавайте программное обеспечение не быстро, а последовательно
Первое, что люди видят в новых фреймворках, это то, как быстро они могут сделать «todo app»…, но это не та реальность, которую видит большинства из нас.
Сходите лошадью, чтобы быстро и грязно сделать большую миску мутной пасты — это хорошо для MVP, побочного проекта или проекта на скорую руку. Но в большинстве случаев вы будете работать над чем-то месяцами.
Важно сделать что-то одно быстро, а затем замедляться с каждой новой функцией, пока вы не спрыгнете с корабля (аксиома XGH 8) или не решите переписать все заново (см. аксиому XGH 10).
XGH: eXtreme Go Horse
Когда я писал этот пост, до меня дошло, что XGH известен только бразильским разработчикам, а во всем мире — мало.
Фреймворк был сделан неизвестно когда, неизвестно кем, немного устарел в написании (я подредактирую по мере необходимости), но, как вы увидите… он вне времени (см. аксиому 14) и имеет отношение к тому, о чем я говорил.
Отказ от ответственности: Это, по сути, список того, как «не делать». Он забавен как мем, но, как я люблю говорить, что если все, что вы делаете, — это вещи из мемов… то ваша жизнь — шутка.
Было несколько переводов, но этот я сделал сам, пытаясь обновить пункты, чтобы они имели больше смысла сегодня.
Наслаждайтесь, но не следуйте ему.
Маленькое примечание: люди обычно читают XGH как «go horse».
Манифест eXtreme Go Horse
1. Если вам нужно думать, то это не XGH
В XGH вы не думаете, вы делаете первое, что приходит в голову. Нет второго варианта, единственный вариант — самый быстрый.
2. Есть 3 способа решения проблемы: правильный, неправильный и XGH, который похож на неправильный, но быстрее
XGH быстрее, чем любая другая известная вам методология разработки программного обеспечения. (см. аксиому 14).
3. Чем больше XGH вы делаете, тем больше вам придется делать
Для каждой проблемы, решенной с помощью XGH, будет создано еще около 7. Но все они будут решены с помощью XGH. XGH стремится к бесконечности.
4. XGH полностью реактивен
Ошибки существуют только тогда, когда они всплывают на поверхность.
5. XGH принимает все
Решили проблему? Скомпилировали? Коммитим и все.
6. Всегда коммитьте перед обновлением
Если что-то случится, ваша часть всегда будет правильной…, а ваши коллеги могут идти в жопу.
7. У XGH нет дедлайна.
Сроки, установленные вашим клиентом, — это всего лишь детали. Вы ВСЕГДА сможете реализовать ВСЁ в отведённое время (даже если для этого придётся обращаться к базе данных с помощью левого скрипта).
8. Будьте готовы спрыгнуть с корабля, когда он начнет тонуть… или обвинить кого-то или что-то еще
Для тех, кто использует XGH, однажды корабль утонет. Чем больше времени проходит, тем больше система превращается в монстра. В день, когда дом рухнет, лучше обновить LinkedIn или иметь того, на кого можно свалить вину.
9. Будьте аутентичны, XGH не уважает стандарты
Пишите код как хотите, если он решает проблему, коммитьте и все.
10. Рефакторинга нет, есть только доработка
Если случилось дерьмо, быстро сделайте XGH, который решает проблему. В тот день, когда переделка повлечет за собой переписывание всего приложения, спрыгивайте с корабля — лодка утонет (см. аксиому 8).
11. XGH полностью анархичен
Фигура менеджера проекта абсолютно одноразовая. Нет владельца, каждый делает то, что хочет, когда возникают проблемы и требования (см. аксиому 4).
12. Всегда обманывайте себя обещаниями улучшений
Помещение TODO в код в качестве обещания улучшения помогает разработчику XGH не чувствовать угрызений совести или вины за сделанное им дерьмо. Конечно, рефакторинг никогда не будет выполнен (см. аксиому 10).
13. XGH абсолютен, он не цепляется за относительные вещи
Время и стоимость — абсолютны, качество — абсолютно относительно. Никогда не думайте о качестве, только о кратчайшем времени реализации решения, на самом деле… не думайте, просто сделайте это!
14. XGH неподвластен времени
Scrum, XP… все это лишь причуды. XGH не цепляется за сиюминутные течения, они для слабаков. XGH всегда использовался и будет использоваться теми, кто пренебрегает качеством.
15. XGH — это не всегда программирование, ориентированное на обходной путь (Workaround-Oriented Programming)
Многие программы, ориентированные на обходной путь, требуют очень высокого уровня мышления, но XGH не думает (см. аксиому 1).
Примечание переводчика: в оригинале используется «Gambiarra Oriented Programming». Поскольку я понимаю, что некоторые люди знают, что такое «гамбиарра»… это более объемный термин, чем просто «хак» или «обходной путь».
16. Не пытайтесь плыть против течения
Если ваши коллеги используют XGH для программирования, а вы — приверженец правильного подхода, забудьте об этом! На каждый паттерн проектирования, который вы используете правильно, ваши коллеги сгенерируют в 10 раз больше гнилого кода, используя XGH.
17. XGH не опасен до тех пор, пока не возникнет небольшой порядок
Эта аксиома очень сложна, но предполагает, что проект, использующий XGH, находится посреди хаоса. Не пытайтесь добавить порядок в XGH (см. аксиому 16), это бесполезно, и вы можете потерять драгоценное время. Это приведет к тому, что проект будет тонуть еще быстрее (см. аксиому 8). Не пытайтесь управлять XGH, он самодостаточен (см. аксиому 11), как и хаос.
18. XGH — ваш союзник, но он мстителен
Так долго, как вы хотите, XGH всегда будет на вашей стороне. Но будьте осторожны, не отказывайтесь от него. Если вы начнете создавать систему на XGH и бросите ее, чтобы использовать модную методологию, вам конец. XGH не допускает рефакторинга (см. аксиому 10), и ваша новая система, полная наворотов, рухнет. И в этот момент только XGH сможет вас спасти.
19. Если это работает, не трогайте это
Никогда не меняйте, тем более не подвергайте сомнению, работающий код. Это пустая трата времени, тем более что рефакторинга не существует (см. аксиому 10). Время — это шестеренка, которая двигает XGH, а качество — незначительная деталь.
20. Тестирование — для слабаков
Если вы приложили руку к системе XGH, вам лучше знать, что вы делаете. А если вы знаете, что делаете, зачем тестировать? Тестирование — пустая трата времени, если код компилируется, этого достаточно.
21. Привыкните к ощущению неизбежного провала
Неудача и успех всегда идут рука об руку, и в XGH это не так. Люди часто думают, что шансы на провал проекта с использованием XGH всегда выше, чем на его успех. Но успех и неудача — это вопрос перспективы. Проект не удался, но вы чему-то научились? Значит, для вас это был успех!
22. Проблема ваша только тогда, когда ваше имя указано в git blame.
Никогда не прикладывайте руку к файлу, автором которого являетесь не вы. Если один из членов команды умрет или будет долго болеть, лодка утонет! В этом случае используйте аксиому 8.
23. Больше — значит больше
В XGH вы процветаете за счет дублирования кода — качество кода не имеет значения, и нет времени на абстракции, code review или рефакторинг. Время имеет большое значение, поэтому копируйте и вставляйте быстро!
24. Код — это документация
В XGH код — это единственная необходимая документация. Комментарии и дополнительная документация — пустая трата времени. Если кто-то не может понять, как работает код, ему не стоит над ним работать (см. аксиому 20).
25. Безопасность не имеет значения
В XGH безопасность — это второстепенная деталь. Реализация надежной защиты — пустая трата времени (см. аксиомы 5 и 7). Поверьте в удачу, в отсутствие интереса со стороны хакеров и в аксиому 8.
