Agile

Повесть об организованном бедламе Представьте себе картину. Три часа дня, пятница. Ваша команда утопает в pull request. Кто-то работает над функцией X, кто-то исправляет ошибки в функции Y, выпущенной три недели назад, и никто не знает, что делает функция Z — вероятно, она находится в спящем режиме в какой-то ветке. В канале Slack царит какофония из вопросов: «Подождите, мы сегодня деплоим?» и «Я думал, что Jenkins должен автоматически собирать». Знакомо? Добро пожаловать в мир неструктурированной разработки программного обеспечения....

47-минутное «15-минутное» совещание Вы знаете это чувство, когда кто-то говорит «быстрый стенд-ап», а вы смотрите на часы, думая: «Посмотрим-посмотрим». Два часа спустя вы всё ещё слушаете, почему чья-то задача в JIRA застряла, и пропустили три других совещания. Добро пожаловать в страну раздутых стенд-апов, где 15 минут превращаются во что-то, что заставило бы выступление на TED покраснеть от зависти. Вот неудобная правда: ваши ежедневные стенд-апы не сломались из-за того, что концепция плоха....

Посмотрите, я собираюсь сказать кое-что, что может привести к тому, что меня не пригласят на следующую конференцию по Agile: истории пользователей не всегда являются решением. Вот, я это сказал. Прежде чем вы закроете эту вкладку и напишете гневный комментарий о том, что я «не понимаю Agile», выслушайте меня. Я годами наблюдал, как команды религиозно превращают каждое требование в священный формат «Как… Я хочу… Чтобы…», даже когда это было абсолютно неуместно....

Грядёт ересь. Я собираюсь сказать нечто такое, что могло бы заставить вашего преподавателя по информатике перевернуться в своей теоретической могиле: иногда стоит отдавать приоритет срокам, а не качеству кода. Да, вы правильно прочитали. Положите вилы, коллеги-разработчики, — выслушайте меня. Прежде чем начать писать гневные письма о техническом долге и кошмарах с поддержкой, позвольте мне прояснить: я не призываю постоянно писать плохой код. Я говорю о том, что пуристский подход «идеальный код или никакого кода» иногда может нанести больший вред вашему проекту, команде и, как ни странно, вашим пользователям, чем выпуск чего-то работающего, но неидеального....

Представьте: вы сидите в конференц-зале и слушаете консультанта в идеально отглаженных брюках, объясняющего, как их «революционная» методология разработки программного обеспечения решит все ваши проблемы. У них есть диаграммы, аббревиатуры и, конечно же, внушительный счёт. Знакомо? Добро пожаловать в чудесный мир проповедников процессов, где каждый продаёт святой грааль разработки программного обеспечения, и, спойлер, его не существует. Вот неудобная правда, из-за которой сторонники процессов схватятся за свои методические руководства: не существует идеального процесса разработки программного обеспечения....