13.4 Функциональные и нефункциональные требования
Интегрированные невыполненные работы
Одно из преимуществ гибкой разработки программного обеспечения заключается в способности команды сосредоточиться на нескольких важных вещах на каждой итерации. Производительность страдает в любой команде, независимо от того, является ли она гибкой или нет, когда неясны приоритеты или когда элементы внедряются в рабочий поток из незапланированных источников. Частая смена задач и отсутствие эффективного способа расстановки приоритетов отрицательно сказываются на эффективном рабочем времени.
В главе 5 представлены основы определения приоритетов стратегических рабочих процессов. Конечно, необходимо учитывать и другие рабочие процессы, отнимающие время у групп доставки.
Команды приносят больше пользы, когда у них есть хорошо расставленный по приоритетам объем незавершенной работы, из которого они могут браться по мере готовности. Но что вы делаете со всей этой работой, основанной на прерываниях, которая занимает большую часть времени любой группы доставки после того, как их продукт был выпущен для клиентов? Как насчет небольших идей по улучшению и дефектов, которые приходят от пользователей после релиза? Этот тип работы известен под многими названиями — слом/исправление, техническое обслуживание, исправление ошибок, исправления и другие. Как правило, эта работа возлагается на команду разработчиков, потому что они являются очевидным выбором для изменения собственного кода. Конечно, это правильное предположение, но команда не планировала эту работу, и ее выполнение ставит под угрозу их существующие обязательства по новым стратегическим функциям. В альтернативном случае эти небольшие, но незапланированные изменения могут быть обработаны командой технического обслуживания.
Эта проблема расстановки приоритетов преследует каждую команду, пытающуюся поставлять программное обеспечение. Ситуация становится еще хуже, если учесть технический долг, который накапливается во время разработки и обслуживания продукта. Совокупный эффект замедляет работу команды и усложняет разработку. В конце концов, это достигает взаимосвязи, когда команда вынуждена разбираться с грехами своего прошлого. Технический долг потребляет их мощности и снижает, по крайней мере временно,ценность, которую они предоставляют своим клиентам. Эти клиенты недовольны тем, что они не получат много новых функций в следующем выпуске.
Как насчет всех этих изящных новых идей? Небольшие ценные изменения, на реализацию которых не требуется много времени, кажется, что имеет смысл просто «вставить их» в следующий релиз. Конечно, это также влияет на запланированный график работы. Все эти виды работ важны и должны решаться, но без типичного непредсказуемого влияния на запланированную работу.
В название этого раздела намеренно включено слово «незавершенные работы», а не «незавершенная работа» в единственном числе. «С» имеет значение. У каждой группы доставки будет отставание для своих инициатив. По пари может быть две инициативы, каждая из которых закреплена за отдельной командой, так что у каждой команды будет свой бэклог. На следующем уровне у каждой голевой команды будет запас приоритетных ставок. Однако в этой главе основное внимание будет уделено бэклогу инициатив, используемому командами доставки.
Компоненты невыполненной работы
На рис. 7-1 показаны компоненты невыполненной работы — стратегический, дефекты, технический долг, небольшие улучшения и технические возможности. Каждый из этих компонентов требует времени и должен быть расставлен по приоритетам. Три будут считаться частью BAU (внутри пунктирной линии). В этом разделе описывается каждый из этих компонентов, а в следующем разделе более подробно рассматривается их приоритетность.
BAU может охватывать ряд типов работ и временных обязательств. Хотя для классификации этой работы используется ряд терминов, в этой главе используются три термина: небольшие улучшения, дефекты и технический долг. Они показаны на рис. 7-2 вместе со стратегической работой, чтобы обеспечить общее представление о рабочей нагрузке команды.
Небольшие улучшения
Во многих организациях есть «команды обслуживания», которые заботятся об унаследованных системах. Эти команды обрабатывают небольшие запросы на усовершенствование от различных пользователей.представителей. Такие небольшие усовершенствования обычно вызваны желанием сделать вещи лучше, быстрее или дешевле.Часто существуют правила управления, чтобы удерживать эти небольшие изменения в определенных пределах. Максимальные лимиты инвестиций, обычно выражаемые в количестве человеко-часов, необходимых для выполнения работы, являются типичными, которые мы видим у наших клиентов.
Эти элементы обслуживания рассматриваются как «быстрый путь» к выполнению задач, потому что они редко требуют преодоления препятствий анализа затрат и результатов для крупных проектов. К сожалению, такими запросами также часто злоупотребляют и приводят к инвестициям в работу, которая была отклонена инвестиционным комитетом (или была бы отклонена, если бы она была тщательно изучена). Положительным моментом является то, что небольшие усовершенствования представляют собой способ остановить все утечки инвестиций и, по крайней мере, сдержать их в пределах бюджета, которым можно управлять. Некоторые организации неплохо умеют использовать руководство по продуктам и пользовательские комитеты, чтобы расставлять приоритеты в этой работе и разумно тратить деньги. Другие, не очень.
Дефекты
Сложные проблемы, как правило, приводят к сложным решениям, которые не всегда реализуются идеально. В программном обеспечении ошибки разработки (иногда называемые «ошибками», чтобы они звучали менее угрожающе) часто допускаются и должны быть исправлены. Мы видели организации со значительными проблемами качества программного обеспечения, которые тратят 50 процентов своего бюджета на устранение дефектов. Даже самая лучшая организация, тратящая менее 5% на ремонт дефектов, все равно нуждается в способе управления работой. Управление инцидентами и проблемами выходит за рамки этой книги, но все организации, независимо от размера их инвестиций в устранение дефектов, должны иметь эффективные и действенные процессы управления инцидентами и проблемами. 11 . Хорошую отправную точку по управлению инцидентами и проблемами см. в The Stationery Office, ed. Руководство для практикующих ITIL . Норидж, Коннектикут: Канцелярия, 2016.
Самая сложная часть работ по устранению дефектов заключается в том, что большая их часть является незапланированной. Хотя обычно работа, необходимая для выполнения ремонта, минимальна, это не всегда так. Когда происходят инциденты, обслуживание должно быть восстановлено быстро. В большинстве организаций инциденты с большим влиянием имеют приоритет и перевешивают всю остальную работу до тех пор, пока не будут устранены. Это действительно мешает расстановке приоритетов и управлению портфелем.
Технический долг
Как определено в главе 2 , Tech@Core, технический долг определяется как деградация технологии с течением времени из-за отсутствия инвестиций в поддержание адаптивности и качества. 2 Технический долг приводит к уменьшению времени цикла от выпуска к выпуску и даже от итерации к итерации. Она накапливается со временем — сначала медленно, а затем все быстрее и быстрее по мере того, как вы отказываетесь от качества в пользу «одноразовой» скорости. Как и в случае с финансовым долгом, допущение невыплаты технического долга означает накопление значительного штрафа в виде снижения адаптивности и стабильности.2 . У Уорда Каннингема есть короткое видео, объясняющее его размышления о введении термина «технический долг»: Каннингем, Уорд. Метафора долга . https://www.youtube.com/watch?v=pqeJFYwnkjE.Accessed21 января 2019 г. .
Наилучшая практика будет поощрять «управление» техническим долгом, чтобы штраф никогда не оказал существенного негативного влияния на бизнес. Следовательно, вам необходимо включить этот тип работы в процесс управления портфелем BAU вместе с другими типами работы BAU.
Объединение стратегического портфеля и портфеля BAU
Как упоминалось ранее, большинство организаций тратят более 80 процентов своих возможностей на работу BAU. Многие портфолио работ никогда не будут включать какую-либо стратегическую работу. Наш портфель дебиторской задолженности является хорошим примером: стратегическая инициатива редко меняет фундаментальные бизнес-возможности AR. Для ясности давайте представим, что ваши коллеги-новаторы выступили со стратегической инициативой, требующей внесения изменений в AR. Вы обычнохотят, чтобы стратегические инициативы были отделены от элементов BAU, но иногда можно управлять более мелкими стратегическими элементами в портфеле BAU. Когда это происходит, как вы справляетесь с этой работой? В каком портфеле он принадлежит?Один из хорошо работающих подходов к объединению стратегических портфелей и портфелей BAU — это концепция зарезервированных мощностей. В нашем примере портфеля AR BAU, если есть вероятность какой-то стратегической работы, вы можете зарезервировать часть денег (мощности), вложенных в бюджет AR, для стратегической работы, как показано на рисунке 7-3.. Этот подход поддерживает согласованный бюджет операционных расходов, но допускает небольшой объем потенциальной стратегической работы. Эти средства можно использовать только для небольших стратегических инициатив в портфеле AR BAU. Резервную мощность следует учитывать при установлении целей для MoS портфеля AR BAU. Если стратегическая работа не требуется, ожидается, что команда будет использовать эту способность для создания ценности с помощью BAU. Более крупные стратегические инициативы должны обрабатываться в портфеле LVT и расставляться по приоритетам с использованием процесса, описанного в главе 5 .
