DevOps User Stories

Особенность DevOps User Stories в том, что для их выполнения необходимо плотное сотрудничество между dev и ops. Если сейчас его нет, то работа над этими историями – повод начать наводить мосты, создавать общие артефакты, пробрасывать петли обратной связи.

Никаких зависимостей между историями нет, каждая – самодостаточна. Это значит, что выполнять их можно в любом порядке.

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

Например «Как разработчик или пользователь я хочу иметь возможность самостоятельно получить требуемое окружение и все поддерживающие сервисы.» — это создание self-service платформы, но начать можно с малого. Много-много лет назад мы первую версию подобного инструмента на Python (c UI =) ) с использованием Xen написали за 4 дня и она сразу сняла немало рутины, а в командах сократились сроки реализации фичей, так как очереди на создание сред руками больше не было.

За основу были взяты найденные где-то когда-то в англоязычном сегменте истории. Со временем дополнил и, что немаловажно, опробовал в боевых условиях 🙂

Можете присылать свои варианты DevOps User Stories, добавлю в список с указанием автора (не забудьте указать)

    DevOps User Stories

    • Как разработчик, вышедший на новое место работы, я хочу получить полностью настроенное рабочее окружение менее чем за один час.
    • Когда мне, как разработчику, необходимо провести небольшие (косметические) изменения, я хочу иметь возможность задеплоить их менее чем за 1 час.
    • Как разработчик, я хочу знать среду выполнения разрабатываемого мной приложения (сервера, IP-адреса, установленные приложения, расположения директорий…).
    • Как разработчк, я должен понимать не только пользовательские, но и операционные требования к разрабатываемому приложению.
    • Как разработчик, я нуждаюсь в обратной связи от Ops в части влияния разрабатываемого приложения на операционную среду для того, чтобы со временем улучшить поведение системы (использование памяти, объем трафика, место на дисках).
    • Как разработчик или пользователь я хочу иметь возможность самостоятельно получить требуемое окружение и все поддерживающие сервисы.
    • Как разработчик я хочу получать уведомление о снижении производительности ниже установленной границы для того, чтобы быть проактивным в решении проблем производительности.
    • Как разработчик я хочу получать уведомление об излишнем потреблении системных ресурсов приложением в боевой среде.
    • Как разработчик, я хочу периодически получать/иметь доступ к отчетам о том, каким образом используется приложение, чтобы отслеживать изменения в поведении во времени.
    • Как разработчик, я хочу вносить изменения в настройку шагов сборки в одном месте, чтобы снизить риск появления различий для различных окружений.
    • Как разработчик, я знаю, какие части конфигурации могут быть отрегулированы.Как админ разработчик, я знаю, какие части конфигурации могут быть отрегулированы.
    • Как у разработчика, у меня есть понимание о внутреннем устройстве и поведении развернутого приложения и таким образом, я могу управлять и настраивать его более эффективно.
    • Как разрабочик, я знаю от каких сервисов зависит разрабатываемое приложение.
    • Как админу, мне необходимо знать, над чем в настоящий момент работают разработчики для того, чтобы я мог предоставить эксплуатационные требования и подготовиться к установке.
    • Как админу (разработчику), мне необходимо построить отношения с разработчиками (админами) таким образом, чтобы они были позитивными и открытыми.
    • Как админ, я должен знать/мониторить состояние приложения.
    • Как админ, я знаю подходы к разработке и могу подготовить необходимые ресурсы.
    • Как админ, я знаю о появлении аномалий в безопасности и могу защитить сервисы от атак.
    • Как разработчик, я знаю, какие части конфигурации могут быть настроены и каким образом.
    • Как разработчик, я знаю о появлении аномалий в безопасности и могу осознанно применить техники, препятствующие проникновению злоумышленников.
    • Как спонсор проекта, я знаю о существующих рисках (доступности, тестопригодности и т.д.) для того, чтобы управлять ожиданиями инвесторов и выделением требуемых ресурсов.
    • Как спонсор проекта, я знаю как и до какого уровня были снижены риски поставки.

    To be continued…

    Share

    Добавить комментарий