- PVSM.RU - https://www.pvsm.ru -
Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность.
Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value.
И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”
Отличный, рациональный подход.
В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.
Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?
Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.
А если помножить это на тенденцию снижения среднего уровня технической квалификации инженерных кадров, — это отдельная тема, завязанная на многолетнее превышения спроса над предложением, — то вообще получается отлично. Поминутно вейпая и попивая смузи, можно строить целые системы, просто интегрируя готовые блоки при помощи быдлокода и такой-то матери быстрого прототипирования.
Поэтому — не изобретай велосипеда и не умничай. Используй готовое, а кривые руки умную голову прикладывай там, где интеграция по какой-то причине вдруг не работает.
Отличный, рациональный подход.
Но самое забавное, как всегда, — то, что может случиться на стыке двух отличных, рациональных принципов. Давайте попробуем рассмотреть абстрактный пример, выгодно оттеняющий всю глубину этой проблемы.
До костей рациональна, следует обоим принципам. Вся по Agile, везде Scrum, каждый разработчик точно знает, какой Business Value имеет каждая его задача. Все озабочены повышением эффективности, общим индексом счастья и прибылью организации.
Не компания, а сказка. Любой владелец IT-бизнеса, глядя на неё, пускает слюнки. Сплошная конфетка.
Ведь таких отличных компаний в реальном мире просто не существует.
.
Ну, здесь, — традиционный бардак. Инженеры поминутно травят свои инженерные байки в курилках, любят инженерные задачи, и чихать хотели на User LIfetime Value. Время от времени изобретают велосипеды, хотя в целом держатся в тренде “повторного использования” сторонних компонент.
На словах в компании Scrum, и даже есть итерации. На деле же, — разработка ведётся, как бог на душу положит.
Словом, — чего уж там. Обычная инженерная компания.
Для упрощения нашего сферического коня в вакууме, — обе компании занимаются примерно одним и тем же, перед ними возникают примерно одинаковые задачи, и работают в них инженеры и менеджеры примерно одного уровня.
Так, конечно, не бывает, но правильные подходы должны же, при прочих равных, показывать преимущества Ratio над броуновским движением человеческой материи, верно?
Итак, в обеих компаниях на низовом уровне, в процессе работы над некоей фичей, возникает инженерная проблема. Один из компонентов ведёт себя непредсказуемо, — старая добрая проблема “протекающих абстракций”, помноженная на проблему интеграции, — и инженер, работающий над фичей, не понимает, почему это происходит.
В Anytime Rational инженер, — скажем, Пётр Первый, — сообщает о возникшей проблеме на утреннем стендапе. Скрам мастер уточняет, сколько времени может потребоваться на её устранение. Инженер затрудняется ответить и запрашивает микроспринт на изучение. Владелец продукта говорит, что фича, в общем-то, второстепенная, и выделить больше двух дней он не может. Скрам мастер сокрушается, что общая скорость команды в этом спринте упадёт, — но выделяет Петру микроспринт.
В Somehow Someway перед инженером, — для простоты Петром Вторым, — встаёт точно такая же проблема.
На стендапе он привычно отбарабанивает: “сегодня продолжаю работать над таской SM-134, помощь не требуется”. Он не особо задумывается над смыслом своих слов. Ведь весь его поглощён обдумыванием “этой херни, которая происходит в долбаном модуле, написанном криворукими даунами из Third Party Component Solutions”.
На очередном перекуре он издалека задаёт вопрос ведущему системщику Ярославу Мудрому из смежного отдела, и они, неспешно покуривая, минут 20 обсуждают подробности. Ярослав даёт пару советов, но в глубине души знает, что Пётру они не помогут. Потому что Пётр, конечно, классный парень и всё такое, — но дизассемблер Ярослав ему бы ни за что не доверил.
Пётр Первый ковыряется со своей проблемой уже второй день. Он понимает, что микроспринт, видимо, будет профукан, и на утреннем стендапе говорит, что ему необходима помощь.
“Кто тебе для этого нужен?” — участливо спрашивает скрам мастер.
“В идеале, — Ярослав Мудрый из смежного отдела. Он крутой системщик, и это как раз его профиль” — отвечает Пётр Первый, уже точно зная ответ на этот запрос.
“Оооо, Ярослааав..” — огорчённо тянет скрам мастер, — “ты же знаешь, он очень занят серьёзнейшими задачами, которые очень важны для нашей компании.”
“У тебя же есть ещё один день”, — встревает владелец продукта, — “Давай посмотрим, что получится по результатам микроспринта, и будем принимать решение.”
Пётр Второй в это время, безуспешно перепробовав всё, что посоветовал ему Ярослав, задумчиво дымит в курилке.
“Чего такой смурной?” — благодушно интересуется зашедший на дымок тимлид Иван Грозный.
“Да так… одна херовинка тут..” — мнётся Петр. Ивана Васильевича он уважает, но побаивается, и расписываться в своей неспособности решить задачу не очень-то спешит.
“Ну-ну”, — хитро усмехается Иван, — “небось, опять взялся за дело не по своей квалификации?”
Иван, посмеиваясь, удаляется, а посрамлённый Пётр идёт ковыряться дальше.
“Микроспринт не принёс результатов”, — сообщает Петр Первый. “Мне не удалось докопаться до источника проблемы. Требуется либо привлечение Ярослава, либо дополнительное время на изучение.”
“Ты и так уже два дня..” — начинает закипать владелец продукта, но скрам мастер умело перехватывает управление потенциальным конфликтом.
“Как мы и договорились, был проведён микроспринт на изучение проблемы, и теперь нам необходимо принять решение. Мы либо выделяем дополнительное время на изучение, либо запрашиваем помощь у отдела системной разработки, либо эскалируем проблему и предоставляем принятие решения вышестоящему руководству.”
“А что мы будем эскалировать?” — буркает недовольный владелец продукта. “Какова стоимость решения проблемы? Мы же так ничего и не выяснили.”
“Хорошо, значит, у нас остаётся два варианта.” — примирительно улыбается скрам мастер. “Будем запрашивать помощь или продолжим разбираться сами?”
Все выжидательно смотрят на Петра.
Он нервно сглатывает, но, будучи верным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.
“Отлично.” — говорит скрам мастер, делая пометку в Evernote. “Я узнаю у отдела системной разработки, когда они смогут нам с этим помочь.”
“Пётр, пока что переключайся на следующую по приоритету задачу. Так, это у нас… SM-135, если я не ошибаюсь.”
Пётр Второй, привычно отбарабанив дежурную фразу, продолжает размышлять над поведением модуля, зафиксированным вчера вечером. Однако Иван прерывает его размышления.
“Пётр, а как там твоя проблемка? Уже решил?”
“Эмм… пока нет, сегодня ещё попробую пару подходов..” — глаза Петра избегают внимательного, с прищуром, взгляда Ивана.
“Ну-ну..” — без улыбки произносит Иван.
Пётр Первый увлечённо работает над новой задачей. Он понимает, что до codefreeze осталось совсем немного времени, но стремится закончить хоть что-то в этом спринте, чтобы скорость команды не просела слишком сильно, и релиз продукта вышел с хорошим набором фичей.
Скрам мастер пытается согласовать совместный микроспринт с командой Ярослава, но приоритеты их задач существенно выше, так что перспектива выглядит достаточно безрадостной.
Но Пётр доволен. Наконец-то можно хотя бы на время забыть об этой сложной проблеме, и принести реальную пользу команде и компании в целом.
Петр Второй, поминутно матерясь, сидит за своим рабочим столом, неощутимо слушает в наушниках какой-то тяжеляк и пытается разобраться, “что же, мать его, происходит внутри этой грёбаной помойки!”
На одном экране открыт отладчик, на другом, — дизассемблированный код. Сосредоточенный взгляд Петра постепенно наполняется безнадёгой, и левый глаз уже начинает подёргиваться.
Он не замечает, что за его спиной вот уже десять минут задумчиво молчит Ярослав, — покуда тот, наконец, не похлопывает Петра по плечу.
“А? Что? Какого..” — срывает с головы наушники Пётр. “А, Ярослав… ты чего тут?”
“Да вот, думал тут над твоей проблемкой на досуге… кстати, смотри, тебе бы вот здесь JNE пробросить, — а то ты дальше не продвинешься.”
“Где? А, вот тут вот… и что это даст? Ааа, вона как..” — Пётр снова входит в поток. “А это тут что за хрень?”
“Кривая работа с регистрами. Давай вот так попробуем..” — подключается к нему Ярослав.
“Итак, скорость нашей команды в этом спринте упала на 3 стори поинта. Учитывая, что фича SM-134 была нами в итоге выброшена из спринта, — это вполне ожидаемо. Кстати, Пётр, ты молодец, я не ожидал, что ты успеешь реализовать SM-135.” — скрам мастер привычно проводил ретроспективу, когда в комнату стремительно влетел Ярослав.
“Ребята, я буквально на минуту, извините. Микроспринт согласован, на три дня мы вам выделим Ефима. Он хороший системщик, вдвоём с Петром проблему наверняка успешно решите. Ну, всё, я побежал, извините ещё раз, что прервал ваше ретро.”
Пётр Первый растерянно хлопает глазами. Проблема? Ах, да, вон та, страшная и сложная… бррр…
“Пётр, что там с твоей проблемой??” — грозно вопрошает Иван.
“Нормально всё, Иван Васильевич. Один небольшой глюк остался, — ну, и код потом вылизать. Дня за три точно управлюсь.” — спокойно отвечает Пётр Второй.
“Знаю я твои три дня..” — ворчит Иван. “Давай быстрее заканчивай, у меня уже руководство интересуется, почему мы эту фичу так сильно затягиваем. Скоро ведро вазелина надо будет заготавливать!”
“Да знаю я, Иван Васильевич. Затащим!” — улыбается Пётр.
“По результатам микроспринта с Ефимом оказалось, что на решение проблемы потребуется ещё половина спринта. Или даже целый спринт.” — не вполне уверенно говорит Пётр Первый. Вдвоём с Ефимом они ковырялись над этой проблемой три полновесных дня, но уверенного решения так и не нашли. — “Есть несколько наметок..”
“Наметок, шнаметок!” — взрывается владелец продукта, — “Где решение? Ты точно за неделю это сделаешь??”
“Так, коллеги, давайте успокоимся.” — вмешивается скрам мастер, укоризненно глядя на владельца продукта. “Пётр, я правильно понимаю, что за половину спринта ты можешь не успеть, но уж за целый спринт точно решишь проблему?”
“Да, всё верно.” — отвечает Пётр, пытаясь говорить уверенно.
“Это всё хорошо и здорово, конечно.” — немного успокоившись, рассуждает владелец продукта. “Но готовы ли мы тратить дополнительное время на эту фичу? Мы и так уже потратили силы и время. Мне кажется, надо эскалировать. Рациональность дополнительных затрат лично мне кажется неочевидной.”
“Хорошо, давайте так и сделаем.” — подытоживает скрам мастер.
“Ну, я тут почти закончил. Всё работает, только subroutine бы ещё причесать.” — отчитывается Пётр Второй. “Благо, скиллы по C я мальца подтянул, там фигня осталась.”
“Ну, вот и молодец.” — улыбается Иван. “Причёсывать-то обязательно, или просто очень хочется? Может быть, лучше фичу наконец-то закроешь?”
“А как же моё чувство прекрасного?” — показушно оскорбляется Пётр, потрясая в воздухе руками.
Все инженеры дружно ржут.
“Руководство пришло к выводу, что возобновлять работу над фичей в данный момент нерационально. Business Value не настолько велико, чтобы вкладывать в неё дополнительные ресурсы, да и по срокам получается, что к следующему релизу никак не успеваем.” — сообщает владелец продукта.
“Ну, и слава богу.” — бурчит себе под нос довольный Пётр Первый. “Можно забыть, как страшный сон.”
“Пётр, фича твоя идёт в релиз. Тестами-то покрыл?” — интересуется Иван.
“Ну, так… надо бы ещё добавить..” — мнётся Пётр Второй.
“Вот и добавь.” — веско говорит Иван. “Всё, разошлись, работаем.”
Опытные разработчики знают, что самые сложные проблемы возникают на стыке технологий и модулей, при интеграции, — там, где встречаются две разных системы. При этом обе системы по отдельности могут быть отличными, — прекрасно разработанными, прекрасно работающими. Но на стыке двух прекрасных систем зачастую возникают уродливейшие противоречия.
Внимательный читатель заметит, что и в нашей истории проблема Anytime Rational возникает на стыке двух прекрасно работающих систем — продаж и производства.
Поэтому, когда вы в следующий раз будете вопрошать: “почему, ну почему они не реализовали здесь эту очевидную фичу??”, или “какого чёрта это работает через такую глубокую задницу??” — помните, что дело может быть в протекающих абстракциях на стыке двух и более систем.
Хотя может быть, в конкретном встреченном вами случае дело просто в рукожопости быдлокодеров, разрабатывающих левой пяткой какое-то говно.
Автор: NickPasko
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/264751
Ссылки в тексте:
[1] мозга: http://www.braintools.ru
[2] Источник: https://habrahabr.ru/post/339104/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.