Гибкое управление проектами и продуктами | страница 34



Простота архитектуры и метафора системы

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

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

Коллективное владение кодом и стандарт кодирования

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

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

Сорокачасовая рабочая неделя

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

Глава 8. Анализ требований

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


Плюсы и минусы гибкого анализа требований


Роль системного аналитика

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


Функции владельца продукта


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

Ксения Колосова, руководитель проектов

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