Scrum и XP: заметки с передовой - [4]
Обычно product backlog хранится в Excel таблице с возможностью совместного доступа (несколько пользователей могут редактировать файл одновременно). Хотя официально документ принадлежит product owner’у, мы не запрещаем другим пользователям редактировать его. Ведь разработчикам довольно часто приходится заглядывать в product backlog, чтобы что-то уточнить или изменить оценку предполагаемых трудозатрат.
По этой же причине, мы не помещаем product backlog в систему контроля версий, а храним его на сетевом диске. Этот простейший способ позволяет избежать взаимных блокировок доступа и конфликтов синхронизации изменений.
Однако почти все остальные артефакты хранятся у нас в системе контроля версий.
Дополнительные поля для user story
Иногда мы используем дополнительные поля в product backlog’е. В основном для того, чтобы помочь product owner’у определиться с его приоритетами.
Категория (track) — Например, «панель управления» или «оптимизация». При помощи этого поля product owner может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет.
Компоненты (components) — указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений. Поле «компоненты» окажется особенно полезным, если у вас несколько Scrum команд, например, одна, которая работает над панелью управления и другая, которая отвечает за клиентскую часть. В данном случае это поле существенно упростит для каждой из команд процедуру выбора истории, за которую она могла бы взяться.
Инициатор запроса (requestor). product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
ID в системе учёта дефектов (bug tracking id) — если вы используете отдельную систему для учёта дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.
Как мы ориентируем product backlog на бизнес
Если product owner — технарь, то он вполне может добавить историю вроде «Добавить индексы в таблицу Events». Зачем ему это нужно? Да потому, что реальной целью этой истории, скорее всего, будет «ускорение поиска событий в панели управления».
И вообще, может оказаться, что не индексы были узким местом, приводящим к медленной работе поисковой формы. Причиной могло быть что-то абсолютно другое. Обычно команде виднее, каким образом лучше решить подобную проблему, поэтому product owner должен ставить цели с точки зрения бизнеса (т. е. что надо).
Когда я вижу технические истории подобные этой, я обычно задаю product owner’у вопросы вроде «Да, но зачем?». Я делаю это до тех пор, пока не проявится истинная причина появления истории (в приведенном примере — повысить скорость поиска событий в панели управления). Первоначальное техническое описание проблемы можно поместить в колонку с примечаниями: «Индексирование таблицы Events может решить проблему».
Как мы готовимся к планированию спринта
Не успеешь оглянуться — как наступил день планирования нового спринта. Мы не раз приходили к одному и тому же выводу:
Вывод: Убедитесь, что product backlog находится в нужной кондиции, прежде чем начинать планирование.
Что значит в нужной кондиции? Что все user story отлично описаны? Что все оценки трудозатрат корректны? Что все приоритеты расставлены? Нет, нет и ещё раз нет! Это значит:
• Product backlog должен существовать! (Кто бы мог подумать?)
• У каждого продукта должен быть один product backlog и один product owner.
• Все наиболее важные задачи должны быть классифицированы по уровню важности, а их числовые значения не должны совпадать.
a) Не волнуйтесь, если задачи с низким уровнем важности имеют одинаковые значения, скорее всего, они не попадут в текущий спринт, а, следовательно, не будут обсуждаться.
b) Все user story, которые, по мнению Product owner’а имеют гипотетическую возможность попасть в следующий спринт, должны иметь уникальное значение важности.
c) Уровень важности используется исключительно для упорядочивания историй. Т. е. если история А имеет уровень важности 20, а история Б важность 100, это означает что Б важнее A. Это не означает, что Б в пять раз важнее А. Если Б присвоить важность 21 — смысл не поменяется!
d) Полезно оставлять промежутки из целых чисел между значениями на тот случай, если появится история В, более важная, чем А, но менее важная, чем Б. Конечно, можно выкрутиться, присвоив ей уровень важности 20.5, но выглядит это коряво, поэтому для промежутков мы решили использовать только целые числа!
• Product owner должен понимать каждую историю (чаще всего он их автор, хотя иногда другие члены команды тоже могут вносить предложения, и тогда product owner обязан назначить им приоритетность). Он не обязан знать во всех подробностях, что конкретно следует сделать, но он должен понимать, почему эта user story была включена в product backlog.
Примечание: Хотя заинтересованные лица могут добавлять user story в product backlog, они не имеют права присваивать им уровень важности. Это прерогатива Product owner’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.
Объединение двух проверенных и отлично зарекомендовавших себя методик управления приносит отличные результаты. Не стало исключением и слияние японской системы бережливого производства и американской — шести сигм. Возникший в результате метод Lean Six Sigma («бережливое производство + шесть сигм») много лет дает возможность компаниям по всему миру повышать операционную эффективность своего бизнеса. Однако внедрение чисто производственных методик управления в сферу услуг представляло определенные трудности.
Издание предназначено для специалистов – занимающихся подготовкой и размещением заказов на проведение капитального и текущего ремонтов зданий и сооружений для государственных и муниципальных нужд. В издании рассматриваются вопросы обследования зданий, подготовки дефектных ведомостей, составления технического задания, подготовке и проверке (экспертизе) проектно – сметной документации.Особое внимание уделено основным аспектам составления проекта государственного (муниципального) контракта на выполнение работ по капитальному и текущему ремонту зданий и сооружений, в том числе порядку составления форм КС-2, КС-3 при бюджетном финансировании ремонтных работ.
Монография является обобщающим исследованием теоретических и методических основ внешнего государственного аудита в современных экономических условиях развития мировой экономики, представлены результаты влияния внешнего государственного аудита на фактический уровень достижения целей экономического развития Российской Федерации, даются рекомендации по использованию новых технологий внешнего государственного аудита российскими контрольно-счетными органами на основе современной методологии и лучшей мировой практики.Издание рассчитано на научных и практических работников, государственных служащих, лиц, обучающихся по программам повышения квалификации управленческих кадров и экспертов-аналитиков, преподавателей, магистрантов, аспирантов и студентов экономических специальностей вузов.
Систематизируется теоретико-методологический задел в сфере государственного и муниципального управления, излагаются основные аспекты государственного регулирования, методы и инструменты управления социально-экономическими системами в современных условиях.Для студентов специальностей «Менеджмент организации» и «Государственное и муниципальное управление», магистров, аспирантов, а – также практикующих менеджеров и юристов, интересующихся – проблемами государственного и муниципального управления.
В учебнике с учетом современных требований освещаются актуальные вопросы коммерции и технологии торговли: основы построения процесса товародвижения; сущность и содержание коммерческой деятельности в торговле; коммерческая деятельность по оптовым закупкам и продаже товаров; организация и технология торговых процессов на предприятиях оптовой и розничной торговли. Специальные главы учебника посвящены тарным операциям в торговле, организации перевозки товаров различными видами транспорта, а также государственному регулированию торговли и правилам продажи товаров.
Успех и неуспех развития бизнеса, как и его жизнеспособность, зависят не столько от вложенных денег и удачного местоположения, сколько от системы управления и работы главы компании. Недаром существует много поговорок, которые подчеркивают влияние руководителя на весь процесс: «Рыба гниет с головы», «Куда голова – туда и ноги», «Без дом – сирота». Именно «голова» детского клуба задает тон всему делу.В издании даны подробные инструкции по управлению детским клубом, формированию команды профессионалов и обучению сотрудников, планированию ежедневной работы организации документооборота, а также по безопасности бизнеса.В качестве приложений предлагаются примеры ученического договора и должностной инструкции администратора, а также пример конспекта занятия по курсу «Школа этикета».Практические советы адресованы собственникам и руководителям детских клубов, тем, кто только создает свой бизнес-проект детского клуба.