tbd что значит в проектах
Почему Trunk Based Development – лучшая модель ветвления. Андрей Александров
В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.
Всем привет! Меня зовут Андрей. Я DevOps-консультант. Работаю в Express 42, по совместительству ведущий подкаста DevOps Deflope. И сегодня я рассказу про Trunk Based Development.
Это штука очень сложная. Я не уверен, что у меня получится за 10 минут объяснить все концепции, идеи, которые за ней стоят.
Почему эта модель лучше? Я не буду рассуждать на тему: лучше она или нет, потому что пруфы в индустрии уже есть:
Я буду сосредотачиваться только на том, почему и зачем это нужно.
Мы хотим тестировать бизнес-гипотезы как можно быстрее. Мы хотим выдвинуть идею, протестировать, отдать пользователям. И Trunk Based Development идеально для этого подходит.
В чем суть Trunk Based Development?
Поговорим про все эти штуки. Почему они хороши?
Все начинается с Feature Flags. Все следующие шаги без этой штуки сделать не получится.
В чем идея Feature Flags? В том, что мы теперь с помощью ключика можем сказать, какие фичи мы включаем, а какие нет. Большая часть фич оборачивается в Feature Flags. И когда мы запускаем наше приложение, мы говорим, что теперь наши пользователи могут за один клик покупать. И таким образом мы можем делать A/B тесты и мержить в мастер те фичи, которые еще не готовы.
Что дает нам включение-выключение фич?
Когда я раньше писал код за деньги, у меня была большая боль. В чем была проблема? У меня есть большой pull request. Я в нем сделал кучу абстракций, полей в базе данных и прочее. И они уже нужны в других фичах. Но мы не можем это переиспользовать, потому что у меня еще не все готово. И мы не можем это смержить. А Trunk позволяет все это делать, потому что у нас Feature Flags как обязательный подход.
Вот это самая сложная вещь. Тут очень многие люди совершают ошибку. У нас больше нет веток для фич. Это сложная концепция.
В чем идея? Мы больше не делаем ветки для фич, мы делаем ветки на изменение одной абстракции.
Например, у нас есть машинка, в ней есть абстракция «передние колеса» и «задние колеса». И мы хотим, чтобы эти колеса работали как-то по-другому. Например, чтобы был другой тип колес, шин.
Как в случае с Trunk будем их менять?
Мы задачу по замене колес, которая большая и сложная с кучей рефакторинга, декомпозировали на маленькие кусочки. И pull requests делаем на изменение одной маленькой абстракции. Вот это ключевая идея. И это то, за счет чего Trunk получается очень быстрым.
Что дает нам такой подход?
Соответственно, мы теперь работаем маленькими кусочками, меняем одну абстракцию за раз и это нам позволяет использовать подход Continuous Review.
Это все очень-очень сложно. Я пытался уже несколько раз рассказывать про Trunk. И каждый раз у людей складывалось впечатление, что это как Git Flow или GitHub Flow, но только проще, потому что нет пару лишних веток, поэтому Trunk Based Development очень простой. Нет, эта штука очень сложная.
И, поверьте, это не так просто. По моему опыту общения с программистами далеко не у всех все хорошо с применением SOLID‑практик. Если ваши программисты разбираются в SOLID, то, скорее всего, эта абстракция у них есть и так. Потому что SOLID нам говорит: «Делай объект, а вокруг него делай еще интерфейс-абстракцию». Если у программиста с этим проблемы, то не взлетит, надо будет все это подтягивать.
Почему, несмотря на все эти сложности, мы приходим к тому, что она лучшая?
Тут парочка полезных ссылочек:
Приветствую! Допустим, у нас есть команда, у которой нет вообще никаких процессов, т. е. даже Git Flow нет. Теоретически мы можем пропустить итерацию выстраивания Git Flow и прочих процессов, а сразу прыгнуть в Trunk Based? И насколько это реально?
Теоретически можно. Trunk Based Development очень сильно вариативный. Если сейчас не получается прыгнуть сразу в Branch By Abstraction, то можно сделать Short-Lived Branches. Это как фичи-ветки, только они живут очень мало. Один-два дня – максимальное время жизни ветки от создания. Можно зайти с этого. Можно сделать короткоживущие ветки, а потом сверху все остальное. Можно попробовать так.
Ты сказал, что для принятия pull request его должно посмотреть достаточное количество глаз. Обычно при разработке у нас есть TeamLead, который просматривает все поступающее и принимает единоличное решение о включении или не включении в текущий Branch. Каким образом вы организовываете pull request, что у вас несколько человек смотрят и принимают решение? У вас голосование?
Можно делать по-разному. Можно, чтобы просто любой коллега посмотрел. Делать так, что все pull requests смотрит TeamLead – это плохая идея, потому что их теперь у тебя очень много, они очень частые и он становится бутылочным горлышком.
Т. е. не несколько человек смотрят все-таки?
Это как принято в компании. Может смотреть несколько, может один человек. Но хоть кто-то должен посмотреть, иначе у тебя не будет никаких плюшек от review, т. е. нет шаринга, нет моментального рефакторинга и т. д.
Привет! Спасибо большое за доклад! Какого размера примерно проект должен быть? Это должен быть маленький проект, микросервисы или это идеология натягивается на любой размер проекта?
Абсолютно на любой. У тебя по большому счету претензия к архитектуре в этом случае. Если ты монолит сделал по условному SOLID, у тебя все абстракции нормально разделены, то у тебя никаких проблем не будет. Ты за счет этого подхода, даже если изначально он был сделан плохо, можешь его кусочками-кусочками медленно рефакторить. И при этом своим рефакторингом абсолютно не блокируешь коллег.
Накрывается ли тестами работа Feature Flags? И насколько большой overhead для разработки, для тестирования вот это покрытие вызывает?
Мы должны тестировать и вариант, когда фича включена и вариант, когда она выключена, иначе мы не понимаем ломаем ли мы prod или нет.
А насколько overhead? Тут не очень понятно, как мерить.
Т. е. два раза нужно написать тест? Нужно написать для старой фичи, нужно написать для новой фичи?
Нет, тест для старой фичи у тебя не пишется, потому что ты его уже писал.
Он уже есть, да. А для новой нужно написать. И внутри написать включилось и не включилось.
Да, ты внутри теста старой абстракции пишешь «if включена новая фича», тогда вот эти тесты новые. Also – старые. И прогоняешь и то, и то. Я не вижу тут какого-то overhead, кроме добавления строчки if, потому что старые тесты у тебя есть, новые ты добавляешь.
Спасибо за доклад! У нас большой проект. У нас Trunk Based Development уже год.
Все отлично, все работает. Только у нас SVN. И поэтому мы просто коммитим прямо в Trunk. И у нас нет pull request, мы коммитим прямо в Trunk. Все здорово и хорошо. Спасибо автотестам. Но пришли новые люди и начали ныть: «Давайте нам Git Flow, ваш Trunk Based – это какой-то ужас». И мы прогнулись, и решили переехать на Git. И сейчас у нас пол проекта в SVN, полпроекта в Git. Скоро весь проект будет в Git. И мне страшно. Мне Trunk Based Development нравится. И мне страшно от него отказываться. Если переехать с такого вида, когда мы коммитим прямо в Trunk, на такое, мы не замедлимся? Т. е. если Short-Lived Branches не по фичам, а Branch By Abstraction, то это не замедлит нас?
У тебя один коммит в мастер – это целая фича?
Нет, у меня один коммит в мастер – это просто кто-то что-то написал и коммитит.
Я понял. Branch By Abstraction, только Commit By Abstraction фактически?
Если вы все-таки начинаете друг друга ревьювить, то это плюс две минуты на ревью кого-то.
Мы в Trunk смотрим и если что-то там плохо, то правим.
Тогда не должно быть никаких проблем. Если мы посмотрим тот же trunkbaseddevelopment.com, то он говорит, что если вы очень крутые, то можете прямо в мастер фигачить. Но вы должны быть очень крутыми, чтобы так делать. видимо, вы крутые.
Привет! Спасибо за доклад! Я хотел по этой картинке спросить (Branch By Abstraction вместо feature branch). Ты говоришь, что над любой фичей должна быть абстракция. Почему тогда не остановится на 4-ом варианте? Если в следующий раз нужно будет что-то поменять, то нужно будет эту абстракцию дополнительно пилить как в первом шаге.
Есть два варианта. Есть вариант, когда мы эту абстракцию оставляем и есть вариант, когда мы ее убираем. Все делают по-разному. Если мы посмотрим, например, на блог Fowler, то он говорит, что эту штуку давайте оставим, пусть у нас для всего будет abstraction layer или layer интерфейса. Это пример с Trunk Based Development, они объясняют эту штуку так. Но можно оставлять, можно убирать – это не принципиально. Но я бы рекомендовал все-таки оставить. Т. е. мы удалили старый вариант, но оставили новый тип колес и абстракцию, через которую мы все еще можем с этим что-то делать.
И еще вопрос у меня по Code Review. Очевидно, когда приходит junior-разработчик в команду, то его Code Review вряд ли будет занимать 10 минут и PR вряд ли будет висеть час. Это может быть и дольше, и может быть отклонено. Что будет в таких случаях? Или ты не берешь вообще juniors в команду?
Можно раскрыть вопрос?
Когда junior берется за дело, то ему требуется больше комментариев по коду и т. д. И, возможно, какие-то исправления необходимо вносить в pull request. А ты говоришь, что pull request висит 10 минут, т. е. он не успеет за 10 минут, скорее всего, поправить. Что делать?
У тебя junior будет исключением. 10 минут – это еще приемлемый результат. Если больше часа, то мы считаем это плохим результатом. Понятно, что Junior будет сложно. Скорее всего, он еще не те абстракции менял или не оттуда зашел. Для него придется сделать исключение.
Можно картинку с машинкой? Вот здесь все вроде бы понятно и хорошо. Мы меняем только колеса. А что если это будет не машинка, а здоровенный космолет из 50 150 частей, которые одновременно изменяются? Ладно, давайте вернемся к этой машинке. У нас несколько команд одновременно изменяет кто-то поведение фар, кто-то поведение стекла, колеса. В итоге выглядит более логичным, чтобы вместо красного корпуса была одна здоровенная абстракция, либо мы ее тоже будем менять. Не приводит ли это к тому, что у тебя начинается какая-то безумная простыня из Feature Flags, когда не понятно, как эти изменения должны друг с другом взаимодействовать? Потому что измененное стекло пусть даже с абстракцией не будет взаимодействовать через корпус с новыми колесами и ее абстракциями. Я уже сам запутался, пока объяснял.
Я понял. Основной вопрос в том, что будет, если мы параллельно меняем кучу всего.
Да, когда проект большой и изменений много в один момент времени.
Проблем не будет и вот почему. У тебя тут абстракция интерфейсная, которая позволяет колеса менять. Тут абстракция, позволяющая фары менять. Тут абстракция, позволяющая менять стекла. Почему это не будет сложно? Потому что у тебя в каждый момент времени все разработчики знают, что меняется. У тебя разработчик шлет сюда pull request на изменение фары, но он работает с максимально актуальным кодом, потому что мы мержимся каждые несколько минут. Поэтому он видит, что еще делают его коллеги. И, возможно, они объединятся и сделают какой-то единый вариант абстракции или еще что-то. У тебя, когда кто-то будет слать сюда pull request, он будет видеть, что другие коллеги уже тоже что-то делают.
Я вспомнил, что хотел сделать опрос. Поднимите руку, кто до этого момента слышал про Trunk. Неплохо, почти треть. А кто использует его у себя в проектах? 4 человека.
Что такое Trunk Based Development (TBD)?
Перевод статьи «What is Trunk Based Development? A Different Approach to the Software Development Lifecycle».
Жизненный цикл разработки ПО (англ. Software Development Lifecycle, SDLC) в каждой компании свой.
Используемая система контроля версий, процедура код-ревью, осуществление непрерывной интеграции, автоматизированное и ручное тестирование и т. п. вещи будут очень сильно зависеть от того, где вы работаете.
То, как компания планирует, пишет, собирает, проверяет, деплоит и выпускает программы, подогнано под ее собственные нужды с учетом всех достоинств и недостатков выбранных подходов.
Я начал читать о том, какие есть жизненные циклы разработки ПО в разных технологических компаниях, и несколько раз наткнулся на термин Trunk Based Development. Это процедура, которой придерживается Google, и мне стало любопытно, чем она отличается от процедур, принятых в большинстве других компаний, занимающихся разработкой.
Два разных подхода к ветвлению
Ответвления для отдельных функций
Когда несколько разработчиков вместе работают над одной кодовой базой, они могут делать это двумя способами.
Первый подразумевает создание отдельных веток для всех создаваемых фич.
Чаще всего разработчики работают с системой контроля версий Git. Каждый из них делает форк кодовой базы на свою машину (в результате у всех есть идентичные копии всего кода). Затем все делают ответвления от основной ветки master и создают ветки фич или проектов, над которыми будут работать. Закончив работу над своей фичей, каждый разработчик сливает свои изменения обратно в master. Тут надо подчеркнуть, что merge делается только один раз, когда работа над фичей окончена, и в master мержится вся ветка этой фичи.
Вот схема того, как происходит работа с ветками:
Белые точки представляют коммиты, а непрерывная черная линия внизу это master. Разработчики делают ответвления от master, вносят изменения в свои ветки, а когда все готово и код прошел проверку, каждая отдельная ветка сливается обратно в master.
Trunk Based Development (TBD)
Второй подход к совместной работе над кодовой базой — TBD. При этом подходе все разработчики делят свою работу на маленькие порции и мержат свои изменения прямо в master по нескольку раз в день. Ветку master при этом часто называют trunk — англ. «ствол», по аналогии с деревом.
Разработчики не создают отдельных веток для своих фич и, естественно, не мержат их затем в «ствол». Вместо этого они делают коммиты напрямую в «ствол», обходясь вообще без веток.
TBD подразумевает, что изменения каждого отдельного разработчика не задерживаются вне главной ветки дольше, чем на несколько часов. Они постоянно мержатся и интегрируются с кодом, написанным другими разработчиками.
Джез Хамбл, Site Reliability Engineer в Google и автор книги «Continuous Delivery», сказал: «ветвление — не проблема, проблема — слияние». Именно эту проблему и призван решить подход TBD.
Цель TBD — избежать болезненного мержа, а он часто бывает болезненным, если в trunk мержатся долгоживущие ветки, которые уже слишком сильно отличаются от ствола. И если разные разработчики (или даже разные команды) сливают несколько веток в одну, прежде чем слить ее в trunk, — merge тоже редко бывает беспроблемным.
Насколько подход TBD применим в больших проектах?
Рейчел Потвин, Engineering Manager в Google, рассказала об одной кодовой базе. В январе 2015 года в этой базе было:
При работе над этой кодовой базой они применяли TBD, и для их нужд этот подход отлично работал. Поскольку в Google работает много талантливых (и, что более важно, — опытных) инженеров, они редко ломают свои сборки.
Также в Google существует очень строгая процедура тестирования (почитать о ней можно здесь). При применении TBD эта процедура тестирования делает возможной быструю и эффективную поставку ПО.
TBD также хорошо сочетается с Agile-методологиями, предполагающими частые поставки для быстрого получения фидбэка от пользователей или клиентов. С TBD вы можете непрерывно интегрировать изменения и получать хорошие снимки текущего состояния кодовой базы.
Давайте коротко обсудим преимущества TBD.
Преимущества TBD
Недостатки TBD
Как релизить программы, применяя TBD
У команды, которая придерживается TBD, процедура релиза будет отличаться от аналогичной процедуры в команде, где используются ветки фич.
Допустим, вы работаете с ветвлением. Когда вы мержите что-то (тикеты, завершенные проекты и т. п.) в master, вы делаете релиз этой основной ветки. В некоторых командах релиз master происходит по расписанию, скажем, раз в неделю.
А вот как обстоят дела с релизами в TBD-командах:
В TBD ответвления используются исключительно для релизов.
Вы делаете «снимок» вашей кодовой базы в ее стабильном состоянии, готовом к деплойменту и релизу.
В приведенной выше схеме могут появиться дополнительные детали, только если с релизом prj-123 что-то пойдет не так. Тогда мы коммитим результат в trunk и выбираем (cherry pick) коммиты в нашу ветку релиза, чтобы как можно быстрее привести ее в рабочее состояние.
В некоторых командах, если релизы у них происходят регулярно, вообще обходятся без ответвлений и, когда необходимо, делают релиз trunk.
Заключение
Теории и практике TBD посвящен отдельный сайт, там вы можете узнать гораздо больше.
Надеюсь, прочитав эту статью, вы поняли, что такое Trunk Based Development и зачем нужен этот подход. Он определенно помогает избавиться от многих проблем, связанных со слиянием долгоживущих веток.
Словарь терминов (глоссарий) по разработке требований (Вигерс, 2013)
CRUD matrix — таблица, связывающая действия системы с элементами данных, чтобы показать, где каждый элемент создается (Created), читается (Read), обновляется (Updated) и удаляется (Deleted). Planguage — основанный на ключевых словах язык, предложенный Томом Гилбом (Tom Gilb) и позволяющий создать точную и количественно оцениваемую спецификацию требований.
Swimlane-диаграмма
diagram — модель анализа, показывающая последовательные шаги потока бизнес-процессов предлагаемой программной системы. Процесс разбивается на визуальные компоненты, называемые дорожками, которые показывают системы или действующие лица, выполняющие эти шаги.
TBD — сокращение от To Be Determined. Служит для отметки неясностей или пропусков, которые надо заполнить, в информации требований.
UML (Unified Modeling Language) — набор стандартной нотации для создания различных визуальных моделей систем, особенно в объектно-ориентированном программировании.
Альтернативное направление
alternative flow — направление, учитывающее вариант использования, которое ведет к успеху (достижение цели действующего объекта), но которое подразумевает отклонение от нормального направления в специфике задач или при взаимодействии объекта с системой.
Анализ первопричин
root cause analysis — действия, которые предпринимаются для поиска основных причин, вызывающих наблюдаемые проблемы.
Анализ расхождение
gap analysis — сравнение текущего состояния и альтернативного или возможного состояния системы, процесса или другого аспекта бизнес-ситуации для выявления значительных расхождений между ними.
Анализ требований
requirements analysis — процесс классификации информации, касающейся требований, по различным категориям, оценка требований для определения желаемого качества, представление требований в различных формах, выделение детальных требований из требований более высокого уровня, обсуждение приоритетов требований и т. д.
Архитектура
architecture — структура системы, включающая все ПО, оборудование и людей, из которых она состоит, интерфейсы и взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам.
Атрибут качества
quality attribute — вид нефункционального требования, описывающего характеристику сервиса или производительности продукта. Примеры атрибутов качества: удобство и простота использования, легкость перемещения, легкость в эксплуатации, целостность, надежность, эффективность и устойчивость к сбоям. В требованиях описаны рамки атрибутов качества, до которых продукт демонстрирует желаемые характеристики.
Атрибут требования
requirement attribute — описательная информация о требованиях, которая дополняет описание желаемой функциональности продукта. К ней относятся источники данных, логические обоснования, приоритеты, ответственные лица, номера версий и выпусков.
Бизнес-аналитик
business analyst — роль члена команды по разработке требований, основная обязанность которой — работа с заинтересованными лицами над выявлением, анализом, определением, утверждением и управлением требованиями в проекте. Эта роль также может называться аналитик требований, системный аналитик, разработчик требований и просто аналитик.
Бизнес-правило
business rule — политика, предписание, стандарт, правило или вычислительная формула, определяющая или ограничивающая некоторые стороны бизнес-процессов.
Бизнес-требования
business requirement — объем информации, который в совокупности описывает потребность, которая инициирует один или больше проектов, призванных предоставить решение и получить требуемый конечный бизнес-результат. Бизнес-требования включают бизнес-возможности, бизнес-цели, метрики успеха, концепция и границы и ограничения.
Бизнес-цель
business objective — финансовая или нефинансовая выгода, которую организация ожидает получить в результате реализации проекта или другой инициативы.
Блок-схема
flowchart — модель, которая показывает этапы процесса и точки принятия решений в логике процесса или программы. Аналогична диаграмме взаимодействия.
Большие данные
big data — обычно описывают массив данных, отличительные особенности которых — большой объем (много данных), высокая скорость (данные быстро поступают в организацию) и/или высокая сложность (данные очень разнородны). Управление большими данными предусматривает обнаружение, сбор, хранение и обработку больших объемов данных быстро и эффективно.
Бумажный прототип
paper prototype — непрограммная модель пользовательского интерфейса ПО с недорогими, несложными в исполнении эскизами экрана.
Вариант использования
use case — описание набора логически связанных возможных взаимодействий действующего лица и системы, которые дают результат, ценный для действующего лица. Может включать много сценариев.
Взаимосвязь «расширить»
extend relationship — конструкция, в которой альтернативное направление ответвляется от нормального направления в отдельный «расширенный» вариант использования.
Владелец продукта
product owner — роль, обычно в команде проекта гибкой разработки, представляющая клиента и отвечающая за определение концепции продукта, предоставление границ и ограничений проекта, определение приоритетов запаса продукта и принятие решений по продукту.
Внешняя сущность
external entity — объект в контекстной диаграмме или диаграмма потока данных, представляющая класс пользователей, действующее лицо, программную или аппаратную систему и являющийся внешним к описываемой системе, но так или иначе взаимодействует с ней. Также называется оконечным устройством.
Водопадный жизненный цикл проекта
waterfall development life cycle — модель процесса разработки ПО, в которой различные действия с требованиями, дизайном, кодированием, тестированием и развертыванием выполняются последовательно, с небольшим наложением или итерациями.
Встроенная система
embedded system — система, содержащая аппаратные компоненты, управляемые ПО, работающем на выделенном компьютере, являющемся частью более крупного продукта.
Выходное условие
postcondition — условие, описывающее состояние системы после успешного завершения варианта использования.
Выявление требований
requirements elicitation — процесс определения требований из различных источников посредством интервью, семинаров, анализа задач, рабочих потоков и документов и других механизмов.
Гибкая разработка
agile development — методы разработки ПО, характеризующиеся постоянным взаимодействием между разработчиками и клиентами. К методам гибкой разработки относятся экстремальное программирование (Extreme Programming), Scrum, разработка, управляемая функциональностью (Feature Driven Development), бережливая разработка программного обеспечения (Lean Software Development) и Kanban.
Граница проекта
scope — часть концепции конечного продукта, реализуемой в ходе текущего проекта. Определяет границу между тем, что входит и что не входит в проект, в котором создается определенный выпуск или итерация.
Действующее лицо
actor — лицо, играющее конкретную роль, программная система или аппаратное устройство, которое взаимодействует с системой для достижения полезных целей. Также называется ролью пользователя.
Дерево решений
decision tree — модель анализа, которая графически показывает действия системы в ответ на все комбинации набора факторов, которые влияют на поведение части системы.
Дерево функций
feature tree — модель анализа, отображающая функции, запланированные для продукта, в виде иерархического дерева и отображающая до двух уровней подчиненных функций в каждой функции.
Дефект требования
requirement issue — проблема, открытый вопрос или решение относительно требования. Это могут быть элементы, помеченные как «TBD» (to be determined — необходимо определить), отложенные решения, необходимая информация, неразрешенные конфликты и т.п.
Диаграмма (или машина) состояний
state machine diagram — модель анализа, показывающая представления различных состояний, которые могут принимать объекты системы на протяжении своего жизненного цикла в ответ на то или иное событие или отображающая возможные состояния системы в целом. Похожа на диаграмму перехода состояний.
Диаграмма «сущность–связь»
entity-relationship diagram — модель анализа, которая показывает логические взаимосвязи между парами объектов. Используется для моделирования данных.
Диаграмма вариантов использования
use case diagram — модель анализа с указанием действующих лиц, которые могут взаимодействовать с системой для выполнения задач, и различные варианты использования, в которых может участвовать действующее лицо.
Диаграмма взаимодействия
activity diagram — аналитическая модель, которая позволяет динамически представить систему, посредством изображения потока процессов от одной функции к другой. Схожа с блок-схемой.
Диаграмма классов
class diagram — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи.
Диаграмма перехода состояний
state-transition diagram — модель анализа, показывающая возможные состояния системы или объектов в ней, разрешенные переходы между ними и условия и/или события, инициирующие каждый переход. Аналогична диаграмме или машине состояний.
Диаграмма потока данных
data flow diagram — модель анализа, описывающая процесс, хранилища данных, внешние сущности и потоки, характеризующие поведение данных, проходящих через бизнес-процессы или программные системы.
Документ о концепции и границах
vision and scope document — документ, в котором определены бизнес-требования к новой системе, в том числе положения о концепции продукта и описания границы проекта.
Документы процесса
process assets — документы, такие как шаблоны, формы, списки, политики, процедуры, описание процессов и примеры рабочих продуктов, которые собраны для эффективного применения в организации с целью улучшить приемы разработки ПО.
Допущение
assumption — положение, которое считается верным в отсутствие доказательств или точных знаний.
Зависимость
dependency — зависимость проекта от внешних факторов, событий или групп, находящихся вне зоны контроля.
Заинтересованное лицо
stakeholder — это человек, группа или организация, которая активно задействована в проекте, подвержена влиянию процесса или результата или может влиять на процесс или результат.
Исключение
exception — условие, которое может помешать успешному завершению варианта использования. Если некоторые возвратные механизмы не работают, то выходные условия варианта использования не достигаются и желаемая цель не достигается.
Итерация
iteration — непрерывный период разработки, обычно от одного до четырех недель, во время которого команда разработки реализует определенный набор функциональности, выбранной из резерва продукта, или базовой версии требований к продукту.
Каркас
wireframe — разновидность одноразового прототипа, который используется для предварительного дизайна веб-страниц.
Карта диалоговых окон
dialog map — модель анализа, описывающая архитектуру пользовательского интерфейса, показывая видимые диалоговые элементы и навигацию между ними.
Карта экосистемы
ecosystem map — аналитическая модель, которая показывает набор классов системы или определенной предметной области, их интерфейсы и взаимосвязи. В отличие от контекстных диаграмм, карта экосистемы показывает системы, имеющие отношения друг с другом, даже если между ними нет интерфейса.
Класс пользователей
user class — группа пользователей системы, имеющих схожие требования к системе. Члены пользовательского класса функционируют как действующие лица при взаимодействии с системой.
Класс
class — описание набора объектов, имеющих общие свойства и поведение, которые стандартным образом соотносятся с элементами реального мира (людьми, местами или вещами) в бизнесе или определенной предметной области.
Клиент
customer — человек или организация, получающая от продукта прямую или косвенную выгоду. Клиенты это заинтересованные в проекте лица, запрашивающие, оплачивающие, выбирающие, определяющие, использующие и получающие результаты работы программного продукта.
Количество элементов
cardinality — количество элементов данных объектов или данных, которые связаны с элементами других объектов или данных. Например, «один к одному», «один ко многим» или «многие ко многим».
Контекстная диаграмма
context diagram — аналитическая модель, которая описывает абстрактную систему высокого уровня. Контекстная диаграмма определяет внешние для системы объекты, которые взаимодействуют с ней, но не отображает ничего из внутренней структуры или поведения системы.
Концепция
vision — утверждение, описывающее стратегический принцип конечной цели и формы новой системы.
Критерий приемлемости
acceptance criteria — условия, которым продукт должен удовлетворять, чтобы его приняли пользователи, клиенты или другие заинтересованные лица.
Матрица отслеживания связей требований
requirements traceability matrix — таблица, отображающая логические связи между функциональными требованиями и другими системными артефактами, в том числе функциональными требованиями, пользовательскими требованиями, бизнес-требованиями, элементами архитектуры и дизайна, модулями кода, тестами и бизнес-правилами.
Модель
mock-up — частичная или возможная реализация пользовательского интерфейса для систем ПО. Применяется для оценки легкости и простоты использования, а также завершенности и корректности требований. Может представлять собой программу или прототип на бумаге. Также называется горизонтальным прототипом.
Модель бизнес-целей
business objectives model — визуальное представление иерархии бизнес-задач и бизнес-целей.
Нефункциональное требование
nonfunctional requirement — описание присущих свойств или характеристик, которые система ПО должна демонстрировать, или ограничения, которые она должна соблюдать.
Нормальное направление
normal course — последовательность действий, заданная по умолчанию в варианте использования, которая ведет к удовлетворению выходных условий этого варианта использования или достижению целей пользователей. Другие названия: нормальное направления развития, базовый поток, нормальная последовательность, основной успешный сценарий и счастливый путь (happy path).
Ограничение
constraint — налагается на доступные разработчику возможности дизайна или конструирования продукта. Другие типы ограничений могут ограничить возможности, доступные для менеджеров проектов. Бизнес-правила часто накладывают ограничения на бизнес-операции, а значит, на программные системы.
Одноразовый прототип
throwaway prototype — прототип, который создается с расчетом, что после его использования для уточнения и утверждения требований и вариантов дизайна он будет выброшен.
Оперативный профиль
operational profile — комплект сценариев, который представляет ожидаемые случаи применения ПО.
Организатор мероприятия
facilitator — лицо, ответственное за планирование и работу группы, например работу семинара по выявлению требований.
Основная версия требований
requirements baseline — зафиксированный в определенный момент времени, согласованный, просмотренный и одобренный набор требований, обычно определяющих определенный выпуск продукта или итерацию разработки. Служит основой для дальнейшей разработки.
Отношение включения
include relationship — конструкция, в которой несколько шагов, повторяющихся во многих вариантах использования, выделяются в отдельный вложенный вариант использования, который вызывается по мере необходимости.
Отслеживание
tracing — процесс определения логических связей между одним элементом системы (вариантом использования, функциональными требованиями, бизнес-правилами, компонентами дизайна, фрагментами кода, тестами и т. д.) и другим.
Панель мониторинга
dashboard — изображение на экране или в печатном документе с множественными текстовыми и/или графическими представлениями данных, предоставляющее консолидированное многомерное представление происходящего в организации или процессе.
Пилотная версия
pilot — контролируемое выполнение нового решения (такого как процесс, инструмент, программная система или учебный курс) для оценки его работы в реальных условиях и готовности к развертыванию.
Повторное использование требований
requirements reuse — использование существующих требований во многих системах, отличающихся одинаковой функциональностью.
Пользователь
user — клиент, который взаимодействует с системой непосредственно или косвенно (например, пользуется результатами работы системы, хотя не генерирует эти результаты). Также называется конечным пользователем.
Пользовательская история
user story — способ выражения пользовательских требований в проектах гибкой разработки в форме одного или двух предложений, формулирующих потребность пользователя или описывающих единицу необходимой функциональности, а также говорящих о пользе, какую эта функциональность приносит пользователю.
Пользовательское требование
user requirement — цель и задача, которую пользователи должны иметь возможность выполнять с системой, или положения об ожиданиях пользователей о качестве системы. Пользовательские требования обычно представляются в виде вариантов использования, пользовательских историй и сценариев.
Поток процесса
process flow — последовательные шаги бизнес-процесса или операций предложенной программной системы. Обычно предоставляется с применением диаграммы взаимодействия, блок-схемы, swimlane-диаграммы или другой нотации моделирования.
Правило решения
decision rule — согласованный способ выработки единого решения в группе людей.
Предварительные условия
precondition — условия, которые должны быть удовлетворены, или состояние, в котором система должна пребывать, чтобы мог начаться вариант использования.
Приемочный тест
acceptance test — тест для проверки ожидаемых вариантов использования с целью определения приемлемости ПО. Используется в проектах гибкой разработки для представления подробностей пользовательских историй и определения правильности их реализации.
Приоритизация, определение приоритетов, расстановка приоритетов
prioritization — акт определения того, какие требования программного продукта наиболее важны для достижения бизнес-успеха и в каком порядке должны реализовываться требования.
Проверка
verification — процесс оценки рабочего продукта, позволяющий определить, удовлетворяет ли он спецификации, на основе которой создан. Обычно формулируется в виде вопроса: «Правильно ли мы создаем продукт?»
Продукт
product — конечный результат разработки, выполняемой в рамках проекта. В этой книге используются также термины-синонимы «приложение», «система» и «решение».
Проект с чистого листа
green-field project — проект, в котором разрабатывается новое ПО или новая система.
Прототип
prototype — частичная, предварительная или возможная реализация программы. Применяется для исследования и утверждения требований, а также для разработки приемов. Прототипы бывают эволюционные, одноразовые, бумажные, горизонтальные и вертикальные.
Процедура
procedure — пошаговое описание направления действия для выполнения и завершения конкретной работы.
Процесс
process — последовательность действий, выполняемых для достижения конкретной цели. Описание процесса представляет собой документированное определение этих действий.
Процесс создания требований, процесс построения требований
requirements engineering — область, которая охватывает все стороны жизненного цикла проекта, связанные с необходимыми возможностями и атрибутами продукта. Состоит из разработки требований и управления требованиями. Считается подобластью процессов построения системы и ПО.
Рабочий продукт
work product — любой промежуточный или окончательный результат, созданный в проекте разработки ПО.
Разработка требований
requirements development — процесс определения границ проекта, классов и представителей пользователей, выявления, анализа, спецификации и утверждения требований. Результатом этого процесса считается основная версия требований, в которой указано, что за продукт должен быть построен.
Расползание границ проекта
scope creep — условия, при которых границы проекта неконтролируемо расширяются на протяжении всего процесса.
Распределение требований, назначение требований
requirements allocation — процесс распределения системных требований по различным архитектурным и компонентным подсистемам.
Резерв продукта
product backlog — в проекте гибкой разработки, распределенные по приоритетам список еще не реализованных задач проекта. Резерв может содержать пользовательские истории, бизнес-процессы, запросы на изменение и разработку инфраструктуры. Рабочие элементы из резерва назначаются на будущие итерации на основе их приоритетов.
Ретроспектива
retrospective — рецензирование, в котором участники анализируют действия и результаты проекта с целью определения путей повышения успешности последующих проектов.
Рецензирование
peer review — действия, предпринимаемые одной или несколькими лицами (не авторами продукта), для исследования продукта с целью обнаружить возможные дефекты и улучшить возможности.
Решение
solution — все компоненты, которые должны быть созданы в процессе реализации проекта для достижения бизнес-целей, определенных организацией, в том числе ПО, оборудование, бизнес-процессы, руководство пользователя и обучение.
Риск
risk — условие, которое может привести к потере или иным образом поставить под угрозу успех проекта.
Серийные продукты, коммерческие готовые продукты
COTS (commercial offtheshelf) product — готовый пакет ПО, приобретаемый у поставщика. Применяется как готовое решение или интегрируется, настраивается и расширяется в соответствии с потребностями клиента для удовлетворения нужд последнего.
Система
system — продукт, содержащий много программных или аппаратных подсистем. В общеупотребимом смысле используется в этой книге в отношении приложения, продукта и решения для обозначения любого содержащего ПО результата, создаваемого командой.
Система бизнес-аналитики
business analytics system — программная система, служащая для преобразования больших и сложных наборов данных в осмысленную информацию, на основе которой можно принимать решения.
Система реального времени
real-time system — аппаратная или программная система, которая должна реагировать в четко определенное время на заданные события.
Системное требование
system requirement — требование верхнего уровня к продукту, состоящему из многих подсистем, которые могут представлять собой ПО или совокупность ПО и оборудования
Словарь данных
data dictionary — набор определений элементов данных, структуры и атрибутов, относящихся к определенной предметной области.
Событие
event — инициирующее или стимулирующее событие, которое происходит в системной среде, например поведение функции или изменение состояния.
Совет по управлению изменениями
change control board — группа сотрудников, отвечающая за решение о принятии или отклонении предлагаемых изменений в требованиях к ПО.
Спецификация требований к продукту
software requirements specification — набор функциональных и нефункциональных требований к продукту ПО.
Сторонник продукта
product champion — назначенный представитель отдельного класса пользователей, который предоставляет пользовательские требования представляемых им групп пользователей.
Сущность
entity — элемент области бизнеса, данные о котором собираются и сохраняются.
Схема требования
requirement pattern — систематический подход к определению определенного типа требований.
Сценарий
scenario — описание взаимодействия пользователя и системы с целью достижения некоторой цели. Пример работы с системой. Один из путей развития варианта использования.
Таблица «событие–реакция»
event-response table — перечень внешних или зависящих от времени событий, которые могут влиять на систему, и описание того, как система будет отвечать на каждое из них.
Таблица решения
decision table — модель анализа в виде матрицы, где показаны все комбинации значений для наборов факторов, которые влияют на поведение части системы, и определены ожидаемые действия системы в ответ на каждую комбинацию.
Таблица состояний
state table — модель анализа, показывающая в виде матрицы состояния, в которых может находиться система или ее объекты, а также какие возможны переходы между состояниями.
Требование
requirement — документ, где указаны потребности или цели пользователей либо условия и возможности, которыми должен обладать продукт, чтобы удовлетворить такие возможности или цели. Свойство, которым должен обладать продукт, чтобы представлять ценность для заинтересованного лица.
Требования для интерфейса внешнего устройства
external interface requirement — описание интерфейса между системой ПО и пользователем, другой системой ПО или оборудованием.
Требования-«бантики», украшательство
gold plating — не являющаяся необходимой или избыточно сложная функциональность, запланированная и разработанная для продукта, иногда без одобрения клиента.
Управление требованиями
requirements management — работа с определенным набором требований к продукту, начиная от процесса разработки продукта и заканчивая поддержкой действующего продукта. Управление подразумевает отслеживание состояния продукта, управление изменениями требований и версиями спецификаций требований, а также отслеживание требований до других требований и элементов системы.
Утверждение
validation — процесс оценки рабочего продукта, позволяющий определить, действительно ли он удовлетворяет потребности клиента. Обычно формулируется в виде вопроса: «Создаем ли мы правильный продукт?»
Функциональная точка
function point — мера размера ПО, основанная на числе и сложности внутренних логических файлов, файлов интерфейса внешнего устройства, вводимых извне данных, результатов и запросов.
Функциональное требование
functional requirement — описание поведения системы в определенных условиях.
Функция
feature — одна или несколько логически связанных возможностей системы, которые представляют ценность для пользователя и описаны рядом функциональных требований
Цикл разработки ПО
software development life cycle — последовательность действий, в которой ПО определяется, конструируется, строится и проверяется.
Шаблон
template — образец, который используется в качестве руководства при создании всеобъемлющей документации или других элементов.
Эволюционный прототип
evolutionary prototype — полностью функциональный прототип, построенный как скелет или некая стадия конечного продукта, которые постепенно будут «обрастать мясом» по мере прояснения требований.
Экспериментальный образец
proof of concept — прототип, реализующий часть содержащей программную часть системы и охватывающий много уровней архитектуры. Применяется для оценки технической осуществимости и производительности. То же самое, что вертикальный прототип.
Эксперт предметной области
subject matter expert — лицо, имеющее обширный опыт и знания в предметной области и считающееся полномочным источником информации о предметной области.
Экспертиза
inspection — тип рецензирования, когда члены специально созданной команды в определенном и строгом порядке исследуют рабочий продукт на предмет выявления дефектов.
Эпика
epic — пользовательская история в проекте гибкой разработки, которая слишком большая, чтобы ее можно было реализовать в одной итерации разработки. Эпика разбивается на более мелкие истории, каждая из которых может быть реализована в одной итерации.
Литература
Карл Вигерс и Джой Битти — Разработка требований к программному обеспечению. Издание третье, дополненное. 2013 год.