TestingStage'17 - конференция №1 для тестировщиков. Успей купить билет по цене early bird до 26.04.

Помогите перевести команду на стори поинты

Всем привет! Помогите перевести команду на стори поинты. Вроде бы в теории все довольно легко и просто. Но возникает вопрос, как и кто все-таки должен оценивать задачи. У меня 3 разработчика и 2 мануальных тестировщика, т.е. команда в принципе не может быть кросс-функциональна, т.к. тестировщики не кодят. Сработает ли вообще здесь скрам? И как оценить задачу? В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят? Или же тестировщики тоже принимают участие?Финальная оценка — это разработка с учетом тестирования? Буду благодарна за ответы.

P.S. Также буду благодарна за ссылочки с реальными кейсами

Допустимые теги: blockquote, code, em, pre, i, li, ol, strike, strong, u, ul, a.
Ctrl + Enter
Допустимые теги: blockquote, code, em, pre, i, li, ol, strike, strong, u, ul, a.
Ctrl + Enter

По початковому переходу, розписую під впливом вже даних вам в коментарях порад:
Метод № 1. Вибираете одну комплексну вже виконану задачу, яку добре знає та розуміє вся команда, середньої складності. Призначаєте їй значення в 5 story point’ів. Порівнюєте з нею всі інші наступні задачі, і призначаєте їм відповідне відносне значення, вибираючи його з ряду фібаначі (до якого ще додайте на початку значення 0.5). Вище ніж 8 story point’ів старайтесь не призначати, дробіть такі задачі на менші.
Метод № 1, покращений. Виберіть не одну задачу-еталон, а створіть цілу еталонну сітку — табличка, стовпчики якої відповідають значенням з ряду фібоначчі. Розподіліть по цим стовпчикам певну кількість вже розроблених задач, це і буде ваша еталонна сітка складності. Під час оцінювання нових задач буде значно простіше зрозуміти, до якого значення все-таки ближче нова задача, порівнюючи з кількома еталонами, а не з одним.

Важливо, треба слідкувати щоб розробники не намагались закласти в оцінку задач якісь свої персональні здібності чи швидкість. Оцінка має бути відносно складності самої задачі, а не того, хто конкретно її буде виконувати.

Метод № 2, провальний. Постановіть, що тепер 1 година чи 1 день будуть називатись сторі пойнтом. Коли хтось під час оцінки буде за звичкою казати «3 години», виправляйте його — «3 сторі пойнти, не плутай», і по-змовницьки підморгуйте.

По процесу оцінювання: оцінюють всі, оцінюють весь об’єм роботи, включно з тестуванням.

помню как в команду из 4 девов пытались внедрить менеджера с какимито страшными словами вроде «скрам» и «сторипоинты», он ушел по собственному желанию через месяц)

ОМГ! Скрам, покер планирование, стори поинты... Вы работать собираетесь?

Зачем? Вы же менеджер, у вас есть беклог, вот через него и работайте. Делаете задачи по размеру до 1-2 дней, если делает дольше — пингуйте, спрашивайте есть ли траблы. А покер и поинты это все мишура.

Но возникает вопрос, как и кто все-таки должен оценивать задачи.
Команда. Вся. Целиком.
У меня 3 разработчика и 2 мануальных тестировщика, т.е. команда в принципе не может быть кросс-функциональна, т.к. тестировщики не кодят.
боюсь, вы в принципе не понимаете что такое кросс-функциональная команда. А может и команда вообще.
Финальная оценка — это разработка с учетом тестирования?
финальная оценка — это относительный размер сложности того, что задача (user story) полностью готова, принята и подготовлена к релизу. В идеале, и выложена на продакшн, но тут уже зависит от delivery процесса.
В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят?
нет, смысла в просто смотрении нет. Стейкхолдеры интересуются «почему так много, а что можно убрать чтобы было проще?» Девелоперы спрашивают тестировщиков почему такие большие эстимейты и как можно сделать тестирование проще. Тестеры удивляются такому низкому эстимейту девелоперов, ведь столько обсуждали историю — значит сложная, да и тест кейсов уйма. И т.п.

Кросс функцирнальность достигается на уровне команды, а не отдельных персоналий. Т.е. команда может теоретически все делать

Сделать 1 стори-поинт равным 1 часу — переход на стори-поинты проходит для команды легко и незаменто. :)

К тому же, клиенты/заказчики будут довольны — когда планирование/оплата работы будет в часах, а не в неких конкретно-командо-зависимых сущностях.

П.С. Разрабов и тестеров держать/менеджерить, по-отдельности.

И промах по оценке гарантирован на 100%, правильно можно будет только угадать. Либо если сам проект уровня конструктора лего, когда все составляющие известны и обкатаны — но тогда и команда не нуждается в управлении, достаточно одного ленивого манагера и план на стену.

Первые спринты делать замеры, насколько промахнулись (при этом, оценку команды можно множить скажем, на 2 или даже на 3).

А далее, оценку команды уточнять, уже более достоверными поправками.

К тому моменту все эстимэйсты с заказчиком уже согласованы. Проблема кроется в другом: сами отношения с заказчиком крайне вероятно совсем не скрамовые. А какие? Правильный ответ — в лучшем случае вотерфолл, в худшем (и наиболее вероятном) — сэйлз: «моё дело продать, а что я при этом наобещал — разгребайте сами, свой процент я уже забрал из предоплаты».

Це якраз найгірший варіант, який відповідає панівному у нас підходу «як так запровадити Scrum, що нічого по суті не змінювати, але щоб він типу був». Навіщо називати години сторі пойнтами? В чому перевага цього перейменування?

В такой команде мягко скажем делать нечего. На 3 разраба — 2 мануальщика и 1 менеджер? Что-то мне подсказывает, что при переводе на канбан можно оставить только 3 разрабов, стадию альфа-теста ликвидировать, и привлечь заинтересованного тестера со стороны заказчика.

Почему так: львиная доля тестирования — избыточна. И расходы на него явно выше чем расходы на риско ошибок.

Согласись, делать стори-поинты — это делить шкуру неубитого медведя. А делать канбаны — это таки убивать медведя по кусочкам. В чём разница: один лишний поинт разрушает всю иерархию системы, равно как и попытка расставить приоритеты. В то же время лишний канбан — нормальное явление, проект развивается органично. Но при этом неумолимо растёт качество — вместе со сроком сдачи.

Стори-поинты имеет смысл делать только тогда, когда нужен результат на срок. А качество — если успеваете. Иначе говоря, качество «на два с плюсом по пятибальной». Притом плюс — за счёт костылей.

С канабанами нельзя оценить конечный срок — поток запросов как правило бесконечен, столь же бесконечен как цикл саппорта и готовность заказчика добивать проект до победного конца. Но прекрасно оценивается срок полуготовности, а все отклонения от срока — очень предсказуемы и видны заранее. Это позволяет отдать предсказание заказчику и заставить его принять решение. Но есть вариант что сунет голову в песок — но это будет означать что в случае скрама проект был бы убит, а в случае канбан-подобных систем — всего лишь задача о жёстких переговорах о «мелкой» задаче. Однако проект будет жив, и будет жив сколько нужно, и будет предсказуем в любой стадии — включая передачу другой команде, другому менеджеру, и даже другому заказчику.

Недостаток канбан-подобных систем — низкая конфликтность. Конфликты априори выносятся за пределы системы, считаются человеческим фактором.

Скрам — является конфликтом сам по себе, это само ядро системы. В результате за пределы системы выносится эмоциональная составляющая конфликтов, они становятся табу, и система разрушает сама себя. Получается, что скраму хорошо поддаются челленджи, когда результат может получиться, а может нет, и все об этом знают. Как только вероятность результата признаётся либо утверждается 100% — скрам становится стрессом, и производительность падает в разы, иногда практически до 0. На такие команды жалко смотреть.

Почему так: львиная доля тестирования — избыточна. И расходы на него явно выше чем расходы на риско ошибок.
Я наблюдаю подобное мнение со стороны бизнеса. Это какойто звиздец. Продукт всегда получаеться очень глчный и бажный, и никто проблемы не видит, ни заказчик, ни менеджмент, ни сами программисты.

Если бы бюрократические методологии тестирования работали — мы бы жили в идеальном мире. А реальный мир таков, что единственный способ добиться качества — закладывать его в проект. Но никак не полагаться на массовый контроль, который всё равно даст на выход говно, но дороже на 40%.

Да поможет вам дедушка Дэминг.

Продукт всегда получаеться очень глчный и бажный, и никто проблемы не видит, ни заказчик, ни менеджмент, ни сами программисты.
Если продукт при этом успешно приносит бабло, то who cares?

Есть еще куча упущенного бабла

Разберем по-порядку:

1) Скрам — работает. Но скрам — это не только стори-поинты. И работает только если внедрять все в комплексе и правильно, а не выбирать отдельные куски или перекраивать процесс до неузнаваемости.

2) А вот «кросс — функциональные команды» по моему опыту как раз — не работают. Девелоперы плохо тестят, а тестировщики еще хуже фиксят баги.

3) Как оценить задачу в стори-поинтах?
Берем для начала пачку самых простых задач: поменять лейблу, поменять цвет, добавить тултип и т.д. Играем в «покер» что бы определить что будет относительной единицей — задачей в 1 стори поинт.
Более сложные задачи оцениваем относительно «единичной»: например подвинуть контрол на 2 пикселя это примерно как две лейблы поменять и т.д.
Если задача сложная и оценки расходятся — надо уточнять и разбивать а не ставить 100500 стори-поинтов «с потолка». Правила «покера» хорошо описаны — повторять все не буду.

4) Как увязать стори поинты с часами?
При планировании — эстимейтим в стори-поинтах. При закрытии таска — ставим реально потраченное время. Важно собирать максимум критериев по таску: в какой части, к чему относился, кто делал и т.д. Потому что, например, подвинуть на 2 пикселя в IE может быть в 10 раз дольше, чем в нормальном браузере. После набора достаточного объема данных уже можно считать и делать выводы. Мерять велосити команды и отдельных людей, искать проблемные места и т.д. Тиммемберам важно пояснить что это не для слежки и наказаний — что бы писали время честно. Советую блокеры заводить как отдельные таски. Например: у девелопера час ставились апдейты или собирался билд — он не должен это писать в текущий таск, а в отдельный. По итогам потом может, например, оказаться что 10% времени спринта уходит на банальное ожидание билдов.

5) В эстимейтах участвуют и двевелопероы и тестировщики. Каждые дают свою оценку: девелоперы — на заимплементить, тестрировщики — на протестить. Иногда оценки могут различаться в разы — это нормально. Иногда поменять одну строку — нужно перетестить все.

6) Тестирование и спринты. Вот это — тонкий момент. В теории задачи в течении спринта делаются, проверяются и бурндавн к концу выходит в ноль. На практике в начале спринта тестировать еще нечего, в середине — находят 100500 багов, к концу — девелоперы сидят ждут пока тестировщики что-то найдут. В последний день все лихорадочно «на лету» фиксят и перепроверяют — на полную проверку времени уже нет. Т.е. нагрузка — неравномерная и в результате зачастую в релиз идет не самая стабильна версия — а «подфикшенная» в последний момент.
Как с этим быть? Лично я видел несколько вариантов:
а) Разнести спринты девелопмента и тестирования. Т.е. 2 недели девелоперы девелопят — потом 2 недели тестеры тестят, а девелоперы фиксят найденные баги и делают следующие задачи. В результате каждые 4 недели выходит стабильная версия.
б) Автоматизация тестирования — девелопер только начинает имплементить а тестер параллельно начинает писать тесты. Фактически девелопер и тестер работают в паре. Когда готово — прогоняют тесты и закрывают задачу.
в) Отдельная команда тестировщиков. Пока идет спринт — за качество отвечает девелопер. Сам пишет юнити и автотесты для своей задачи. После релиза версия уходит в тестирование команде тестировщиков и они потом пишут баги, которые девелоперы берут в следующие спринты. В этом варианте тестировщики могут вообще не участвовать в скраме и эстимейтах.

В заключение: по моему опыту самое сложное — это перевести на стори-поинты клиента! Особенно если он не готов полноценно играть свою роль в скрам процессе. Без этого Скрам вместо процесса эффективного сотрудничества клиента и команды часто превращается в средство обмана и команды и клиента. Например: «у нас Скрам — поэтому не надо планировать архитектуру наперед», или «у нас Скрам — поэтому мы и не обещали что успеем все эти фичеры к клиентской выставке через 4 месяца». Гибкий процесс — это не значит бардак!

Хорошо написал. Единственный комент к 6:

На практике в начале спринта тестировать еще нечего
На этом этапе пишутся тесткейсы, ручные или автоматизированные
в середине — находят 100500 багов
Кол-во багов, найденных за спринт, хорошо учитывается матстатистикой. За 1-е несколько спринтов их необходимо измерить, в дальнейшем — учитывать при оценке сложности задачи.
Их кол-во будет уменьшаться к концу проекта, в середине оно будет примерно постоянной величиной.
к концу — девелоперы сидят ждут пока тестировщики что-то найдут
Нет. Они берут таски из топа бэклога, если вдруг возникла ситуация, что все таски сделаны, все баги пофикшены и в мире наступил коммунизм и благодать :)

А все как бы зависит. Это вообще-то решение, которое должна принять сама команда.

Мы раньше на нескольких проектах делали так:
— голосовали все.
— перед голосованием если была необходимость можно было сделать маленький интродакшен, где либо ПО, либо кто-то компетентный в данной области мог по простому описать всем как он видит что нужно сделать.
— после голосования человек не компетентный в данной сфере мог отозвать свой голос, если он сильно отличался от голосов людей компетентных, ну а иначе должен был мотивировать почему

И как оценить задачу?
Самое простое для начала привязать пинты ко времени, с оговоркой что это временно, только на газ и только для оценки, назад пинты во время не конвертировать.
В прокер планировании принимают участие только разработчики и ставят свои оценки, а остальные просто смотрят?
Немного безсмысленно, тогда надо делить команду по полам и делать 2 отдельных планинг покера.
Финальная оценка — это разработка с учетом тестирования?
Ну так это зависит от вашего тима, от того какие задачи вы оцениваете и того как Вы построили процесс, и от вашего «definition of done».
В общем по классике — конечно с тестированием и с последующим багофиксом, иначе кому она нужна без всего этого? Это хорошо и потому, что все могут принять участие в планировании и потому как укрепляет ваши внутрикомандные связи. У нас часто бывало что девелоперы ставили маленькие оценки, а тестеры большие и задавали вопрос «а как вообще это можно протестировать?». Но все зависит от вашей конкретной сферы, вашей команды, вашего рабочего процесса. Это вещи которые должна решать сама команда ибо по канонам скрама команда владеет своим процессом.

Еще одно — нету смысла переводить команду на стори поинты. Классический совет по скраму — адаптировать его целиком, со всеми ограничениями, принципами и практиками. А не переводить на сторипоинты. Само собой делать это надо с головой.

Мой совет насчет внедрения скрама — обязательно проводите настоящую ретроспективу. На ней анализируйте что вы делаете, что у вас получается, и имеет ли это смысл.

Привет, Алина

Есть два вида применения стори поинтов — (относительный, тру) стори поинт и стори поинт который по факту равен 1му человеко дню (идеальный день в теории аджайла). И тот и другой вариант применяют на разных фазах мачурити команды.
(Относительный) стори поинт стоит вводить только когда команда сработана и есть что проанализировать на ретроспективах, собственно есть на чем построить относительную шкалу. Для новых команд лучше использовать поинт-день а потом уже переходить на относительные поинты, либо продолжать эстимирование в идеальных днях, если не охота заморачиваться.
Во время покер планирования каждая задача оценивается только командой исполнителем, отдельно — девы не должны оценивать таски тестеров и наоборот.
Если команда уже сработалась то стоимость сторипоинта стоит оценивать по велосити команды, взять несоклько удачных спринтов и оценить в определенный обьем поинтов — это и есть велосити вашей команды, больше чем этот обьем команда не сможет выполнить за спринт. Дальше составить классификацию задач из спринта и назначить каждому классу средную оценку в стори поинтах, это будет ваша мастер шкала. ну а дальше — эстимирование и корректировки на ретроспективах.

спасибо! для уточнения: т.е. стоит оценивать велосити команды не в целом, а по подкомандам исполнителей? т.е. к примеру тестировщики могут выполнить такой объем за спринт, а разработчики такой?

Ага, у тебя всегда есть определенный ресурс на девелопмент и на тестирование отдельно, причем на каждый спринт он свой (отпуска, больничные, праздники). И смешивать их можно только если девы готовы тестить а тестеры — девить

спасибо огромное !

Вот смотришь человеку в профиль на линкедине, а там и скрам и канбан и другие умные слова:)
Ну как так?)

можешь бросить ссылочки на этих людей, я напишу им в личку ))

Вот такой профайл ))
www.linkedin.com/in/alina-dudka-994b7351

отличный профайл, я считаю ) написала в личку, чтобы про Кабан рассказали, а то ничего об этом в профиле не нашла )

Во-первых, спасибо за внимательность, без таких людей бы проекты точно рассыпались ;)
Во-вторых, как указано в комментариях выше, скрам — это не только стори поинты и можно использовать комбинацию элементов различных фреймворков аджайла, которые наиболее подходят под команду, проект, заказчика и т.д.
Мой вопрос звучит непосредственно о стори поинтах, т.к. именно этот элемент мы не использовали ранее и пришли к нему сейчас, когда команда уже созрела
И в-третьих, людей, которые работают по чистому скраму можно пересчитать на пальцах. Но это не означает, что другие не могут быть сильны в методологии. И почему-то в них никто не тычет, когда они указывают в профилях «Скрам-мастер», не имея соответствующего сертификата.

И еще раз спасибо за язвительные комментарии, они всегда помогают людям становиться лучше. А методом проб и ошибок мы достигаем результатов. Всех целую :*

чтобы про Кабан рассказали
это к зоологам :)

ты еще не видел резюме разработчиков — там и ораклы и винформы и все все все, и в 90% случаев просто нет чела который это все может хоть както проверить

Видел:) но я думал пм-ы честнее :))))

90% случаев просто нет чела который это все может хоть както проверить

А отзывы/рекомендации в письменном виде, от прошлых шефов — в Украине не приняты? На фирменном бланке компании, с подписью и прочими причиндалами, само-собой...

Подписаться на комментарии