Процессы и методологии

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

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

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

SDLC проходит стадии требований, проектирования, разработки, тестирования, развёртывания и сопровождения — последовательные фазы в Waterfall и повторяемые каждую итерацию в Agile. Аналитик ведёт требования и проектирование, затем поддерживает разработку, тестирование и релиз.

Kanban — вытягивающий метод потока: визуализируй работу на доске, ограничивай work in progress (WIP) и улучшай поток. WIP-лимит ограничивает, сколько пунктов одновременно в колонке, чтобы команда завершала начатое перед новым, вскрывая узкие места. Спринтов нет.

Это Waterfall (последовательные фазы, полная спецификация заранее), итеративная и спиральная модели, а также Agile-фреймворки вроде Scrum и Kanban (короткие циклы, меняющийся объём). При Waterfall аналитик описывает всё заранее; при Agile — непрерывно грумит живой бэклог.

Рефайнмент (груминг) — сессия, где команда проясняет, дробит и оценивает пункты бэклога для следующего спринта. Аналитик приносит понятные описания, критерии приёмки и зависимости. История «готова», когда отвечает Definition of Ready — понятна, тестируема и достаточно мала.

Пять событий Scrum: Sprint — таймбокс-контейнер; Sprint Planning ставит цель и выбирает работу; Daily Scrum синхронизирует прогресс и вскрывает блокеры; Sprint Review показывает инкремент стейкхолдерам ради обратной связи; Retrospective согласует улучшения процесса.

В Scrum три роли — Product Owner (владеет бэклогом и приоритизирует его), Scrum Master (ведёт процесс, снимает препятствия) и Developers (создают инкремент) — и три артефакта: Product Backlog, Sprint Backlog и Increment (готовый результат спринта).

Velocity — сколько story points команда закрывает за спринт, в среднем за несколько; это мера ёмкости для прогноза, а не оценка продуктивности. Burndown-диаграмма строит остаток работы против времени, показывая, укладывается ли спринт. Оба — сигналы тренда, не цели.

Аналитик отвечает за «что» — потребности, требования и ограничения; архитектор и разработчики — за «как» — технологии, структуру и код. Аналитик даёт требования и проясняет замысел, но не диктует технические решения, тогда как архитектор проектирует, а разработчики реализуют.

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

Приоритет бэклога у Product Owner: он ранжирует пункты по ценности, стоимости, риску и зависимостям — методами MoSCoW, RICE или взвешенной оценки. Аналитик помогает: даёт оценки трудозатрат и влияния, вскрывает зависимости и проясняет объём, чтобы PO решал по фактам.

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

Scrum работает спринтами с ролями, церемониями и объёмом, зафиксированным на спринт; Kanban — непрерывный поток с WIP-лимитами, без спринтов, изменения в любой момент. Scrum — для планового итеративного продукта; Kanban — для ровного меняющегося потока вроде поддержки или ops.

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

Product Owner владеет видением и бэклогом — решает, что строить и в каком порядке, максимизируя ценность для бизнеса. Системный аналитик прорабатывает, как требование реализуется, — специфицирует и моделирует его точно. PO отвечает на «что и зачем», аналитик — на «как».

Аналитик ведёт выявление, требования и спецификацию и совместно отвечает за проектирование. Позже, на разработке, тестировании и релизе, он консультант — проясняет требования и проверяет, что сборка отвечает спецификации, — а этими стадиями владеют разработчики, QA и DevOps.

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

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

Отделите «сделано меньше» от «измеряем иначе» — проверьте дрейф и ре-базирование оценок. Изучите качество требований (churn и размытые истории дают переделки), зависимости, блокеры и scope creep. Сигналы требований — переоткрытые истории — чиню; сигналы поставки — простои, отток — эскалирую.

SMART — чек-лист хорошо сформулированной цели: Specific (конкретная), Measurable (понятно, когда достигнута), Achievable (достижимая при ресурсах), Relevant (согласована с общей задачей) и Time-bound (с дедлайном). Он превращает размытое пожелание в отслеживаемый ориентир.