Одноразовые и одноразовые. Бережливое смещение

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

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

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

Одноразовые вещи требуют дополнительных усилий (что обычно не означает «дополнительное время») на разработку. Однако после внедрения они по определению дистанцируются от конечного продукта. Это возможности. Но в силу того, что они одноразовые, они становятся жертвами ленивого подхода, когда они бросают их при первой же возможности, поскольку их так легко бросить, чтобы продемонстрировать краткосрочную «экономию» в ущерб проекту или всей организации.

Разделение функций и возможностей

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

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

Отделение функции от возможности, то есть развертывание возможности от самой возможности, приводит к разделенной, тестируемой и, в конечном итоге, многократно используемой базе кода. Такое разделение фактически является самым первым шагом проектирования программного артефакта на любом уровне от небольшого класса до большого продукта (см. Также Проектирование без архитектуры). Например, на уровне спринта Scrum это разделение выполняется, когда во время планирования спринта product owner и Scrum совместно формулируют пользовательские истории, с одной стороны, и сопоставляют их с историями реализации, с другой.

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

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

Возможность размещения. Упаковка знаний. Третий вариант использования

Чтобы отделить возможность от ее развертывания, ее нужно где-то разместить. Таким образом, если мы говорим о программном артефакте, как минимум, репозитории кода продукта должны содержать каталоги, посвященные возможностям:

  • Эти каталоги должны быть хорошо структурированы и иметь правильные названия. Это не должна быть одна папка с именем util с плоской связкой из сотен файлов.
  • Не следует смешивать функции с возможностями, которые делают их возможными.
  • Возможности также не должны быть слишком общими. Набор возможностей должен формировать единый мини-язык, на котором можно было бы выразить требуемые функции.
  • Тем не менее, следует сохранить образ мышления о написании отдельной библиотеки, обслуживающей несколько вариантов использования, чтобы избежать переобучения под конкретный случай, чтобы следующий человек не мог понять мотивацию дизайнерских решений. Хотя Agile противостоит чрезмерной и преждевременной документации, может быть действительно полезно подумать о написании документации для артефактов возможностей после их реализации: если трудно объяснить, что они из себя представляют и как их использовать, обычно это означает, что они либо чрезмерно конкретный и переоборудованный, либо плохо обобщенный, так что есть тысяча ручек, которые нужно повернуть, чтобы заставить их работать, что, кстати, демонстрирует, что обе проблемы имеют неаккуратную семантику использования из-за предвзятости реализации как их общей причины. Можно сказать, что после продукта и набора тестов документация является третьим вариантом использования артефакта (второй вариант использования - это набор тестов).
  • Возможности развертываются не только для предоставления функций. Возможности также объединяют знания: они формулируют знания, полученные командой разработчиков, как если бы эти возможности были повторно использованы где-то еще (даже если они ограничены конкретным проектом).

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

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

Кому принадлежат возможности программного обеспечения?

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

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

Книги по Agile настоятельно рекомендуют наличие единственного product owner-а. С другой стороны, они также настоятельно рекомендуют, чтобы в Скрам-команде не было одного человека, отвечающего за команду, а вместо этого они должны были самоорганизовываться. (См., Например, Крейг Ларман, Бас Водде, Практики масштабирования бережливого производства и гибкой разработки.)

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

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

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

Бесполезно совмещать роли мастера Scrum и владельца возможностей. Владелец возможности идентифицирует (в основном внутренних) пользователей кода: самих членов команды, членов других команд или проектов и т. Д .; возможности для синергии и повторного использования; хорошо структурированная упаковка знаний (не только в коде, но и с точки зрения сбора, упаковки и обмена знаниями); и т. д. Во время планирования Scrum она / она следит за тем, чтобы артефакты невыполненной работы не только соответствовали пользовательским историям (аспект развертывания), но и четко разделяли возможности построения и развертывания. Он / она не обязательно должен быть руководителем группы, но должен иметь достаточные полномочия, чтобы настаивать на надлежащем разделении между созданием и развертыванием возможностей, даже если это займет немного больше времени в краткосрочной перспективе и заинтересованные стороны продукта стремятся срезать углы. Он все равно окупится, быстро и щедро.