После смерти Agile

Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

1. Статья имеет небольшой объем и не займет много времени;

2. Статья поднимает вопрос и дает на него практический ответ;

3. Статья затрагивает интересную лично мне тему - ретроспективный взгляд на современные тенденции;

Засим все, приятного чтения.

What Happens After Agile Dies?

Я начал программировать в 1990-х, работая над Unix OS. Наш "офис" в те времена назывался лабораторией, и мы почитали старожилов, которые работали только по ночам, а обновления рассылали по электронной почте в виде разрозненных файлов.

Google, Linux, Amazon, cookies, Wi-Fi, ноутбуки и т.д. - все это еще впереди. В то время восторг вызывала технология DNS, стремительно набиравшая популярность и в последствии обеспечившая что-то под названием World Wide Web.

В это время я работал на SCAFS, который представлял собой аппаратный кэш между ОС и жесткими дисками. Он кешировал SQL-запросы и обеспечивал прирост производительности более чем в 20 раз! Отличный результат для времен SCSI шин.

Тогда мы представляли из себя небольшую команду специалистов в разных областях от разработчиков до менеджеров по продажам. У нас были баги, фичи и роадмап. Мы много общались с клиентами и принимали участие в торговых выставках.

Наш продукт был автономным, но в тоже время интегрированным с ОС и БД. По-моему мы выпускали обновления каждые три месяца, а багфиксы выкатывались еще быстрее (и это на магнитных лентах!).

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

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

Нам не навязывали никаких формальных рамок. Управление и микроменеджмент нужены были только несформированным командам, от нас ждали, что мы будем взрослыми. Идеи и мнения свободно распространялись, в отличии от нынешнего времени (как иронично!) - времени догматичных кафкианских процессов.

Я в унынии от того, что бизнес сделал с процессом разработки. Agile - это бизнес версия процесса проектирования, навязанная разработчикам как саморазвитие. Это культ, подпитывающий нарциссизм.

Сейчас я работаю над веб-приложением и мои мысли заняты тем, как писать меньше кода. В 11 000 строк, скорее всего, будет меньше ошибок, чем в 22 000?
Один из рисков соло разработки заключается в том, что проект будет забирать огромное количество времени на поиск и исправление багов. Это чистый бизнес подход.

Хочешь меньше времени тратить на код - нужно больше времени уделять разработке, в итоге остается еще меньше времени на код...

Я стремлюсь к еженедельному деплою. И вот мой шаблон.

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

С пятницы по воскресенье я пишу код. Когда не нужно принимать никаких дизайнерских (архитектурных) решений, кодить легко и быстро.

Этот подход противоречит Agile. Интуитивно противоречит тому, к чему мы привыкли, но попробуйте сами: попробуйте выполнить задание AdventOfCode, потратьте пару дней на разработку плана и только потом садитесь за клавиатуру.

Потратить 80% на планирование и 20% - на реализацию может показаться нелогичным. Но это приводит к ускорению разработки, снижению эксплуатационных расходов и повышению мотивации. Это меняет ситуацию, когда вы понимаете, что разработка хорошего программного обеспечения на самом деле не сводится к написанию кода.

Такой способ планирования на самом деле не является чем-то новым. Он направлен на более эффективную коммуникацию. В моем случае, я коммуницирую с собой в будущем с помощью пошагового руководства.

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

Поэтому в мире пост-Agile разработки компании, отказывающиеся от микроменеджмента и принимающие идею автономной разработки, будут создавать более качественный продукт.

Шаблон

Я создал этот шаблон в приложении Things 3 для Mac и iOS. Мне нужно было простое управление задачами, которое я мог бы читать и редактировать на ходу. Возможность отображения задач в виде виджета на главном экране отлично подходит как ограничение объема.

#### Trigger

What happened to make this worth doing.

#### Purpose

What functionality MUST be delivered.

#### Strategy

- High level decisions I will take to do this.

#### Thoughts

- Any context to decision making, peripheral things, knock-on's, etc.

#### Walkthrough

- [ ] First thing to do

A task description. Adding pseudo code lets me evolve function/var names and types as I build up the walkthrough tasks.

func loadData(id int64) account.Data {
    if !dataExists(id) {
        fetchData(id)
    }
    return getData(id)
}

- [ ] Second thing to do

Конечно, я говорю об Agile в общих чертах. Не все так плохо (привет будущим работодателям!). Но мы действительно кое-что теряем, когда бизнес занимается разработкой программного обеспечения.