Productivity

Великий парадокс безопасности нашего времени Представьте: ваша организация только что одобрила новый проект по обеспечению безопасности с нулевым доверием. Высшее руководство в восторге. Команда безопасности настроена осторожно оптимистично. Ваша команда разработчиков? Они готовы потратить следующие шесть месяцев на то, чтобы убедиться, что «лучшие практики безопасности» и «выполнение реальной работы» не всегда хорошо сочетаются. Вот неудобная правда, которую никто на корпоративных конференциях по безопасности не хочет признавать: [нулевое доверие теоретически может повысить производительность], но на практике многие реализации создают такие запутанные системы контроля доступа, что сотрудники тратят больше времени на борьбу с театральностью безопасности, чем на выпуск функций....

Никому не нужный «театр оценок» Давайте будем честными: планирование с помощью покерных карт — это, по сути, ритуальный театр, который никому на самом деле не нравится. Вам знакома эта сцена. Кто-то выкрикивает: «Планирование с помощью покерных карт!», и внезапно все замолкают, лихорадочно пытаясь понять, является ли эта конкретная функция входа в систему пятёркой или восьмёркой (или и тем и другим, в зависимости от количества кофе, выпитого разработчиком утром). Ирония в том, что после многих лет, когда команды зацикливались на точках историй, расчётах скорости и последовательностях Фибоначчи, настоящий вопрос остаётся без ответа: сколько времени это займёт на самом деле?...

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

Существует специфическое явление, которое происходит в организациях при введении метрик: все вдруг считают, что нашли секретный ингредиент успеха. Диаграммы появляются на панелях управления, цели выгравированы на стенах командных комнат, и разговоры становятся всё более эмоциональными по поводу достижения этих чисел. Это опьяняет — обещание, что если мы просто будем измерять правильные вещи, всё волшебным образом улучшится. Но вот неудобная правда: иногда лучшее решение, которое вы можете принять относительно своих метрик, — это отказаться от них....

Ваша кодовая база — это хаос. Вы это знаете, и ваша команда тоже. У одной функции 47 параметров. Переменные названы в честь ваших кошек. И где-то там комментарий 2015 года гласит: «TODO: исправить это перед запуском в производство», и голос в нём звучит всё более отчаянно. Естественно, вы поступаете как любой уважающий себя разработчик: берёте обязательство провести масштабную рефакторинг-спринт-доработку. Две недели, думаете вы. Может быть, три. Вы красиво перепишите всё, примените шаблоны проектирования, словно они выходят из моды, и выйдете победителем с кодовой базой, настолько чистой, что по ней можно будет есть....