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’а. Они также не могут добавлять оценки трудозатрат, поскольку это прерогатива команды.
Количество оригинальных идей в различных областях человеческой деятельности ограничено. Эксперты в области искусства давно определили, что в жанрах художественной литературы существует определенное количество сюжетов, варианты которых множатся и множатся. Так и эксперты в области экономики считают, что в сферах руководства коммерцией и товарным производством существует определенное количество идей, а тех, кто способен развивать и совершенствовать их, следует выделять как избранных, гениев менеджмента, из чего и образовалась концепция гуру руководства.
КАК СОКРАТИТЬ РИСКИ РЕКРУТИНГА И ПРОГНОЗИРОВАТЬ УСПЕХ? НОВЫЙ ВЗГЛЯД. В своей книге Адам Робинсон предлагает проверенный и крайне эффективный метод рекрутинга новых сотрудников. Он показывает, как переосмыслить процесс поиска, оценки и найма оптимальных кандидатов. НОВЫЙ МЕТОД. Робинсон, профессиональный рекрутер с двадцатилетним стажем, покажет вам: [ul]как составить профиль должности для оценки рисков как составить оценочную карту кандидата как оценивать основные компетенции кандидата как задавать правильные вопросы, чтобы собрать исчерпывающую информацию во время собеседования как сделать кандидату предложение, от которого он не сможет отказаться.[/ul] ВЫСОКИЕ РЕЗУЛЬТАТЫ.
Покупайте конкурентов, усиливайте команду, предлагайте новые продукты и услуги. Все эти предложения для большинства собственников и руководителей компаний актуальны в период роста, когда график продаж неуклонно идет вверх, а на лицах членов совета директоров по итогам отчетных собраний из полугодие в полугодие непременно играет улыбка. Автор придерживается иного мнения. Атаковать нужно в кризис, когда большинство топ-менеджеров заняты тем, что играют в защите, и, самое главное, – боятся волны кризиса, которая может отправить их на дно.
В учебном пособии рассматриваются юридическая природа государственного контракта, существенные условия государственного контракта в контексте положений Федерального закона от 5 апреля 2013 г. № 44-ФЗ «О контрактной системе в сфере закупок товаров, услуг для обеспечения государственных и муниципальных нужд». Подготовлено в форме научно-практического комментария статьи 34 названного Закона и с учетом изменений и дополнений внесенных Федеральным законом от 28 декабря 2013 г. № 396-ФЗ, а также последних разъяснений Министерства экономического развития РФ, Федеральной антимонопольной службы и Федерального казначейства.
Книга Александра Филатова написана на основе многолетнего опыта работы ее автора в советах директоров и адресована в первую очередь первым лицам крупных компаний. Ее задача – помочь акционерам и директорам корпораций четче понимать цели и компетенции совета директоров в зависимости от модели корпорации («управляемая»/«направляемая»), ее формы (ОАО/ООО) и множества других факторов. Александр Филатов разбирает наиболее часто встречающиеся ошибки советов директоров – к примеру, попытки участия в ежедневном управлении бизнесом – и предлагает способы ухода от них, а также подробнейшим образом останавливается на таких вопросах, как:• агентская проблема между менеджером и владельцем бизнеса;• права и фидуциарные обязанности директора;• вознаграждение членам совета; процедура работы совета;• оценка деятельности совета.
В учебнике с учетом современных требований освещаются актуальные вопросы коммерции и технологии торговли: основы построения процесса товародвижения; сущность и содержание коммерческой деятельности в торговле; коммерческая деятельность по оптовым закупкам и продаже товаров; организация и технология торговых процессов на предприятиях оптовой и розничной торговли. Специальные главы учебника посвящены тарным операциям в торговле, организации перевозки товаров различными видами транспорта, а также государственному регулированию торговли и правилам продажи товаров.