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’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.
Покупайте конкурентов, усиливайте команду, предлагайте новые продукты и услуги. Все эти предложения для большинства собственников и руководителей компаний актуальны в период роста, когда график продаж неуклонно идет вверх, а на лицах членов совета директоров по итогам отчетных собраний из полугодие в полугодие непременно играет улыбка. Автор придерживается иного мнения. Атаковать нужно в кризис, когда большинство топ-менеджеров заняты тем, что играют в защите, и, самое главное, – боятся волны кризиса, которая может отправить их на дно.
В монографии исследуются основные закономерности развития социально-трудовых отношений в аграрной сфере в современных условиях. В связи с этим работа включает изучение и анализ как исторически сложившихся, так и существующих социально-трудовых отношений в аграрной сфере, перспектив их развития.Представленный в монографии материал может быть полезен для ученых, работников сферы государственного управления и профсоюзов, студентов вузов, интересующихся вопросами труда и социальных отношений, складывающихся в процессе его реализации.
Монография посвящена принципам составления регламентов представительных коллегиальных органов местного самоуправления. Автор, анализируя действующее законодательство, судебную практику и опыт организации заседаний коллегиальных органов, высказывает предложения о формулировании и применении процедурных норм.В монографии приводится текст модельного регламента, составленного на основе реально действующего регламента представительного органа, который успешно используется уже более 10 лет.Автор – кандидат юридических наук, практикует в области правовой поддержки деятельности представительных органов МСУ.Для юристов, практикующих в области муниципального права, преподавателей юридических дисциплин, депутатов представительных органов.
Прежде чем взяться за перо, я много лет проработал в коммерческих предприятиях в качестве первого лица. Я не только работал (и работаю) генеральным директором крупных российских компаний из самых разных сфер — общепит, производство, отделочные материалы, — но и входил (и вхожу) в советы директоров государственных и частных компаний. Я бы никогда не написал эту книгу, если бы не московские пробки. Обилие «пробочного» времени, привычка записывать свои мысли и современные цифровые технологии сделали эту книгу возможной.В этой книге я делюсь собственным опытом и впечатлением от других прочитанных книг.
Любая предпринимательская деятельность – это не только извлечение прибыли, это прежде всего люди, которые работают в компании или у предпринимателя. Даже сам предприниматель, который трудится на себя, является работником. Аналогичная ситуация возникает и в том случае, когда в компании работает только генеральный директор, который одновременно является учредителем. И ошибочно полагать, что кадровый учет и кадровую отчетность в этом случае вести не нужно. Но большая ответственность на работодателе лежит, если в штате компании или предпринимателя трудятся работники.
Социальное предпринимательство — новое явление в российской практике. Эта монография — первое издание на русском языке, в котором рассматривается опыт социального предпринимательства в России и в мире с учетом его разнообразия и исследовательского потенциала. В книге обобщена информация, касающаяся развития социального предпринимательства в разных странах и современных исследований этой новой области; подробно описана деятельность одиннадцати иностранных и четырех российских предприятий, представляющих с разных сторон практику социального предпринимательства.