Conference for DevOps, Software Architects and Engineers. Regular price ends 27/09!
×Закрыть

Software: Bears, Bulls & Swaps

«А давайте напишем систему так, чтобы, когда нам что-то понадобится, оно там уже было»
Один из моих первых работодателей.

Разработка ПО для меня, в первую очередь, — это борьба со сложностью. Со сложностью создания модели прикладного домена, выбора инструментария, построения ортогонального интерфейса, адаптации к новым требованиям, борьба со сложностью поддержки и модификации системы.

И если сложность прикладного домена можно рассматривать как константу или данность, то сложность, порождаемую процессом разработки, можно и нужно контролировать.

Result vs Process

Если обратиться к классике, то целью разработки ПО являет продукт, решающий задачи пользователя, с максимально приемлемыми значениями внешних факторов качества: #correctness, #robustness, #extendibility, #reusability и т.д. [Бертран Мейер. Объектно-ориентированное конструирование программных систем]. Это то, что покупает заказчик.

Перемещаясь по оси результата, разработчики сталкиваются со сложностью домена: рассчитать риски для финансовых инструментов, удалить вырожденные треугольники перед 3D-печатью, выдерживать нагрузку 100К пользователей и т.д.

Но если дополнительно рассмотреть сам процесс разработки, то здесь появляется одна из ключевых особенностей ПО: высокая вариативность. Количество возможных способов достижения результата огромно.

И как следствие, разработка движется уже не просто по прямой результата, а из точки A в точку B, а точнее, в некоторую область, так как с течением времени может меняться не только процесс разработки, но и сама конечная цель. И чем сложнее ваши процессы, тем большее влияние они оказывают на конечный результат.

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

Bears

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

Спецификации, диаграммы, определение интерфейсов, несколько этапов утверждений и только после — реализация в базисе согласованной модели.

Ахиллесова пята данного подхода в том, что пока вы разрабатываете архитектуру, конкуренты уже вышли на рынок с половиной функций, работают с пользователями и получают прибыль.

Bulls

Нарастающие требования к скорости разработки и её объемам привели к необходимости пересмотра самих методов построения ПО.

Гибкие методологии разработки обещали Грааль — фокусировку на результате, постановку во главу угла потребностей пользователя, сокращение цикла разработки, то есть лекарство от всех болезней. Все это происходило на фоне улучшения инструментов: языков программирования, сред разработки, библиотек и пр. Более того, они уменьшали планку входа и стоимость.

Важно понимать, что чаще всего, это возможно за счёт экономии на разработке архитектуры (путём привлечения готовых компонентов), рефакторинге, R&D и уровне разработчиков.

Краеугольной проблемой здесь является то, что частое игнорирование необходимости работ по улучшению внутренней структуры программной системы приводит к постоянному накоплению технического долга и как следствие — к поэтапному смещению в область легаси-продукта.

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

Почему Agile не захватит мир? Потому что велик соблазн закрыть глаза на «прикрутки», недочёты в архитектуре и сказать: «А давайте добавим все это в список задач и вернёмся к нему, когда будет время».

Это время не наступает никогда.

Swaps

«Software eats world» и сейчас сложно определить, что очередная идея программной системы стоит того, чтобы быть принятой в разработку. Очень часто сложность информационной среды не позволяет сказать с уверенностью, что систему вообще можно реализовать в заданные сроки, с заданными функциями и она сможет решить существующие задачи эффективнее. Идея быстро создать работающий прототип, отвечающий на ключевые вопросы, выглядит более чем разумно: это небольшие инвестиции с максимальным результатом.

Подвох здесь в том, что одну и ту же часть работы нужно будет выполнить дважды: сначала в базисе прототипа, а потом как часть продукта и, что более важно, не все тестируемые идеи оправдают затраты.

R&D-отделы компаний работают по этому принципу, понимая что это плата за возможность «пощупать» идею и «нащупать «Next Big Thing».

99% процентов PoC останавливаются в точке E (см. график выше).

Fractals

Описанные выше стратегии — это всего лишь строительные блоки. Каждый проект уникален, более того, оптимальный ход разработки может существенно отличаться в начала и в конце проекта или даже спринта, RUP тому подтверждение.

Разрабатываемая система — это комбинация этапов (задач), для каждого из которых, вы принимаете компромиссное решение в пользу затраченного времени, качества или объема работ.

Singularities

Для каждого из подходов наступает момент, когда необходимо изменить приоритеты и скорректировать движение.

Waterfall — Bear market

Точка С — переломный момент, когда от проектирования необходимо переходить к реализации полезных функций.

Что произойдёт если, позволить разработчикам продолжать двигаться в том же направлении? Проект никогда не будет закончен.

Если у вас бесконечный бюджет, то в обозримом будущем вы достигнете точки B`, с «идеальной» иерархией классов, согласованностью, но с функционалом, который безнадёжно устарел или уже стоит слишком дорого.

Agile — Bull market

Точка D — мечта любого Product Owner-а: бОльшая часть заявленных функций реализована, система не содержит ошибок класса А.

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

Вас никто не осудит, если вы просто дотянете до точки B`. Потом будет работа над новой версией, или даже другой продукт, а может и работа в новой компании.

Swap — Hedging risks

Точка E — момент внутренней демонстрации PoC. На этом этапе должны быть проверены основные гипотезы: интерфейсы разных систем могут быть состыкованы, сервер выдерживает необходимую нагрузку и т.д.

После это момента, код из PoC может быть использован только как демонстрация, но не как базис для дальнейшей разработки. В противном случае, с вероятностью близкой к 1, вы никогда не достигнете точки B.

PoC позволит вам начать разработку с «чистого листа», точки F, с пониманием того, как система должна быть построена. Вы не начинаете с нуля, а как бы из некой условной точки A` в прошлом. Здесь нужно быть аккуратным и не попасться на крючок «эффекта второй системы» — перегрузить архитектуру, базируясь на положительном результате PoC.

Balance

«Выбор всегда заключён между тем, что легко, и тем, что правильно».

Резюмируя сказанное выше:
— смещение в область процесса порождает сложность завершения проекта в срок;
— перекос в сторону результата накапливает сложность технического долга;
— всё это происходит в процессе работы со сложностью прикладной задачи;
— и на фоне постоянного усложнения внешней среды (IT).

Ключ к созданию качественного ПО лежит в плоскости эффективного объединения двух взаимосвязанных векторов процесса и результата и в последовательной корректировке общего вектора движения.

В идеальном случае, для каждой задачи на проекте нужно сопоставить оценку из интервала -N..N. Отрицательное значение — для задач, сфокусированных на процессе, положительное — для задач, ориентированных на результат.

Более реалистичный сценарий состоит в том, чтобы маркировать таким образом только те задачи, которые имеют явные перекосы в сторону процесса (рефакторинг класса) или результата (прикрутка перед демо). Это позволит не только видеть баланс между ними, но и иметь доводы для разрешения споров и коллизий интересов, которые будут базироваться на объективных данных, а не на суждениях и предпочтениях.

Сбор такой статистики позволит выявлять перекосы в ту или иную сторону и принимать взвешенные решения, а поддержание данной метрики в области нуля позволит быть уверенным, что баланс между тактикой и стратегией, процессом и результатом соблюдается.

LinkedIn

72 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хорошая статья. Годится в первую очередь как иллюстрация для заказчиков, которым разбираться в отличиях процессов разработки.

Из-за возрастающей скорости изменений в мире все равно давят на результат. Как минимум это доказывает тот факт, что RUP загнулся и что все топят за SCRUM, который все равно тяжелый как его не облегчай (а SCRUM-мастеров вообще надо выбрасывать из окон). Но любой опытный PM все равно должен владеть всем инструментарием, чтобы уметь двигаться по вашем графику и умело переключаться по вашему графику.

Хорошая статья, спасибо.

Как минимум это доказывает тот факт, что RUP загнулся
Согласен, работать по RUP или Waterfall могут себе позволить только очень небольшое кол-во доменов.
Но любой опытный PM все равно должен владеть всем инструментарием, чтобы уметь двигаться по вашем графику и умело переключаться по вашему графику.
Это можно вынести как сухой остаток.

Ну давай, расскажи какие преимущества Scrum против параллельного Waterfall? Ну и пару нюансов о том, ЧТО СЛУЧАЕТСЯ, когда обнаруживается что Agile вообще пошёл не по тому пути, а собственно ключевые задачи свалили в бездонный technical debt, который по факту оказывается совсем даже не technical.

В общем, гладко было на бумаге. А цикличность процесса проигнорили, у ребят просто не было такой линейки.

«Главное — вовремя уйти». Автор это подтвердил фразой:

Потом будет работа над новой версией, или даже другой продукт, а может и работа в новой компании.

Так и бизнес не вечен. Откладывать неприятности вперед — иногда очень годная стратегия.

Насреддин рассказывает, что как-то раз поспорил с эмиром бухарским, что научит своего ишака богословию так, что ишак будет знать его не хуже самого эмира. На это нужен кошелёк золота и двадцать лет времени. Если он не выполнит условия спора — голова с плеч. Насреддин не боится неминуемой казни: — «Ведь за двадцать лет, — говорит он, — кто-нибудь из нас троих обязательно умрёт — или эмир, или ишак, или я. А тогда поди разбирайся, кто лучше знал богословие!»

Она негодная в тех случаях, когда временной горизонт — не двадцать лет, а год-два, и за это время продукт с 99% вероятностью не умрёт. Стартапы — да, отдельная песня, но беда в том, что откладывание неприятностей наперёд вовсю практикуют в других контекстах, где ожидаемый минимальный shelf life программного продукта заранее более-менее известен.

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

Вот, например в Lean есть концепция Last Responsible Moment. А некоторые исследования так и вовсе говорят, что прокрастинация разгоняет креативность. Так что откладывать — далеко не самая плохая идея, даже со всеми ее несомненными рисками.

Головна проблема не в обраній методології. Головна проблема в мотивації та зарядженості на результат. Якщо цього немає, запороти можна будь що.

Ще кращий спосіб запороти — це надмірно мотивувати, та ще й за «ключовими» показниками. Якщо це є — то краще б взагалі нічого не було з мотивації.

Ну, рабів треба хоч трохи жаліти...

Ти щойно завалив свою кар′єру менеджера.

Ну давай, расскажи какие преимущества Scrum против параллельного Waterfall
преимущество заключается в том, что agile построен на более раннем диагностировании и реагировании на вот это:
когда обнаруживается что Agile вообще пошёл не по тому пути, а собственно ключевые задачи свалили в бездонный technical debt, который по факту оказывается совсем даже не technical.
У ватерфола по ходу преимуществ при прочих равных нету.

Ну да, ну да. А какие мотивы этой ранней диагностике происходить? Agile это НЕ описывает в принципе. Решения есть, не спорю, но они выходят за рамки Agile.

У вотерфолла нет «прочих равных». Его ключевое преимущество — приоретизация задач. То есть практически любую можно останавливать к контрольных точках и ничего при этом не сломается, и никакой ресурс не останется зависшим. То есть по высвобождению ресурса параллельному фотерфоллу нет равных.

С Agile этого не сделаешь. В этом сама суть Agile — концентрировать усилия на одном процессе, максимизировать вовлечение ресурса. Команда быстро высвободить ресурс приведёт к огромным потерям. А команда выдать версию на первое число, выданная первого числа — это неделя похороненной разработки минимум. И мало кто понимает, что так хоронится будущая идея.

Ключевой недостаток вотерфолла — документирование. Именно здесь его название просто таки оправдано — документация по ходу процесса просто таки как снежный ком накапливается. И в какой-то момент её проще выбросить всю, чем что-то в ней пытаться искать. Просто потому что систематизацию её не делают — это внутренняя кухня, там всё меняется быстрее чем эта систематизация пройдёт.

ИТОГО: параллельный вотерфолл — лучше всего подходит к рисковым процессам со многими составляющими риска, включая неопределённость времени, количества исполнителей, объёма ТЗ и даже наличия финансирования. Проект в вотерфолле можно остановить на полгода, и спокойно продолжить дальше, в том числе другой командой. А ещё можно анализировать неудавшиеся проекты или их части, и легко принимать решение о воскрешении — то есть оценить объём риска и ожидаемую выгоду.

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

Налицо путаница. Попробуем разобраться. Для простоты в качестве agile возьмем классический Скрам.

Ну да, ну да. А какие мотивы этой ранней диагностике происходить? Agile это НЕ описывает в принципе. Решения есть, не спорю, но они выходят за рамки Agile.

Мотивы — stakeholder satisfaction. Решения находятся как раз в рамках большинства методологий. Скажем львиная доля того же Скрама — это управление беклогом, задача Product Owner.


У вотерфолла нет «прочих равных». Его ключевое преимущество — приоретизация задач.

Приоритезация задач есть везде. Слабость ватерфола в том, что он хуже поддерживает переприоритезацию, которая необходима вследствие изменчивости как внешних так и внутренних факторов.

То есть практически любую можно останавливать к контрольных точках и ничего при этом не сломается, и никакой ресурс не останется зависшим. То есть по высвобождению ресурса параллельному фотерфоллу нет равных.

Ресурс-то может и «не зависнет», а вот задача — да. Зависшие задачи имеют свойство быстро протухать. С этим пытаются бороться богато приправляя промежуточной документацией, но борьба эта идет с переменным успехом и обычно недешева.

С другой стороны в ажильном Скраме контрольная точка — это конец спринта. В этот момент задачи прошедшие DoD не нуждаются в доработке, остальные считаются неготовыми и в принципе могут потребовать вплоть до полного rework from scratch. Кажущиеся потери компенсируются постоянным акцентом на уменьшении размеров этих задач и повышением эффективности обратной связи.

Озабоченность «провисанием» ресурсов сама по себе является классическим признаком неграмотного проджект менеджмента. Еще в 3й четверти прошлого века было убедительно показано что оптимизация flow намного важнее полной утилизации ресурсов, а последняя зачастую оказывается вредна. Наглядно расписано для нашей индустрии у Поппендиков


С Agile этого не сделаешь. В этом сама суть Agile — концентрировать усилия на одном процессе, максимизировать вовлечение ресурса. Команда быстро высвободить ресурс приведёт к огромным потерям. А команда выдать версию на первое число, выданная первого числа — это неделя похороненной разработки минимум. И мало кто понимает, что так хоронится будущая идея.

Это не имеет абсолютно никакого отношения ни к Agile в целом ни к его методологиям.

Ключевой недостаток вотерфолла — документирование.

В принципе документирование не является обязательным отличием ватерфола от agile методологий. Ватерфол можно делать с минимум документации, скажем если участники фаз colocated. Так же контекст может требовать внесения большого количества промежуточной документации в DoD самого что ни на есть гибкого в других терминах процесса.

Более того, при уменьшении размера задачи и прохождении ей всех фаз ватерфола за короткий период (2±1 недели) тот же ватерфол очень легко замаскировать скажем Интерпрайзным Скрамом.

Другой вопрос тенденции, и избыточное документирование является характерным симптомом показывающим уязвимость вотерфола к меняющимся приоритетам, критически уязвимую размазанность задач во времени.


ИТОГО: параллельный вотерфолл — лучше всего подходит к рисковым процессам со многими составляющими риска, включая неопределённость времени, количества исполнителей, объёма ТЗ и даже наличия финансирования.

Скорее очевидно обратное.

Если убрать воду, остаётся только «очевидно».

Документирование линейных процессов ЯВЛЯЕТСЯ обязательным в вотерфолле. В этом его суть — никакой следующий этап не запустят, пока не будет создана ДОКУМЕНТИРОВАННАЯ связь с предыдущим.
Выгода вотерфолла именно в том, что задачи здесь «протухают» куда дольше. И практически все стабильные процессы существования (не первичной разработки) именно на нём построены. Просто в силу, как ты выразился, «избыточной» документации, его можно оставить с нулевой подпиткой на неопределённый период времени.

Попробуй-как подать команду hibernate в скрам-процесс — да ты его через месяц собрать не сможешь сколь-либо приемлемыми силами, и без зависших там навсегда проблем. С вотерфоллом иначе:
— что говорите, денег нет, только после праздников? Нет проблем. И команда переключается в другой проект в течение часа без каких-либо усилий со стороны руководства. Лишь у некоторых он задержится до конца дня.

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

А я не то же самое сказал? Agile не есть плохо. Плохо есть Скрам, особенно когда урезанный и «покращеный». Должны быть ещё алгоритмы, притом с приоритетом ВЫШЕ скрамных процедур и ритуалов.

Скрам лучше всего работает там, где нужно быстро и с максимальным использованием условно безлимитного ресурса добиться максимально возможного количественного результата. Иными словами, решить боевую задачу в боевой обстановке.

Хуже всего скрам пашет там, где нужно минимизировать саму обстановку. То есть перевести проект в такое состояние, когда его жизнедеятельность будет потреблять минимум ресурсов, минимизировать риски, и вывести чёткую картину его слабых мест.

Иными словами, когда делается проект, нацеленный на прорыв, на масштабирование — от скрама лучше держаться подальше. А вот когда делается клонирование результата, притом не всего проекта, а только его части — скрам самое оно!

+ Нужно знать о проблеме перегрева. Скрам способен накалять обстановку и повышать энтропию. Бороться с этим можно, но очень дорого для процесса. Лучшее средство предотвращения, как ни странно — это ИНВЕРСИЯ УПРАВЛЕНИЯ. Когда руководство лидера составляет не более 10% от всех управленческих решений. Иными словами, когда рост энтропии не приводит к негативным последствиям в силу нарушения правила Парето: те 80% которые не влияют на результат СЕЙЧАС — вытесняются из текущего приоритета. А те что вытеснены быть не могут — значит таки влияют, пусть и через несколько звеньев.

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

Что я хочу этим сказать: не стоит всецело полагаться на методологии. Нужно знать прототипы, на которых они работают, уметь запускать и контролировать базовые процессы. Тогда и методологии будут работать — за счёт ВЫПИЛИВАНИЯ сломавшихся или бракованных частей механизма.

Главный из этих процессов — умение видеть глупость в лицо. То есть называть глупость — глупостью, а не новым веянием.

Вернемся к началу. Это теперь хоть понятно:

ЧТО СЛУЧАЕТСЯ, когда обнаруживается что Agile вообще пошёл не по тому пути, а собственно ключевые задачи свалили в бездонный technical debt, который по факту оказывается совсем даже не technical.
?
И команда переключается в другой проект в течение часа без каких-либо усилий со стороны руководства.

А что, проблема вхождения в контекст уже давно решена? Или утверждаете, что документация спасает от этого? :)

Вхождение в контекст — это не проблема, а просто издержка по времени. От частых переключений понятно что никто не выиграет. Но вот как раз СОХРАНЕНИЕ контекста, и ВХОЖДЕНИЕ в него — являются преимуществами вотерфолла.

Впрочем, не буду обманывать — вотерфолл тоже должен иметь обратную связь. Накопление ошибок — вот его ахиллесова пята.

Ну да, ну да. А какие мотивы этой ранней диагностике происходить? Agile это НЕ описывает в принципе. Решения есть, не спорю, но они выходят за рамки Agile.

Так никакая методика не устраняет необходимости думать.
Разве что где-то сказано «а других источников быть не может» — ну тогда вываливать в перьях именно автора этой фразы, а не самых общих принципов.

Его ключевое преимущество — приоретизация задач.

Приоритизация, извините.

параллельный вотерфолл

Такой термин не гуглится ни в каком описании. Это Ваше личное изобретение, командное, или откуда? В любом случае, прошу расшифровать.

То есть практически любую можно останавливать к контрольных точках и ничего при этом не сломается, и никакой ресурс не останется зависшим. То есть по высвобождению ресурса параллельному фотерфоллу нет равных.

Это тоже требует пояснения.

Критика, мне кажется, не по адресу. Статья подходит больше не для зубров, а для новичков для освоения принципов и устранения начальных перекосов в понятиях, и для заказчиков, которым надо понять основные тенденции.

Ну давай, расскажи какие преимущества Scrum против параллельного Waterfall?

А где-то превозносится Scrum?

А цикличность процесса проигнорили, у ребят просто не было такой линейки.

Её лучше вынести в следующую главу (статью), после понимания того, что изложено здесь.

Всі фрази зрозумілі. А от про що стаття в цілому — хз ) Яка в автора головна думка — неясно.

Доу собираются прокачать до уровня Хабра .. )) Кстати интересно как бы написал статью Юра ...

Кстати интересно как бы написал статью Юра

Как-то так?
dou.ua/...les/behind-methodologies

О, другое дело! Старый ламповый стиль Юры Паламарчука, классика. Не то что современники. Надеюсь в скором будущем редакция доу сможет предложить $5К/мес и Юра вернется ...

Яка в автора головна думка — неясно.
Как с помощью дополнительной метрии стремиться к созданию своевременного, качественного и «долгоживущего» ПО.

Эт точно. Как при помощи очередной членомерки оправдать затраты на очередного членомера.

а как на счет XP?:) Это же Agile framework, но он скорее process over product (согласно поданой выше классификации). Кто запрещает выделять изначально буфер в каждом спринте под архитектурные фичи и рефакторинг, чтобы не накапливать тех.долг к концу релиза как на графиках выше?

Какой XP, какой RUP? Нынче такая дурная мода пошла, что говорим «Agile» — подразумеваем «Scrum [+ Kanban]».

просто утомляет, что половина «комментаторов» которые кричат «Agile/Scrum/Kanban/.../etc — x###!@#» - сами зачастую не понимают смысла этих понятий и разницу между ними, а лишь где-то попали в кривой Scrumbut принудительно и теперь всюду на все издали похожее — фукают... А ведь там не процесс кривой, а его криво внедрили скорее всего. Как отверткой гвозди забивать и говорить, что отвертка — фигня!

да бывает даже agile’ом называют отсутсвие процесса, а потом ещё себе в резюме пишут «agile». насчет «комментаторов» тут все ешё хуже, некоторые спорят по аналогии что лучше молоток или отвертка (вот тупо вообще независимо от решаемой задачи). ну может и нормальная/образовательная дискусия для джуниоров, но пишут же люди с н-лет опыта, это ж вообще клиника. восхищаюсь терпением людей, которые пытаются таким что-то объяснить

Я специально не специализировал на графике, что же такое точки 1 и 2.
Это может быть весь проект или, как В Вашем примере, граница одного спринта.
Суть не поменяется, главное в конце интервала стараться полностью возвращать накопленный технический долг.

принято, спасибо за пояснение)

Цікава точка зору

Як, коли і як часто пропонуєте ставити та переглядати такі оцінки для тікетів?

Как я упоминал, слишком накладно, требовать от разработчиков делать такую оценку для каждой задачи «руками».

Як
Это может быть дополнительное поле для задачи в Jira.
коли
Можно делать при создании задачи, можно во время её закрытия. Главное чтобы подобные задачи были обязательно промаркированы.
як часто
Для каждой задачи, которая имеет явные признаки «перекоса» в ту или иную сторону.

Ну, за такого підходу жодна задача не буде позначена, крім тієї, в яку PM-ам дожмуть розробники, і яку PM ткне розробникам явно. Відповідно, користь для передбачень і управління буде нульова.

Якщо є інший досвід — цікаво дізнатись як :)

в яку PM-ам дожмуть розробники, і яку PM ткне розробникам явно
В таком случае любая методика не будет работать ), из-под палки в ИТ мало что работает
...
Один из моментов, который я хочу донести в данной статье: выиграть можно только принимая во внимания обе составляеющие процесса разработки.
...
Приняв спорное решение перед демо, ПМ должен выделить временной бюджет для возвращения технического долга.
Потратив ощутимое время на проектирование, Tech lead должен форсировать разработку полезного для заказчика функционала.
...
In My Simple World )
из-под палки в ИТ мало что работает...

«Само по собі» в IT працює ще менше.

Ок ) «Добрым словом и пистолетом вы можете добиться гораздо большего, чем одним только добрым словом».
...
Предположим, Вы на законодельном уровне объявили проактивную борьбу с техническим долгом.
1. Необходимо создать дополнительное поле в вашем менеджере задач (TechnicalDebt)
2. В процессе очередного планирования:
* команда решает добавить в спринт, задачу явно прикруточную, чтобы пройти демо, выкатить обновление и пр: захаркодить IP адрес, список языков, игнорировать временную зону и т.д. Такая задача создаётся со значением поля TechnicalDebt = 1. Тут же, необходимо создать задачу, которая должна будет компенсировать данное решение. Она так же заносится в трекер со значением TechnicalDebt = −1
* разработчики убедили команду что нужно отрефакторить какую-то часть кода, внедрить новый фрейворк, переписать несколько методов: создаём задачи с TechnicalDebt = −1. Но тут же выясняем как это сможет ускорить разработку и создаёт для этого будущие задачи с TechnicalDebt = 1. Например если мы внедрим enterprise service bus, то на интеграцию с социальными сетями мы будем тратить на порядок меньше времени: создаём задачу подключить 20 сервисов через oauth2 за 2 дня (facebook, twitter, linkedin, uber, ...)
...
Что можно ожидать. Здесь влияние такое же как и при внедрении юнит-тестирования: чем больше кода покрыто тестами, тем меньше комитов, ломающих сборки, тем меньше тратится времени на локализацию и правку ошибок. В данном случае технический долго не будет накапливаться и разговоры от том, чтобы переписат всё с нуля, будут звучать значительно реже, как и желание пускать проект на самотек.
...
PM — будет понимать, что за любую прикрутку нужно будеть расплачиваться и должен будет держать в фокусе критичные для заказчика аспекты и не дотягивать до конца спринта и\или релиза с их решением.
Любое предожение в духе: давайте перепишем этот говно-код, должно будет обосновано, конкретным списком фич, которые буду улучшены в разрезе полезного функционала приложения\сервиса.

ИМХО сравнили теплое и мягкое :(

«Структурированный» ватерфол и «рыгала, ср№?а, мазала» эджайл, уж простите меня за лаконичность :)

Можно попожробнее пояснить значение осей на графиках, особенно Process
В чем их можно измерять? Result — в story points ?
А Process в чем?

Процес — то обслуговування розробки. Сюди входить і підготовча робота, як то розробка архітектури, вивчення матчастини, аналіз первинних данних тощо, так і всі наступні етапи: написання документації, аналіз роботи системи, інтеграційні процеси тощо.

Результат — написання коду, досягнення певних практичних цілей, створення суті продукту.

Це моє розуміння даних сутностей в статті.

Спасибо Олександр, Вы услышали то, что я хотел сказать.

Немного добавлю от себя.
Здесь Результат более абстрактное понятие чем даже story points.
Я бы измерял его в Epic/Story — в том, что действительно важно заказчику: залогиниться, скачать файл, построить график и т.д.

Подвох здесь в том, что одну и ту же часть работы нужно будет выполнить дважды: сначала в базисе прототипа, а потом как часть продукта и, что более важно, не все тестируемые идеи оправдают затраты.
WAT? o_O
А хто заважає реалізовувати прототип прямо в рамках продукту? А хто заважає використовувати `dummy data` (`mocks`) для того, щоб не просто зробити прототип, а ще й майже повнофункціональний прототип?

Согласен, что между PoC и MVP достаточно тонкая грань.
...

o_OА хто заважає реалізовувати прототип прямо в рамках продукту?
Потому что, вероятность того, что данная идея будет принята в разработку очень низка. Я не случайно упомянул R&D/Incubator команды, для которых создание PoC основная задача.
...
А хто заважає використовувати `dummy data` (`mocks`) для того, щоб не просто зробити прототип, а ще й майже повнофункціональний прототип?
Никто. Чем больше ресурсов вы выделяете для реализации внутренней структуры продукта, тем больше вы смещаетесь в область MVP и полноценной разработки продукта.
...
Для PoC я просто забью в код exit(file_get_contents($fname))
Для MVP скорее всего я подключу какую-нибудь mocks/fakes библиотеку.
Вопрос тольков в том что “time-to-market” для первого варианты выше, за счёт экономии на дизайне и внутренней структуре продукта.
...
Здесь нет чёткой границы между черным и белым.
Потому что, вероятность того, что данная идея будет принята в разработку очень низка.
Та ладно! В мене більше 95% ідей проходять кастінг та попадають одразу в фінальний продукт. Тому що ідея в мойому розумінні — це результат аналізу та кропіткої інтелектуальної роботи. Це такий самий готовий продукт, як і реалізація в коді. Насправді вміння досягати непоганого результату з першого разу — це теж результат постійного поліпшення процесу створення прототипу. Тому ота кривуляка, що намальована в статті, мусить бути трохи іншою: спочатку мусить йти AC, потім свапатися на AE, потім повертатися назад на AC через деякий час. Тобто процес мусить йти перед реалізацією.
Для PoC я просто забью в код exit(file_get_contents($fname))
За таке треба відривати руки одразу. Це не буде PoC, бо концепт порушено. Ви таким чином будуєте інший процес, який не співпадає із тим, що вимагається. Отже, time-to-market тут тільки збільшується.
Ви таким чином будуєте інший процес, який не співпадає із тим, що вимагається.

Когда делают такое, то “вимагається” только одно — как можно быстрее и дешевле выпустить на рынок продукт приемлемого качества (при этом, речь идёт о качестве продукта исключительно как “черного ящика”). Для бизнеса, в самом начале реакция рынка и traction важны в сотни раз больше — так как нет смысла расширять и поддерживать продукт, который окажется нахрен не нужным рынку.

Соответственно, структурное качество, поддерживаемость, расширяемость — на данном этапе никого не интересуют; технический долг накапливается тоннами, и написанное на этапе PoC / MVP зачастую проще выбросить нахрен и переписать заново по-человечески.

Скоріш за все ви не бачили в своєму житті нормального PDD (prototype driven development). Нічого ніхто не викидає, окрім того доволі швидко фічі з’являються в продакшині та приносять прибуток.
Про економіку проекта. Краще не чіпляти тему, бо можемо довго ще товкти воду в макогоні.

Про економіку проекта. Краще не чіпляти тему, бо можемо довго ще товкти воду в макогоні.

А жаль, потому что именно в экономике всё и дело. Если бюджет и сроки позволяют нанять команду исключительно из strong middle / senior разработчиков, то вариант

Нічого ніхто не викидає, окрім того доволі швидко фічі з’являються в продакшині та приносять прибуток.

вполне реален хотя бы потому, что ребята такого уровня уже приучены писать приличный поддерживаемый код “на автомате” — соответственно, потребности что-то выкидывать не возникает изначально, и уже написанный код вполне поддается рефакторингу и дальнейшим модификациям.

При более скромном бюджете с большой вероятностью получим мешанину из god class’ов по 10000 строк с кучей ненужных связей между ними. Имея в базисе подобный г...код big ball of mud, долго работать в режиме

доволі швидко фічі з’являються в продакшині та приносять прибуток.

просто не получится (хотя, видел проект-исключение, где подобную дохлую лошадь пинали лет 10).

Головна причина виникнення лайнокоду — вибір інструментів перед вибором методології розробки (не плутати із скрамом або водоспадом). І тут немає різниці, джун буде писати, чи профі.
Наприклад, команда вирішує писати Single Page Application. Що зазвичай роблять в першу чергу? Правильно, довго й галасно обговорювати, який фреймворк краще взяти: Ангуляр чи Реакт. А їх аудиторія — користувачі із слабкими компами. А ще одне обмеження — великі об’єми даних, якими мусить оперувати користувач. І тут краще взагалі відмовитися від рендерінгу на клієнті, зробити його на серверній стороні та передавати на клієнт вже готові шматочки HTML. Тепер запитання, чи буде приносити користь в даному випадку Ангуляр чи Реакт? Не впевнений.
Чи суттєво змінится архітектура проекта та процес розробки? Так, дуже сильно.

То, о чем вы говорите, тоже имеет место быть. Скажу даже больше — у самого есть печальный опыт, когда излишне доверился архитектору, увлекшемуся впихиванием event sourcing и NoSQL куда надо и, что гораздо печальнее, куда не надо.

Вместе с тем, не соглашусь с тем, что вышесказанное —

Головна причина виникнення лайнокоду

Т.к. лайнокод — это НЕ о неверном выборе технологий, а об отсутствии так называемого структурного качества, то есть — высокая связность, высокая цикломатическая сложность, грубые нарушения принципов SOLID, несоблюдение стандартов кодирования и т.п.

То ви про лапшакод кажете, але навіть профі, які вміють писати високоякісний код, все одно в решті решт пишуть лайнокод :) Тому що спочатку мусить бути методологія, потім інструменти.

навіть профі, які вміють писати високоякісний код, все одно в решті решт пишуть лайнокод

Ну вот эту посылку неплохо бы аргументировать. Профи в условиях спешки может писать неидеальный код, но вот лайнокод он писать уже не умеет на уровне рефлексов.

Та легко. Ви можете бути профі в Angular чи React, мати величезний досвід за плечима, можете із закритими очима писати код, можете навіть побудувати ідеальну (з вашої точки зору) внутрішню архітектуру, але якщо стане обмеження, наприклад, не більше 200КБ на весь код проекту (включаючи стилі та картинки), то тут ви просто сядете в калюжу. Ви напишете саме лайнокод, хоча і вельми красивий, бо він не буде вирішувати поставлену задачу. :)

За таке треба відривати руки одразу.

Стаття саме про це. «Серйозні» розробники будуть сперечатися і обсмоктувати на code review кожен рядок тривіального кода, а конкуренти вже почнуть заробляти гроші.

Виграє не той, хто більше фіч за певний проміжок часу нагенерує, а той, хто краще вирішує проблеми кінцевого споживача.

Знов за рибу гроші! Погане, але працююче рішення — це для споживача значно краще, ніж відсутність працюючого рішення.

Із власного досвіда. Планомірне вбиття наших конкурентів сталося лише тому, що ми почали краще вирішувати проблему споживача. В конкурентів, коли ми тільки починали, були значно кращі та, що саме головне, робочі та існуючі рішення. Але наше, нехай навіть кострубате та напівробоче, надавало зовсім інший рівень послуг. Через деякий час ми почали вигравати по всіх фронтах, а ще через деякий час назавжди змінили місцевий ринок. Так само зробив Гугл.

Та ладно! В мене більше 95% ідей проходять кастінг та попадають одразу в фінальний продукт.
Возможно дело в том, что Ваши идеи не имеют ничего общего с прототипами. Прототипы делают тогда, когда нужно проверить предположение или гипотизу на практике. Если Вы имеете
результат аналізу та кропіткої інтелектуальної роботи
, то возможно Вы просто реализуете свою идею
в фінальний продукт
, вот и все. Если 95% Ваший идей проходят, то проверять концепцию просто не выгодно, выгоднее просто реализовывать все идеи в продукт и убирать/выключать из него не взлетевшие (что мне кажется Вы по сути и делаете). А вот прототипы и PoC делают как раз тогда, когда нет 95% вероятности того, что концепт верен, и стоимость ошибки больше, чем затраты на проверку концепта.

Тут вже жонглювання термінами. Хто що вкладає в значення слів. Для мене прототип — це майже полнофункціональна модель чогось.

Тут я перескочил с термина PoC на Прототип, изначально разговор был про PoC, цель которого — получить ответы на вопросы/доказать правильность наших предположений, и который не имеет ничего общего с полнофункциональной моделью чего-либо.

между PoC и MVP достаточно тонкая грань

С моей колокольни, PoC — это прототип, создаваемый с целью снизить технические риски — способность держать нагрузку, интеграции с внешними системами и т.п. Как правило, PoC по своей природе являются throw-away prototype.

С MVP все интереснее, так как его дальнейшая судьба зависит от объема технического долга, накопленного к моменту выпуска в свет первой версии. Который, в свою очередь, во многом зависит от ограничений по бюджету и срокам.

Грубо говоря, если заказчик дал команду слепить за две недели из г...на и палок, да еще и в бюджет вписывается только команда из джуниоров, то код MVP проще выбросить и переписать.

А если изначально была возможность откровенно не г...нокодить и заложить хотя бы фундамент правильной архитектуры — такой MVP может, в дальнейшем, развиваться эволюционно без больших перерасходов между точками E и F.

Спасибо, моё ощущение границ между PoC и MVP аналогичное.
Если обощить, то чем больше мы уделяем времени архитектуре, тем больше мы смещаемся вправо
PoC -> MVP -> Agile -> Waterfall.

Согласен во всём, кроме участка

Agile -> Waterfall

Я бы, в принципе, рассматривал waterfall — если мы понимаем под этим словом именно кондовый водопад со строго последовательными фазами — как некий вырожденный случай, работающий исключительно на мелких проектах наподобие запуска инфо-сайтов путем прикручивания и допиливания темы к какой-нибудь CMS.

К сожалению, очень часто даже опытные менеджеры в IT называют «водопадом» процесс, по сути отличающийся от классического agile только большим объёмом предварительного планирования и более формальной документацией. Ни RUP, ни тот же MSF for CMMI, когда-то пропагандируемый Microsoft — это ни разу не водопад в классическом смысле этого слова.

Поэтому, скорее, в правой части вашего спектра я бы написал Agility at Scale: в эту категорию попадают как старый добрый RUP, так и более новомодные Disciplined Agile Delivery / SAFe

Очень хороший обзор можно найти здесь: Tactical Agility at Scale

Согласен во всём, кроме участка
Да, здесь классическая ловушка использования устоявшихся терминов.
Я старался использовать термины «Agile» и «Waterfall», для обозначения ситуаций, когда есть перекос или в сторону процесса или результата.
Если в PoC и MVP более или менее понятно, то схема выше должна была выглядеть так
PoC -> MVP -> «Agile» -> «Waterfall»
...
Я бы, в принципе, рассматривал waterfall — если мы понимаем под этим словом именно кондовый водопад со строго последовательными фазами — как некий вырожденный случай, работающий исключительно на мелких проектах наподобие запуска инфо-сайтов путем прикручивания и допиливания темы к какой-нибудь CMS.
Вот тут не соглашусь, по причине участия в разработке авиа симулятора для Antonov AN-148.
Waterfall был единственно возможным подходом, по причине вовлечённости большого количества подрядчиков. Да, после утверждения интерфейсов, каждый из подрядчиков мог изменить процесс разработки. Но с уровня конечного продукта — водопад был единстенно приемлимым решением.
Так что строго последовательные фазы применяются и на больших проектах.

Я бы просто убрал MVP из этой цепочки, это скорее ортогональное понятие. MVP (Minimum viable product) указывает на количество функционала в продукте (продукт с минимальным набором функционала), а не на его качество или процессы, по которым он разрабатывался. Точно так же как и полная версия продукта MVP может разрабатываться с упором на скорость выпуска, на качество решения или же на их баланс. Само понятие MVP не говорит, что это должно быть быстрее за счет качества, оно говорит «мы выйдем на рынок раньше за счет минимального количества функционала».

Само понятие MVP не говорит, что это должно быть быстрее за счет качества

Кроме шуток, я бы это распечатал и повесил в рамочке на каждом этаже в офисе.

PoC — для девелоперов, показать, что выбранный подход работает, а MVP — как продукт для презентации PM и тд.

Подписаться на комментарии