КР
И руководству должен в конечном итоге не понравится манагер, который привык обещать в 2 раза больше, чем команда выполнить может
Size: a a a
2019 November 07
КР
Пусть выкидывает из спринта менее приоритетные вещи
КР
И тогда получится настоящий аджайл, главное делаем сразу, рюшечки потом
IB
И руководству должен в конечном итоге не понравится манагер, который привык обещать в 2 раза больше, чем команда выполнить может
или менеджеру может не понравиться тот, кто не делает столько сколько он обезщает)
R(
Я слышал хорошую аналогию про сторипоинты, может даже уже "избитую"
Чтобы выкопать кубометровую яму, надо перелопатить кубометр земли, не важно, будешь ты лопатой или экскаватором это делать
Чтобы выкопать кубометровую яму, надо перелопатить кубометр земли, не важно, будешь ты лопатой или экскаватором это делать
Это интересый вопрос. Стори-понты пытаются уйти от строгих оценок "в кубометрах" или "в часах" , а выбирать что-то грубое-приблизительное, чтобы "ускорить процесс". Но задача одна и та же — "предсказуемость процесса". Если у кого получается предсказуемость строить на часах вместо стори-понтов, я вот считаю что лучше часы оставить.
А
Ildar Bekmansurov
делай как надо, а как не надо делать - не делай!
Нормально делай - нормально будет
КР
Нормально делай - нормально будет
Вот вы шутите, а зря
КР
Парни, неужели вы сами не можете оценить, вы с обычной скоростью работаете или пинаете?
КР
Если ты работал с обычной скоростью и не авралил, то вот она твоя капасити. Люди важнее процессов, 3 аврала подряд, несите нового работника
КР
И это надо техническому руководству доносить, которое в свою очередь должно влиять на рашн-манагеров, которые только руками махать могут и орать, а поработать на планировании - это не для них
R(
а как же этап планирования? разве он не для этого и нужен чтобы корректно прикинуть загрузку?
Я видел большие проблемы как планируют то чего изнутри ещё не видели, а потом заглядывают в код, а там ТАКОЕ что не согласовывалось с планированием. Опытные в скраме эту проблему знают и она обходится всякими "инвестигейтами" или ещё чем, что позволит понимать что ты собственно и от чего планируешь.
Но даже так выходит не всегда и на сразу, позаваливал я спринтов и даже фич оптимистам.
Но даже так выходит не всегда и на сразу, позаваливал я спринтов и даже фич оптимистам.
А
Парни, неужели вы сами не можете оценить, вы с обычной скоростью работаете или пинаете?
Да у нас то проблем нет, мне кстати нравится как ты обрисовал, если на собесе вдруг спросят про скрам и оценку буду знать что рассказывать
R(
Ildar Bekmansurov
вот есть у нас 2 разраба. У одного производительность 1.5 сторипоинта в спринт, а у второго 0.5. Общая - 2 сторипоинта в спринт. Есть 2 задачи по 1 сторипоинту. Сходится. Получается разраб с 1,5 производительностью закончит свою и потом должен помочь второму доделать или как? Они ведь не уложатся если каждый сам свою задачу будет делать
Может и так быть, что поможет. А может прийти Рома и тогда ничто не поможет :)
КР
Я видел большие проблемы как планируют то чего изнутри ещё не видели, а потом заглядывают в код, а там ТАКОЕ что не согласовывалось с планированием. Опытные в скраме эту проблему знают и она обходится всякими "инвестигейтами" или ещё чем, что позволит понимать что ты собственно и от чего планируешь.
Но даже так выходит не всегда и на сразу, позаваливал я спринтов и даже фич оптимистам.
Но даже так выходит не всегда и на сразу, позаваливал я спринтов и даже фич оптимистам.
И всё упирается в то, что задачи не готовы к взятию в работу, а ведь помимо definition of done существует definition of ready
R(
Коллеги, могу порекомендовать ЗНАЧИТЕЛЬНО увеличить оценки в SP, если у вас в спринт люди делают 0,5-1,5 сторипоинта, значит вы не пользуетесь замечательной последовательностью Фибоначчи
Попробуйте оценивать задачи "трудная"- 8 "очень трудная" - 13, если задача получает оценку в 20 - задача заворачивается на декомпозицию, как не готовая к взятию в работу.
Тогда у вас команда будет суммарно не единицы сторипоинтов делать за итерацию и будет виднее картина сколько можем сделать, и сколько обычно берём в спринт
Попробуйте оценивать задачи "трудная"- 8 "очень трудная" - 13, если задача получает оценку в 20 - задача заворачивается на декомпозицию, как не готовая к взятию в работу.
Тогда у вас команда будет суммарно не единицы сторипоинтов делать за итерацию и будет виднее картина сколько можем сделать, и сколько обычно берём в спринт
Присоединяюсь к рекомендации.
YA
Это интересый вопрос. Стори-понты пытаются уйти от строгих оценок "в кубометрах" или "в часах" , а выбирать что-то грубое-приблизительное, чтобы "ускорить процесс". Но задача одна и та же — "предсказуемость процесса". Если у кого получается предсказуемость строить на часах вместо стори-понтов, я вот считаю что лучше часы оставить.
ну сторипоинт это и есть, формально "кубометр". Насколько я знаю, по классике скрама, команда универсалов и специалистов, поэтому знают, сколько нужно сделать работы, что бы добавить какой-нибудь функционал в текущую архитектуру системы, т.е. они могут плюс минус адекватно назвать сторипоинты.
Я видел как команда успешно применяла сторипоинты, поэтому нет сомнения, что такой подход тоже может работать.
Я видел как команда успешно применяла сторипоинты, поэтому нет сомнения, что такой подход тоже может работать.
R(
Плюс, аджайл-команда должна быть кросс-функциональной, и если разработчик освободился от задач - пусть поможет тестеру
По теории и идеальному миру должна быть кросс-функциональной, но на практике этого никогда не случается: и наши люди не привыкли, и обстановка-бюджеты не располагают.
YA
идеальный мир скрама
КР
Кросс-функциональность - это уже вишенка, лишь бы басфактор не ровно 1 был, умер тестер - проект встал