Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.
Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.
Расчет времени, необходимого на выполнение задачи одновременно и очень простая и очень рискованная задача, с которой сталкиваются команды разработки.
Неверная оценка становится одной из первых причин срыва графиков или даже провала проекта.
Проблема в том, что бизнес рассматривает оценки как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».
К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:
Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.
Срочные встречи, рабочие письма, мессенджеры и упавший таск-менеджер еще больше запутывают и без того сложный процесс разработки, что делает идеальные часы, которые мы воображаем во время выставления оценок слабо полезными для менеджера проекта, пытающего собрать стремительно устаревающую диаграмму Ганта.
Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.
Естественно, подход с использованием SP не первая попытка решить озвученные проблемы, хотя и, вероятно, самый популярный.
В этом блоке я расскажу еще об одной программе, включающей в себя схему оценки задач. Программы называется PERT и знакомство с ней не обязательно для достижения цели тексты, поэтому можно смело перейти к следующему блоку.
Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.
Что если вместо оценки времени, которое потребуется для выполнение задачи мы будем оценивать усилия, необходимые на решение этой задачи? Для этого мы примем шкалу оценки и расставим на ней задачи, требующие оценки.
При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:
Звучит непросто, но давайте вспомним, что у нас нет необходимости выставлять каждой задаче четкую оценку, нам просто нужно найти ее место на шкале оценок между другими оцениваемыми задачами.
Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:
Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.
Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах, таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!
Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.
Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?
Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?
Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.
Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.
В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;
Суть метода заключается в следующем: всем участникам команды раздаются карты с числами из шкалы оценки. Затем выбирается задача и обсуждаются требования к ней. После обсуждения модератор просит всех членов команды выбрать карту и положить ее «рубашкой» вверх. Затем модератор дает сигнал показать карты.
Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».
Стоит отметить, что согласие не должно быть абсолютным. Вы можете условиться, что набор соседних оценок так же считается согласием.
Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.
Этот блок можно пропустить и перейти сразу к следующей странице.
Сколько часов в Story Point'e и как мне построить диаграмму Ганта?
Итак, мы оценили наш бэклог задач, но на Story Point'ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.
То же самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.
Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта. К тому же не забывайте про закон больших чисел, погрешности оценок взаимно компенсируются, это касается как задач, так и итераций. Стоит отметить, что это немного оптимистично, т.к. погрешности обычно связаны с недооценкой, а не переоценкой. Но ничто не идеально.
Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.
Какие нюансы нужно знать?
Каких ошибок можно избежать?
В заключении хочется собрать несколько советов для тех, кто в первый раз решил попробовать описанные методики в своей работе.
С чего начать
Это ваш первый покер планирования и команда не понимает относительно чего оценивать новые задачи. Соберите несколько уже реализованных задач, в идеале хорошо всем знакомых или типовых и оцените их сложность относительно друг друга. Используйте эти задачи для оценки новых.
У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.
Не усредняйте оценки
Иногда, когда два члена команды оценили задачу по-разному, так и подмывает назначить задаче усредненный балл и пойти дальше. Не поддавайтесь этому искушению, дискуссия это важный элемент оценки, в ходе нее команда может вскрыть ранее неизвестные особенности в реализации задачи.
Но, как и говорилось выше, вы всегда можете договориться о том, что близкие друг к другу оценки не будут являться поводом для дальнейшего обсуждения.
Не меняйте оценки
Даже если в ходе реализации вы поняли, что ошиблись при планировании, оставьте оценку неизменной. Вы будете ошибаться и в будущем, причем в обе стороны. Дайте этим ошибкам компенсировать друг друга, не вмешивайтесь в процесс.
Оценка багов
Я сталкивался с разными подходами к оценке багов. Некоторые команды оценивают все баги, кроме тех, что возникли в ходе реализации новых задач в итерации. Некоторые не оценивают баги, обосновывая это тем, что скорость команды должна показывать новую ценность, которая добавляется в продукт, и исправление багов не должно влиять на рост этого показателя.
Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.
Нулевые оценки
Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.
Вы можете ввести оценку в 1/2 балла для таких задач и ретроспективно отслеживать не превышает ли доля таких задач разумные пределы. Но главный совет все тот же, оставайтесь последовательными в своих решениях.
Переоценка незаконченных задач между итерациями
Не всегда удается закончить задачу в одну итерацию, даже если это планировалось изначально. Тем не менее не стоит изменять ее оценку при планировании следующей итерации исходя из количества оставшейся работы. Учитывайте это при планировании, но оставьте оценку неизменной для истории.
Ретроспектива оценок
Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.
В ходе ваших ретроспектив пройдитесь по оценкам, которые были сделаны при планировании итерации и обсудите не случилось ли больших отклонений между ожиданиями и реальностью.
Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.
Записывайте все
Если ваша система управления задачами не поддерживает оценки и не считает скорость команды автоматически, значит вам придется делать это вручную. Как Вы, наверняка, уже догадались исторические данные важный инструмент совершенствования ваших оценок.
Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.
Проблема
Расчет времени, необходимого на выполнение задачи одновременно и очень простая и очень рискованная задача, с которой сталкиваются команды разработки.
Неверная оценка становится одной из первых причин срыва графиков или даже провала проекта.
Проблема в том, что бизнес рассматривает оценки как обязательства. Разработчики рассматривают оценки как предположения.
Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».
Майк (Менеджер): Какова вероятность того, что ты справишься за три дня?Я думаю, что диалог выше звучит довольно знакомо для любого разработчика или менеджера проекта.
Питер (Разработчик): Пожалуй, справлюсь.
Майк: Можешь назвать число?
Питер: Пятьдесят или шестьдесят процентов.
Майк: Значит, есть довольно высокая вероятность, что тебе понадобится четыре дня?
Питер: Да. может понадобиться даже пять или шесть, хотя я в этом сомневаюсь.
Майк: До какой степени сомневаешься?
Питер: О, я не знаю… Я на девяносто пять процентов уверен, что работа будет сделана менее чем за шесть дней.
Майк: То есть может быть и семь?
Питер: Ну, если все пойдет наперекосяк… Черт, если ВСЕ пойдет наперекосяк, может быть десять и даже одиннадцать дней. Но ведь вероятность такого совпадения очень мала, верно?
К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:
Корреляция оценки и оценивающего
Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.
Идеальная оценка в неидеальном мире
Срочные встречи, рабочие письма, мессенджеры и упавший таск-менеджер еще больше запутывают и без того сложный процесс разработки, что делает идеальные часы, которые мы воображаем во время выставления оценок слабо полезными для менеджера проекта, пытающего собрать стремительно устаревающую диаграмму Ганта.
Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.
Альтернативные решения
Естественно, подход с использованием SP не первая попытка решить озвученные проблемы, хотя и, вероятно, самый популярный.
В этом блоке я расскажу еще об одной программе, включающей в себя схему оценки задач. Программы называется PERT и знакомство с ней не обязательно для достижения цели тексты, поэтому можно смело перейти к следующему блоку.
Program Evaluation and Review Technique
PERT или Program Evaluation and Review Technique была разработана в 50-е годы XX века в ВМС США.
Для оценки задачи по схеме представляются три числа:
O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.
N: номинальная и наиболее вероятная оценка.
P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.
По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:
А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:
Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:
Как видим данный метод заставляет оценивающего задумываться не только о позитивных, но и негативных сценариях и даже использует элемент статистики. Но, к сожалению, не отвечает на все поставленные вопросы и к тому же весьма усложняет сам процесс оценки.
Для оценки задачи по схеме представляются три числа:
O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.
N: номинальная и наиболее вероятная оценка.
P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.
По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:
А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:
Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:
Как видим данный метод заставляет оценивающего задумываться не только о позитивных, но и негативных сценариях и даже использует элемент статистики. Но, к сожалению, не отвечает на все поставленные вопросы и к тому же весьма усложняет сам процесс оценки.
Story Points
Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.
Что если вместо оценки времени, которое потребуется для выполнение задачи мы будем оценивать усилия, необходимые на решение этой задачи? Для этого мы примем шкалу оценки и расставим на ней задачи, требующие оценки.
При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:
- Объем требуемой работы;
- Техническую сложность задачи;
- Возможные риски и неопределенность в требованиях;
Звучит непросто, но давайте вспомним, что у нас нет необходимости выставлять каждой задаче четкую оценку, нам просто нужно найти ее место на шкале оценок между другими оцениваемыми задачами.
Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:
Относительность оценки
Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.
Замена часов на абстрактные баллы
Так мы снимаем с оценивающего необходимость оценивать задачу в часах. Вместо этого он оценивает ее в баллах, таким образом мы убираем противоречия в восприятии оценки разработчиком и менеджером. Более того, теперь отвлекающие факторы и форс-мажорные обстоятельства никак не повлияют на оценку, ведь они не меняют усилия, требующиеся для решения задачи!
Числа Фибоначчи, майки и собаки
Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.
Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.
 |
 |
Оценка в команде
Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?
Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?
Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.
Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.
Покер планирования
В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;
Суть метода заключается в следующем: всем участникам команды раздаются карты с числами из шкалы оценки. Затем выбирается задача и обсуждаются требования к ней. После обсуждения модератор просит всех членов команды выбрать карту и положить ее «рубашкой» вверх. Затем модератор дает сигнал показать карты.
Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».
Стоит отметить, что согласие не должно быть абсолютным. Вы можете условиться, что набор соседних оценок так же считается согласием.
Альтернативы
Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.
Этот блок можно пропустить и перейти сразу к следующей странице.
Афинная оценка
Об этом методе я узнал все из той же книги Роберта Мартина «Идеальный программист. Суть метода заключается в том, что все задачи записываются на картах без каких либо оценок. Экспертная группа стоит возле окна или стены, на которой карты распределены случайным образом. Участники не говорят между собой — они просто сортируют карты. Карты задач, требующих больше усилий, перемещаются вниз, требующих меньше усилий смещаются наверх.
Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.
На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.
Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.
Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.
На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.
Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.
Планирование проекта
Сколько часов в Story Point'e и как мне построить диаграмму Ганта?
Итак, мы оценили наш бэклог задач, но на Story Point'ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.
Короткий ответ на этот вопрос: „Никак“.
Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.
То же самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.
 |
 |
Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).
Собирая данные о скорости команды можно получить достаточно точные данные для долгосрочного планирования проекта. К тому же не забывайте про закон больших чисел, погрешности оценок взаимно компенсируются, это касается как задач, так и итераций. Стоит отметить, что это немного оптимистично, т.к. погрешности обычно связаны с недооценкой, а не переоценкой. Но ничто не идеально.
Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.
Практика
Какие нюансы нужно знать?
Каких ошибок можно избежать?
В заключении хочется собрать несколько советов для тех, кто в первый раз решил попробовать описанные методики в своей работе.
С чего начать
Это ваш первый покер планирования и команда не понимает относительно чего оценивать новые задачи. Соберите несколько уже реализованных задач, в идеале хорошо всем знакомых или типовых и оцените их сложность относительно друг друга. Используйте эти задачи для оценки новых.
У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.
Не усредняйте оценки
Иногда, когда два члена команды оценили задачу по-разному, так и подмывает назначить задаче усредненный балл и пойти дальше. Не поддавайтесь этому искушению, дискуссия это важный элемент оценки, в ходе нее команда может вскрыть ранее неизвестные особенности в реализации задачи.
Но, как и говорилось выше, вы всегда можете договориться о том, что близкие друг к другу оценки не будут являться поводом для дальнейшего обсуждения.
Не меняйте оценки
Даже если в ходе реализации вы поняли, что ошиблись при планировании, оставьте оценку неизменной. Вы будете ошибаться и в будущем, причем в обе стороны. Дайте этим ошибкам компенсировать друг друга, не вмешивайтесь в процесс.
Оценка багов
Я сталкивался с разными подходами к оценке багов. Некоторые команды оценивают все баги, кроме тех, что возникли в ходе реализации новых задач в итерации. Некоторые не оценивают баги, обосновывая это тем, что скорость команды должна показывать новую ценность, которая добавляется в продукт, и исправление багов не должно влиять на рост этого показателя.
Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.
Нулевые оценки
Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.
Вы можете ввести оценку в 1/2 балла для таких задач и ретроспективно отслеживать не превышает ли доля таких задач разумные пределы. Но главный совет все тот же, оставайтесь последовательными в своих решениях.
Переоценка незаконченных задач между итерациями
Не всегда удается закончить задачу в одну итерацию, даже если это планировалось изначально. Тем не менее не стоит изменять ее оценку при планировании следующей итерации исходя из количества оставшейся работы. Учитывайте это при планировании, но оставьте оценку неизменной для истории.
Ретроспектива оценок
Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.
В ходе ваших ретроспектив пройдитесь по оценкам, которые были сделаны при планировании итерации и обсудите не случилось ли больших отклонений между ожиданиями и реальностью.
Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.
Записывайте все
Если ваша система управления задачами не поддерживает оценки и не считает скорость команды автоматически, значит вам придется делать это вручную. Как Вы, наверняка, уже догадались исторические данные важный инструмент совершенствования ваших оценок.
MooNDeaR
Как сферический конь в вакууме — это прекрасно. Непонятно только что отвечать бизнесу "когда будет готов проект/фича", особенно в больших проектах.
На практике, не получается такого понятия, как "скорость команды" в действительно больших проектах. По одной простой причине — разные члены команды обладают разной крутостью своих скиллов. Для одних задач бывают нужны soft skills, чтобы добиться чего-то от других команд, для других hard skills. В больших проектах большой разброс подсистем с которыми приходится взаимодейтствовать и у разных учатсников команды совершенно разный опыт работы с ними.
В итоге, мы имеем два выхода из ситуации:
1) Заставлять всех работать со всеми частями проекта. Так мы заранее соглашаемся со снижением максимальной продуктивности, ибо переключения контекста, да и в целом, заниматься тем, что тебе не оч нравится (иначе почему ты в этом еще не хорош?) — это дело довольно унылое и ведет к выгоранию. Но в целом, бонусы есть — в среднем компетенция у команды выравнивается: опыт показывает, что те кто были экспертами, снижают свой уровень экспертизы, ибо нет времени поддерживать тот же уровень, остальные да, что-то новое узнают. Всех выгоревших/недовольных можно уволить нафиг, но тогда не стоит рассказывать мне в статье о том, что все эти методы оценки — это вот они для счастья команды.
2) Позволить людям заниматься тем, чем они занимаются лучше всего не перебрасывая их с одной части проекта на другую. Но тогда у нас появляются риски с передачей знаний, магическими подсистемами и всем сопуствующим. Они неизбежно срабатывают и вся "скорость команды" имеет непредсказуемое значение, а потому все эти оценки в SP в целом ничего не значат. Зато разработчики довольны, ибо занимаются тем, что нравится :)
P.S.
Хватит уже, пожалуйства, впаривать работникам чудные сказки о том, что все могут быть счастливы: и работники, и бизнес. Все эти управленческие свистоперделки — они только и только про потребности бизнеса, потребности разработчика в них никто и не пытается запихнуть. Я не говорю, что это плохо. Мне не нравятся только сам факт подмены понятий.
SirEdvin
Потому что это скучная монотонная работа (формочка или другая задача, которая занимает кучу времени чисто из-за ее нудности или копание в легаси-части проекта? Потому что вам идеологически не нравится задача? Вариантов на самом деле очень много. Ну и да, причем тут "нравится или нет", если тут скорее вопрос "есть ли компетенция в этой части проекта или нет"? Получается немного подмена понятий.
Почему-то, обычно разработчики страдают от серьезной нагрузки, потому что их модуль никто другой не знает и задачи в нем может пилить только он, а так же от отсутствия отпуска, потому что даже если он в него пошел — баг в его модуле тоже только он может починить. Вообще не знаю никого, кто был бы доволен ситуацией в пункте 2.
Особенно ситуация в пункте 2 выглядит классно, когда разработчик внезапно заболевает, критически важная задача для бизнеса не сделана или критически важная бага не исправлена, а вы понимаете, что заменить разработчика за вменяемый срок (условно, до месяца) вообще некем. В итоге просто все ждут разработчика и страдают.
Вы отрицаете потребность бизнеса в лояльных сотрудниках? Учитывая что лояльность часто формировать дешевле, чем поднимать ЗП, что бы компенсировать ее отсутствие.
MooNDeaR
Я не отрицаю потребность бизнеса в управляемых болванчиках. Я не люблю когда мне вливают в уши, что я должен это любить.
Страдает только бизнес. Работникам, в основном, плюс/минус наплевать.
Притом, что я разработчик :) Если задача рутинная, скучная и монотонная и я не хочу её делать, я конечно пойду её делать из под палки, но лояльность моя снизится. Вот соббсно и вся история. Все эти agile штуки ведут к уменьшению моей… ну, эффективность не то слово, скорее производительности. Я буду пилить говёную задачу "лишь бы отстали", что в последующем выльется в проблемы.
Он страдает, потому что хочет страдать, очевидно. Если бы меня не отпускали в отпуск на регулярной основе, я бы просто уволился и разбирайтесь со своей проблемой как хотите.
SirEdvin
Это прям в крупных компаниях. В средних обычно страдания бизнеса выливаются, например, в сокращении расходов на офис (был кулер? Ну, теперь будет фильтр), задержке зарплаты и уменьшение лояльности бизнеса к разработчикам. Потому что цикл обратной связи от владельца бизнеса 2-3 человека и докадывается до всех. Причем самое приятное в этой ситуации то, что как бы вам нужно просто ее перестрадать.
Есть такая штука, называется ответственность. Бывает она, например, перед коллегами или начальством. На словах обычно все как Львы Толстые, а когда доходит до дела, то вспоминаешь, что модуль пилил только ты, он тебе как родной, а задачи на него все приходят и приходят.
А кто же тогда будет делать рутинные задачи? Бедняга, который более уступчивый и в итоге потом тихо уволится? И вот тогда все эти прекрасные задачи свялятся на вас полным скопом и не уверен, что те выиграши в продуктивности, которые были получены окупятся.
Мне интересно, почему как лояльность, так сразу болванчики? Для вас лояльность это что в духе "люби компанию и делай для нее все" или, например, то что начальник более лояльно относится к вашему графику, а вы взамен иногда по 1-2 часа на выходных уделяете работе?
MooNDeaR
Это лишь ещё раз подчеркивает, что мы с бизнесом в разных лодках :) Чуть что не так — страдают сотрудники :) Думаете фильтр для воды, вместо кулера, будет поставлен в кабинет гендира. То-то и оно. Мы плывём может и в одной лодке, но при любой мелкой качке — вылетом с неё мы первыми, стоит об этом всегда помнить. Работодатель — не друг. И не враг. Просто способ обменять время на деньги, или удовлетворить свои амбиции и хотелки за счёт чужих денег) В конечном итоге, тот у кого ты их берешь все равно заработает на тебе много больше — и это справедливо, с учётом рисков, но это не значит, что я должен сопереживать его проблемам.
Что для кого-то рутина, для другого новый интересный мир :) Будьте честны на счёт задач при найме и будем всем счастье. К тому же, есть же люди работающие на конвейерах? Скорее всего они его ненавидят или просто равнодушны к работе. Таких много. Но никого не нужно заставлять любить рутину и говорить "смотри как классно, теперь твоя работа на половину состоит из задач, которые тебе не упёрлись, как классно, не правда ли?"
Причем, тут соббсно лояльность?) Мои договоренности с начальством, agile и переработки — дело мне кажется немного другого толка. К тому же, начальник в сущности тот же работник, но с другими задачами. Его бизнес интересует тоже постольку поскольку по сути, но чуть больше, чем меня, ессно.
Именно. И не только меня перед работодателем, но и работодателя передо мной. Отпуск и отдых — как раз из этих вещей :) Хочет меня дергать каждый раз — будь добр переработки оплачивай и вот это всё.
yaroslav2
Если фича важна, и она стоит в текущем спринте, либо в планах на ближайшие 1-2 спринта, то ответ очевиден. Если она важна, но в планах не стоит, то ответом будет предложение переопределить приоритет этой фичи в отношении других фич, которые стоят в планах. Всё это настолько просто, что уже не помню, когда наш бизнес задавал такой вопрос. Ведь планы и приоритеты у них всегда перед глазами.
Работаю в действительно большом проекте: много кода, очень много интеграций с другими проектами. По-моему, чем крупнее проект, тем стабильнее общая скорость разработки. Да и на уровне команд 6-10 человек она тоже достаточно стабильна. Главное – не гонять людей между командами.
Почему обязательно "заставлять". Здесь же всё логично. Надо просто объяснить. Согласен с SirEdvin – при ближайшем рассмотрении вариант 2 мало кому понравится.
Бизнес – это тоже работники. Мы все в одной лодке. Кому-то может казаться, что если он уел коллегу, то вырос профессионально. Но это не так. Профессиональный рост – это когда мы вместе с бизнесом достигаем поставленных целей, компания растет и приносит пользу всё большему числу клиентов.
Соглашусь, что во многих крупных компаниях о целях или клиентах компании мало кто беспокоится. Решения принимаются по политическим мотивам – люди взвешивают, какое впечатление произведут на начальство, коллег и пр. Работать в таких компаниях тоскливо. Да и настоящего Agile у них быть не может.
MooNDeaR
Не, объяснить-то можно, желания заниматься у меня от этого не появится :)
Не согласен. До тех пор пока бизнес может по желанию левой пятки уволить сотрудника, пока у сотрудника нет доли в бизнесе — ничего общего, кроме трудового договора у них нет.
Чем там измеряют профессиональный рост менеджеры я не знаю. Программисты обычно измеряют профессиональный рост сложностью технических задач, которые они стали способны решать. Тот факт, что способность создать стабильное, хорошо спроектировннае высоконагруженное приложение будут использовать миллионы людей, крут не потому что "смотри сколько людей это используют", а потому, что "смотри как я заставил эту железку работать!". Вот и вся история.
Эта история хоть и грустная, но в целом все мои сотрясения воздуха не об этом.
Я просто о том, что попытки что-то измерять в сторипоинтах на моей памяти проваливались, точно так же, как и попытки оценить что-то в часах.
Пассаж про запудривание мозгов — он вообще параллелен сторипоинтам. Это просто заметка о том, что в каждой статье как мантру повторяют, что все эти алжайлы и прочее — это ведь не только бизнесу, это нужно больше всего мне самому. Я так не считаю.
SirEdvin
По желанию левой пятки уволить сотрудника, а потом опять выходить на рынок и несколько месяцев искать нового человека, терпя убытки от нереализованных задач. Какой-то странный бизнес.
Эм… а что не так то с "смотри сколько людей это используют"? Мне вот, как программисту такое тоже нравится.
А как бы вы хотели вести разработку, в духе "Просто пиши код"? Когда все просто пилят, пилят, пилят без конца и края?)
MooNDeaR
Так, мне ща в самолёт, так что нет времени ответить полностью.
Я не против, в целом, организованной работы. Бардак явно хуже. Не против и agile, наверное, в целом (хотя в этом не уверен). Я просто против того, чтобы меня заставляли любить кнут в том или ином виде.
Аgile в некотором смысле, самый худший из всех кнутов. Его задача выжать меня как лимон и выбросить :) А т.к. знания в среднем распределены по команде, теперь надо просто взять следующий лимон. Может я просто не хочу быть эффективнее, чем я есть, меня лично все устраивает.
AstarothAst
Для этого нынче придумано еще одно модное слово — кроссфункциональность. Его пришлось придумать потому, что «и жнец, и швец и на дуде игрец» имеет четкие негативные коннотации, и продвигать его, как благо для разработчика, которому он должен радоваться, почему-то не получается.
yaroslav2
Кроссфункциональной должна быть команда, а не разработчик. Т.е. включать всех специалистов, необходимых для того, чтобы довести задачу до конца.
Говоря о "жнеце", Вы, наверное имели в виду понятие Т-специалиста, т.е. человека, у которого есть основная специализация, в которой он работает бОльшую часть времени, но он не отказывается при реальной необходимости выполнить и другую работу, которую знает, как делать. Например, Java-программист не отказывается написать простой SQL-запрос, если у разработчика БД перегруз или он заболел. Понятие Т-специалиста часто извращают, говоря о том, что тестировщики будут программировать, а программисты вместо них тестировать. На самом деле речь идет лишь о том, что все болеют за общее дело и выручают друг-друга при необходимости.
Ни первое, ни второе понятие не имеют отношения к обсуждаемой в данной ветке темы о том, что все программисты работают над всеми частями проекта.
Здесь речь скорее о таком аджайл-понятии как совместное владение кодом. Оно подразумевает, что любой разработчик может вносить изменения куда угодно. Нет строгого закрепления кода за разработчиками. Что не отменяет, однако, существования "владельцев" отдельных компонент, которые должны помогать новичкам погрузиться в компоненту, за которую ответственны, ревьювить код для неё от других разработчиков, следить за целостностью, соблюдением внутренней архитектуры и т.п.