[Перевод] После смерти Agile
Перед вами перевод статьи автора Doug Bridgens, в которой он рефлексирует свой опыт и критически отзывается о Agile. В его статье совсем нет анализа и аргументации, это личные размышления на тему конкретного разработчика.
Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:
Статья имеет небольшой объем и не займет много времени;
Статья поднимает вопрос и дает на него практический ответ;
Статья затрагивает интересную лично мне тему — ретроспективный взгляд на современные тенденции;
Засим все, приятного чтения.
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 doHabrahabr.ru прочитано 6403 раза
