Как и во многих других проектах, мы также используем JIRA для управления задачами и пользовательскими историями, а также Scrum в качестве методологии Agile. В конце каждого дня скрам-мастер предоставляет диаграмму выгорания команде PMO.
Тем не менее, первый набор вопросов, которые поднимаются во время каждой еженедельной встречи с командой PMO:
Откровенно говоря, вся команда уже устала от всех этих глупых вопросов, и все мы задаемся вопросом, действительно ли мы следуем ценностям Scrum или вместо этого просто поддерживаем JIRA, чтобы показать PMO, что мы все следуем Scrum и имеем почти идеальный график выгорания.
Меня всегда интересовали три момента:
Может ли кто-нибудь из вас прояснить мои вышеупомянутые три сомнения, чтобы мы все могли стать лучшей командой Scrum?
Спасибо всем заранее, и я ценю ваше время и предложения, чтобы помочь мне!
Я чувствую разочарование в вашем посте. Как человек, который перешел от PMO к Agile-роли, я могу понять обе стороны медали.
Ваш вопрос состоит из нескольких компонентов, которые я рассмотрю по очереди, но в основе каждого из них лежит эффективная коммуникация .
Это может быть несколько вещей, но руководство обязательно должно отслеживать часы работы. Это может быть одна или комбинация следующих причин.
Жестокая правда заключается в том, что я бы никогда не позволил сотруднику отказаться от учета своего рабочего времени, если он даже не может отслеживать свое рабочее время. Имеет ли это смысл?
У нас в армии была поговорка -
"Когда ты сможешь управлять собой, мы дадим тебе винтовку. Когда ты сможешь управлять своей винтовкой, мы дадим тебе транспортное средство. Когда ты сможешь управлять транспортным средством, мы дадим тебе подчиненных..."
Если ваша команда не может даже отслеживать часы, то с какой стати они должны быть освобождены от этой задачи? Это простой пункт, который занимает менее 5 минут. Я удивлен, что руководство еще не предприняло более строгих мер. Если ваша команда хочет независимости, они должны ее заслужить.
Частично это проблема психологии, но это также указывает на то, что им не объяснили ценность учета часов. Если им была объяснена ценность, и они продолжают обесценивать процесс, который руководство считает ценным, то у вас есть дисфункциональная команда , возможно, сосредоточенная на одном или двух сильных персонажах, которые управляют остальной частью группы.
В этом случае вы должны принять меры, чтобы привить дисциплину в команде. Скрам-мастер — это главный слуга команды. Большинство людей сосредотачиваются на роли слуги, чтобы показать смирение, но не забывают о роли хозяина. Навязывайте свою волю команде, чтобы убедиться, что они точно понимают, что будет, а что нет.
Сообщите команде, что
Всегда легче обвинить процесс управления, чем проводить анализ первопричин; по моему опыту, у большинства менеджеров есть веские аргументы в пользу отчетов и процессов, которые они запрашивают. Кроме того, в будущем, если вам потребуется увеличить или оспорить оценки планирования и у вас нет журналов, подтверждающих ваше экономическое обоснование, ожидайте, что ресурсы перейдут к руководителю отдела, который может обеспечить ведение журналов.
Удачи, даже поднятие этой проблемы в PM.SE указывает на то, что у вас есть отличные качества для решения этой проблемы.
Этот ответ представляет собой моментальный снимок того, где я работал и как я подошел к Agility. Должен сказать, что в настоящее время я абсолютно не поддерживаю табель учета рабочего времени, а табель учета рабочего времени сам по себе симптом запаха проекта, который требует анализа первопричин. Это указывает на отсутствие доверия к команде или распределению ресурсов между поставками. Короче говоря, это ужасный способ облегчить разработку программного обеспечения.
Кроме того, работающее программное обеспечение является основным способом демонстрации ценности . Все остальные артефакты — дым и зеркала.
Я поддерживаю свой ответ, поскольку он показывает путь, который мы все идем к ценностям Agile, но я больше не поддерживаю его как совет сообществу разработчиков или управления проектами.
Почему руководство больше заботит диаграмма выгорания JIRA, чем соблюдение ценностей Scrum при разработке проекта?
3 распространенные причины такого поведения:
Почему некоторые члены команды не любят каждый день усердно записывать часы в JIRA?
Либо это воспринимается как пустая трата времени, либо член команды не понимает ценности выполнения этой деятельности, либо он не получил поощрения за продолжение этой практики.
Есть ли что-нибудь, что команда может сделать, чтобы упростить регистрацию часов (каждым членом команды), чтобы руководство не беспокоило нас такими плохими вопросами?
Чтобы упростить регистрацию часов в Jira, вы можете использовать программу Worklog Assistant. Помощник рабочего журнала захватывает все фильтры из Jira, например, вы получаете список текущих задач спринта. Он предупреждает вас, когда не регистрирует время. Можно публиковать автоматически или делать это вручную и при необходимости корректировать журналирование. Создайте несколько билетов-заполнителей на время простоя, например, встречи спринта или другие накладные расходы, не связанные с спринтом.
Не уверен, что вы это сделаете, но не оценивайте задачи в часах, переключитесь на стори-пойнты (это поддерживается Jira). Руководству сложнее перевести проделанную работу в часы и сравнить их. Работа делается тогда, когда она сделана, а не тогда, когда команда ее оценила. Одни задачи займут больше времени, другие — меньше. Сгорание предназначено для того, чтобы дать представление о том, собираетесь ли вы закончить свой прогноз и соответствующим образом адаптироваться, если план не сработает.
Я думаю, что руководство беспокоится о часах, потому что они платят разработчикам за час. Каждый час — дополнительные деньги. Объясните, как Scrum дает разработчикам больше внимания и что его труднее отвлечь на несущественные вещи.
Однажды я был на презентации Scrum, которую проводил Джефф Сазерленд , и он сказал, что первое, что он меняет в компании, — это убрать отслеживание времени. Также прочитайте его сообщение в блоге . Отслеживание времени — это анти-Scrum: что вы делаете, когда вам это нужно для выставления счетов?
Вчера на тренинге по Scrum в Копенгагене с опытными руководителями проектов, работающими на уровне 5 CMMI в IBM и других местах, было достигнуто общее согласие, что просьба к разработчикам заполнять табели учета рабочего времени снижает производительность команды как минимум на 10%. Они ненавидят это делать, это двойная работа, это явно «отходы», и это делают только компании, которые не имеют ни малейшего представления о бережливой разработке продукта.
МСВ
Марк Филлипс