Agile

Когда я впервые столкнулся с методологией Agile около десяти лет назад, это было похоже на открытие огня. Наконец-то у нас появилась система, которая обещала гибкость, быстрые итерации и свободу от бюрократических оков Waterfall. Мы собирались быть другими. Мы собирались быть быстрыми. Мы собирались носить худи и проводить стоячие встречи о стендапах. Затем произошло нечто забавное. Мы настолько увлеклись Agile, что забыли, зачем начали её использовать. Мы стали адептами Agile, и, как и в большинстве случаев фундаментализма, мы упустили из виду первоначальную цель....

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

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

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

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