Перед вами перевод статьи автора 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 doКонечно, я говорю об Agile в общих чертах. Не все так плохо (привет будущим работодателям!). Но мы действительно кое-что теряем, когда бизнес занимается разработкой программного обеспечения.
Комментарии (7)
dmiche
14.04.2024 19:55+3Любая индустрия проходит фазы становления. Аджайл, на деле, решает всего один вопрос: как структурированному, целе-ориентированному корпоративному менеджменту управлять толпой высокотехнологичных косячников, работу которых не хватает компетенции формализовать, а её оценку привести к общему метрическому знаменателю.
Для того, чтобы этот вопрос был поставлен, разработка ПО должна была пройти путь от тех самых "лабораторий", через "заводики" (специализированные компьютерные фирмы), через появление конкурентного рынка продукции таких "заводиков", к тому, что в любой корпорации теперь есть уже не своя лаборатория, а свой заводик.
Таким образом, если раньше разработкой ПО руководили профессиональные кадры, задачи были медленно меняющимися (бизнес над душой не висел, делался, как правило, универсальный продукт), бюджеты были ограничены, то, после проникновения разработки в корпоративный сектор, всё стало в точности до наоборот:
Денег куры не клюют, универсальность не нужна, потребности "давай-давай-переделай". Именно в этой ситуации аджайл почти идеален. Как только что-то из этого пропадает (а сегодня оно у американов опять пропадает, потребности стандартизуются, копипастеры совершенствуются), аджайл становится пятым колесом в телеге.
При этом, необходимо отметить, что в России по этим параметрам мы до нормального аджайла ещё и не доросли даже - у нас в инженерке ещё впереди это состояние, лет через 15. Сейчас аджайл бы, скорее, в науке и образовании прижился - там паттерн условий соответствует.
bloomdido
14.04.2024 19:55Можете не читать Agile Manifesto, а прочесть только список его "подписантов" и подумать о том, много ли среди них "бизнеса". Аджайл придумали разработчики успешных проектов (а вовсе не бизнес), которым пришлось реализовывать массу новых фич, поток которых был обусловлен успехом проектов. Затем он был подхвачен "стартап-культурой", у которой были аналогичные запросы.
ManGegenMann
14.04.2024 19:55+2На самом деле беда ИТ в том что сюда пришли менеджеры, коучи, аналитики и прочие инфоцыгане. Вместе с собой они притащили и свои методы работы где важно громче всех кукарекать и проводить ИБД, притащили звонки, согласования, встречи, демо и прочее.
Как только Гугл, Амазон, Яндекс и прочие смогли создать свой бизнес. Ведь у них небыло скрама и штата цыган, зато был штат специалистов которых никто не трогал.
Клиенту не нужны ваши фичи, еженедельные поставки и прочее. Ему нужен законченный продукт. Чтобы не пытаться находу выяснить его требования можно привести аналитку, этап планирования проекта, проектирование архитектуры и прочее. В идеале система должна быть полностью готова ещё до того как будет создан первый файл проекта.
Люди забыли как строить UML и ER и прочие диаграммы. Забыли как писать документацию. В проектах которые я вижу документация это просто поток сознания и куски проектных решений, зато микросервисы. "После меня хоть потоп" вот девиз менеджеров проектов, тимлидов да и вообще всех. Главное сейчас прям тут выдать больше фич и КПИ, а дальше с почестями уйти пока никто не понял что ты тут накакал.
Я и сам видя проблемы в проекте вместо их решения стал создавать встречи, заводить задачи с описанием что нужно сделать, сообщать всем. Мог бы за 2ч все сделать, но тогда я ничего не получу, а так я получу почёт и уважение ведь я активный и деятельный. Только вот проблема не решена. Почему? Потому что всем плевать на проект, главное соблюдать КПИ и ИБД.
WebPeople
14.04.2024 19:55+1Клиенту не нужны ваши фичи, еженедельные поставки и прочее. Ему нужен законченный продукт.
Вы у всех клиентов в мире об этом спросили?) Всем клиентам нужно, чтобы доработки и новые фичи выходили максимально быстро. Этого требует современный рынок. Законченный продукт это какой? Которым никто не пользуется? Живой продукт постоянно дорабатывается и меняется.
В идеале система должна быть полностью готова ещё до того как будет создан первый файл проекта.
Такое проектирование возможно лишь для самых простых и примитивных систем. А сложные системы - пока будут проектироваться, уже устареют))
В проектах которые я вижу документация это просто поток сознания и куски проектных решений
Это проблема лишь вашей организации. Не везде так. Хотя в целом, встречается часто. Низкоквалифицированные It-шники бывают косноязычны, не любят схемы и документирование, а ещё частенько неграмотны, постоянно недовольны всем вокруг.
всем плевать на проект, главное соблюдать КПИ и ИБД.
Опять таки, зависит от компании. Если у вас заказная разработка, то в целом да, плевать. Если вам не хватает "почета и уважения", то продолжайте делать как делаете.
Или можете повзрослеть. И потратить свое время с пользой - прокачивая свои навыки. Почитайте умные книги, чтобы понять, для чего менеджер проводит демо перед клиентом, для чего он созвоны устраивает и т.д. Это софт скиллы. Улучшайте свои технические навыки, делайте диаграммы и т.п., не ожидая "почета и уважения". Ради себя и своих навыков. И в будущем, может быть уже даже в другой компании, это будет оценено по достоинству. Станете сеньором, тимлидом, потом руководителем отдела, может даже техническим директором. И там у вас будет настоящий "почет и уважение", а не тот суррогат, который вы сейчас пытаетесь получить, занимаясь хернёй.
northartbar Автор
14.04.2024 19:55По-моему это спор о форме, а нужно сфокусироваться на содержании то есть суть бизнеса это количество заработанных денег.
И agile, waterfall или конвейер на заводе форда будет оцениваться только с этой позиции.
Если ваш операционный руководитель любит замыкать все на себе, то будьте готовы ему напоминать и ждать его визирование, если он склонен делегировать, то будьте готовы общаться с скрам мастерами.
Повторю, на мой взгляд это лишь форма процесса, надстройка над людьми которые пишут код, если они не могут самоорганизовываться они ищут себе pm-ов, а как их труд организовывается это лирика.
Что бы выяснить что лучше нужно решить, лучше это про что? «Лучше» - всегда в конечном итоге про деньги. Человеко часы это себестоимость продукта.
Все что до сих пор не реализовано, не запущено, не разработанно является таковым только по причине дороговизны. MVP показывает, что дорого и ваш проект кладут под сукно.
Может хороша та методика которая раньше позволит определить это «дорого».
И давайте для себя определимся наконец, за что нам платят деньги? На мой взгляд нам платят деньги чтобы с нашей помощью перетащить таску из in process в done. На этом все, нам как рядовым разработчикам больше ничего не нужно делать, нет задачи оценивать или критиковать. Может это звучит цинично, но мой личный опыт подсказывает мне именно это. Если ты закрываешь таски в срок, не нарушаешь трудовую дисциплину, ты идеальный сотрудник, ты получишь все! Возможно даже решат что раз ты так хорошо решаешь таски, то пора тебе самому эти таски назначать, тут скорей всего бизнес потеряет хорошего разраба и получит плохого менеджера )
sergeyssv
Без последней строки (у автора текста она есть) текст не закончен
northartbar Автор
Благодарю!