Предисловие Ни для кого не секрет, что правильно выстроенные бизнес-процессы нужны каждому.
Отдельные граждане, ведомства и целые компании с холдингами ходят кругами и воют о необходимости правильной организации каждого процесса.
Все должно быть рассчитано, измерено, запланировано и выполнено в срок, в рамках жесткого бюджета.
Метрики и KPI, предсказуемость и прозрачность.
Agile должен быть «внедрён» везде.
Каждый должен мыслить в терминах бережливого производства.
Каждый должен думать о ценности бизнеса.
И, проснувшись ночью, мгновенно ответить на вопрос: «Какой LTV у нашего пользователяЭ» Отличный, рациональный подход. В разработке программного обеспечения уже давно прочно утвердилась тенденция «не изобретать велосипед».
Вам нужно разработать инсталлятор для нашего мегапродукта? Интегрироваться с внешней системой? Разработать кучу отчетов? Не умничайте, возьмите коробочное решение.
Вы сэкономите массу времени, нервов и, как следствие, денег компании.
А если помножить это на тенденцию к снижению среднего уровня технической квалификации инженерных кадров - это отдельная тема, связанная с многолетним превышением спроса над предложением, - то результат вообще отличный.
Постоянно куря и попивая смузи, вы можете строить целые системы, просто интегрируя готовые блоки с помощью реднек-кода и такого-то быстрого прототипирования.
Поэтому не изобретайте велосипед и не умничайте.
Используйте то, что готово, и заставляйте свою умную голову работать там, где интеграция по каким-то причинам вдруг не работает. Отличный, рациональный подход. Но самое смешное, как всегда, то, что может произойти на пересечении двух различных, рациональных принципов.
Попробуем рассмотреть абстрактный пример, подчеркивающий глубину этой проблемы.
Итак, знакомьтесь с нашими героями
В любое время Rational Inc.
Она рациональна до глубины души и следует обоим принципам.Все Agile, Scrum повсюду, каждый разработчик точно знает, какую бизнес-ценность имеет каждая из его задач.
Все озабочены повышением эффективности, общего индекса счастья и прибыли организации.
Не компания, а сказка.
Любой владелец IT-бизнеса, глядя на нее, пускает слюни.
Сплошная конфетка.
Ведь таких отличных компаний в реальном мире просто не существует.
ООО "Как-нибудь как-нибудь"
.Ну, тут традиционный бардак.
Инженеры постоянно рассказывают свои инженерные сказки в курилках, они любят инженерные задачи, и им хотелось чихнуть на пожизненную ценность пользователя.
Время от времени они изобретают велосипед, хотя в целом следуют тенденции «повторного использования» сторонних компонентов.
На словах в Scrum-компании даже есть итерации.
На самом деле разработка ведется так, как Богу угодно.
Одним словом, что там? Обычная инжиниринговая компания.
Если упростить нашего сферического коня в вакууме, обе компании делают примерно одно и то же, перед ними стоят примерно одни и те же задачи, у них работают инженеры и менеджеры примерно одного уровня.
Такого, конечно, не бывает, но правильные подходы должны при прочих равных условиях показывать преимущества Соотношения перед броуновским движением человеческой материи, не так ли? Итак, в обеих компаниях на низовом уровне, в процессе работы над определенной фичей, возникает инженерная проблема.
Один из компонентов ведет себя непредсказуемо — старая добрая проблема «дырявых абстракций», помноженная на проблему интеграции — и инженер, работающий над фичей, не понимает, почему это происходит.
Хронология проблемы
1 день
Инженер Anytime Rational, скажем, Петр Первый, сообщает о проблеме на утреннем стенде.Скрам-мастер указывает, сколько времени может потребоваться на решение проблемы.
Инженер затрудняется с ответом и запрашивает микроспринт для изучения.
Продуктовладелец говорит, что фича, в общем-то, второстепенная, и больше двух дней он выделить не может. Скрам-мастер сетует, что общая скорость команды в этом спринте упадет, но назначает Петре микроспринт. В «Как-то как-то» инженер — Петр Второй для простоты — сталкивается с точно такой же проблемой.
На стенде он привычно отбарабанивает: «сегодня продолжаю работу над заданием СМ-134, помощь не нужна».
Он не особо задумывается о значении своих слов.
Ведь весь его мозг поглощен мыслями об «этой херне, которая творится в гребаном модуле, написанном кривыми людьми из Third Party Component Solutions».
Во время очередного перекура он издалека задает вопрос ведущему системному инженеру Ярославу Мудрому из смежного отдела, и они, не спеша куря, около 20 минут обсуждают детали.
Ярослав дает несколько советов, но в глубине души знает, что Петру они не помогут. Потому что Петр, конечно, классный парень и все такое, но Ярослав никогда бы ему не доверил дизассемблер.
День 2
Рациональное в любое время
Петр Великий уже второй день возится со своей проблемой.Он понимает, что микроспринт, видимо, окажется напрасным, и на утреннем стендапе говорит, что ему нужна помощь.
«Кто вам для этого нуженЭ» — сочувственно спрашивает Скрам-мастер.
«В идеале», — Ярослав Мудрый из профильного ведомства.
Он крутой системотехник, и это как раз его профиль», — отвечает Петр Первый, уже точно зная ответ на этот запрос.
«Ооо, Ярослав… — грустно протягивает Скрам-мастер, — ты знаешь, он очень занят серьезными задачами, которые очень важны для нашей компании».
«У вас есть еще один день», — вмешивается владелец продукта.
— «Давайте посмотрим, что произойдет в результате микроспринта, и мы примем решение».
Как-то так или иначе
В это время Петр Второй, безуспешно испробовав все, что советовал ему Ярослав, задумчиво курит в курилке.«Почему такой мрачныйЭ» — самодовольно спрашивает зашедший покурить бригадир Иван Грозный.
«Да, так.
тут есть одна фигня.
» - Питер колеблется.
Он уважает Ивана Васильевича, но боится и не спешит признать свою неспособность решить задачу.
— Ну-ну, — лукаво усмехается Иван, — ты, небось, опять взялся за дело сверх своей квалификации? Иван, смеясь, уходит, а пристыженный Петр продолжает ковыряться.
День 3
Рациональное в любое время
«Микроспринт не принес результатов», — сообщает Петр Великий.«Мне не удалось добраться до источника проблемы.
Требуется либо участие Ярослава, либо дополнительное время на учебу».
«Вы занимаетесь этим уже два дня…» — начинает кипеть владелец продукта, но Скрам-мастер умело берет потенциальный конфликт под контроль.
«Как мы и договаривались, был проведен микроспринт для изучения проблемы, и теперь нам нужно принять решение.
Мы либо выделяем дополнительное время на изучение, либо запрашиваем помощь у отдела разработки систем, либо эскалируем проблему и оставляем решение вышестоящему руководству».
«Что мы будем обострятьЭ» — бормочет недовольный продактовенец.
«Какова стоимость решения проблемы? Мы до сих пор ничего не выяснили».
— Хорошо, тогда у нас остается два варианта.
— Скрам-мастер примирительно улыбается.
«Попросим помощи или продолжим разбираться самиЭ» Все выжидающе смотрят на Питера.
Он нервно сглатывает, но, будучи истинным сторонником идеалов Agile, честно и открыто сообщает, что ему нужна помощь.
"Большой.
" — говорит Scrum Master, делая заметку в Evernote. «Я свяжусь с отделом разработки систем, чтобы узнать, смогут ли они нам в этом помочь».
«Питер, а пока переключись на следующую приоритетную задачу.
Итак, вот что мы имеем.
СМ-135, если не ошибаюсь.
Как-то так или иначе
Петр Второй, привычно отбарабанив рутинную фразу, продолжает размышлять над записанным вчера вечером поведением модуля.Однако его размышления прерывает Иван.
«Питер, в чем твоя проблема? Ты уже решилЭ» «Эмм.
пока нет, сегодня попробую еще пару подходов.
» - глаза Петра избегают внимательного, прищуренного взгляда Ивана.
«Ну-ну…» — без улыбки говорит Иван.
День 5
Рациональное в любое время
Петр Первый с энтузиазмом работает над новой задачей.Он понимает, что до заморозки кода осталось совсем мало времени, но стремится хоть что-то закончить в этом спринте, чтобы скорость команды не упала слишком сильно, и продукт вышел с хорошим набором функций.
Скрам-мастер пытается договориться о совместном микроспринте с командой Ярослава, но приоритеты их задач значительно выше, поэтому перспектива выглядит достаточно безрадостной.
Но Питер счастлив.
Наконец-то вы сможете хотя бы на время забыть об этой непростой проблеме и принести реальную пользу коллективу и компании в целом.
Где-то где-то
Пётр Второй, постоянно ругаясь, сидит за столом, незаметно слушая в наушниках какую-то тяжёлую музыку и пытаясь понять, «что, черт возьми, происходит внутри этой гребаной помойки!» На одном экране открыт отладчик, на другом — дизассемблированный код. Сосредоточенный взгляд Питера постепенно наполняется безнадежностью, а его левый глаз уже начинает дергаться.Он не замечает, что Ярослав уже минут десять задумчиво молчит за его спиной, пока наконец не похлопывает Петра по плечу.
«А? Что? Что.
» - Петр срывает с головы наушники.
«Ой, Ярослав.
почему ты здесьЭ» «Ну, я тут в свободное время думал о твоей проблеме… кстати, смотри, тебе стоит сюда JNE бросить, иначе дальше не продвинешься».
«Где? Ах, прямо здесь.
и что это даст? Аа, вот и все.
» - Петр снова входит в ручей.
«Что это здесь за чертЭ» «Кривая работа с регистрами.
Давай попробуем вот так.
» - присоединяется к нему Ярослав.
День 10
Рациональное в любое время
«Итак, скорость нашей команды в этом спринте упала на 3 сюжетных пункта.Учитывая, что в итоге мы исключили из спринта функцию SM-134, это вполне ожидаемо.
Кстати, Петр, ты молодец, я не ожидал, что ты успеешь реализовать СМ-135».
— Скрам-мастер как обычно проводил ретроспективу, когда в комнату быстро влетел Ярослав.
«Ребята, я всего на минутку, извините.
Микропринт согласован, мы выделим Вам Ефима на три дня.
Он хороший системный инженер, вместе с Питером вы наверняка успешно решите задачу.
Ну вот и все, я побежал, еще раз извините, что прерываю ваше ретро.
Петр Первый растерянно моргает. Проблема? О да, тот самый, страшный и сложный.
бррр.
Где-то Кто-то
— Питер, в чем твоя проблема? – грозно спрашивает Иван.«Все хорошо, Иван Васильевич.
Остается один небольшой глюк, и тогда код можно будет вылизать.
Я обязательно сделаю это за три дня».
- спокойно отвечает Петр Второй.
— Я знаю твои три дня… — ворчит Иван.
«Давайте побыстрее закончим, мое руководство уже спрашивает, почему мы так сильно откладываем эту функцию.
Скоро нам нужно будет приготовить ведро вазелина!» — Да, я знаю, Иван Васильевич.
Мы тебя втащим!» - Питер улыбается.
День 13
Рациональное в любое время
«По итогам микроспринта с Ефимом выяснилось, что для решения задачи понадобится еще половина спринта.Или даже целый спринт».
- говорит Петр Великий не совсем уверенно.
Вместе с Ефимом они возились над этой проблемой три полных дня, но уверенного решения так и не нашли.
- «Есть несколько подсказок.
» «Наметок, шнаметок!» — взрывается Product Owner, — «Где решение? Ты уверен, что сможешь сделать это за неделю? «Ладно, коллеги, давайте успокоимся».
— вмешивается Scrum Master, укоризненно глядя на Product Owner. «Петр, правильно ли я понимаю, что за половину спринта ты, возможно, не успеешь, но за целый спринт ты обязательно решишь задачуЭ» "Да все верно.
" - отвечает Питер, стараясь говорить уверенно.
— Это все хорошо, конечно.
— говорит Product Owner, немного успокоившись.
«Но готовы ли мы тратить дополнительное время на эту функцию? Мы уже потратили время и силы.
Мне кажется, нам нужно нагнетать обстановку.
Рациональность дополнительных затрат лично мне не кажется очевидной».
«Хорошо, давай сделаем это».
— резюмирует Скрам-мастер.
Кто-то когда-нибудь
«Ну, я почти закончил.Все работает, осталось только причесать подпрограмму».
- сообщает Петр Второй.
«К счастью, я улучшил навыки ребенка в C, но ерунда осталась».
«Ну, молодец».
- Иван улыбается.
«Тебе нужно расчесывать волосы или ты просто очень этого хочешь? Может быть, лучше наконец закрыть эту функциюЭ» «А как насчет моего чувства красотыЭ» - демонстративно обижается Питер, встряхивая руками в воздухе.
Все инженеры дружно смеются.
День 17
Рациональное в любое время
«Руководство пришло к выводу, что возобновление работы над функцией на данный момент нерационально.Business Value недостаточно велик, чтобы вкладывать в него дополнительные ресурсы, а по срокам получается, что мы не успеем к следующему релизу».
— говорит владелец продукта.
"Ну, слава Богу.
" - бормочет себе под нос довольный Петр Великий.
«Можно забыть это, как страшный сон».
Когда-нибудь что-то
«Питер, твоя функция выходит в свет. Вы покрыли это тестамиЭ» – интересуется Иван.«Ну, так.
надо бы еще добавить.
» - колеблется Петр Второй.
"Ну вот." - весомо говорит Иван.
«Все, поехали, поработаем».
Нижняя граница
Опытные разработчики знают, что самые сложные проблемы возникают на стыке технологий и модулей, при интеграции – там, где встречаются две разные системы.При этом обе системы по отдельности могут быть отличными — идеально спроектированными, идеально работающими.
Но на стыке двух прекрасных систем часто возникают самые безобразные противоречия.
Внимательный читатель заметит, что в нашем рассказе задача Anytime Rational возникает на стыке двух идеально работающих систем — продаж и производства.
Итак, в следующий раз вы спросите: «а почему, ну почему здесь не реализовали эту очевидную фичу?Э», или «как, черт возьми, это работает через такую глубокую задницу?Э» — помните, что проблема может быть в текучих абстракциях на стыке двух и более систем.
Хотя, возможно, в конкретном случае, с которым вы столкнулись, это было просто дело рук жадных программистов-реднеков, разрабатывавших какую-то фигню левой пяткой.
Теги: #разработка ПО #бизнес-процессы #scrum #agile #шутка инженеров #Управление разработкой #Управление проектами #agile #Управление продуктом
-
Пожертвования На Разработку Freebsd
19 Oct, 24 -
Карты Bing Интегрируются С Openstreetmap
19 Oct, 24 -
Немного Познавательного
19 Oct, 24 -
Метафоры
19 Oct, 24 -
Паттерны Для Новичков: Mvc Vs Mvp Vs Mvvm
19 Oct, 24
