но имея статистику и эксель менеджеру даже знакомиться не надо

с командой

вот давайте поиграем в игру

угадай срок

и как погружение менеджера в проблему и знание им узких мест влияет на точность оценки сроков программистом?

как минимум когда тебе говорят сроки, ты можешь помочь наводящими вопросами и все ли они учли

следующей задачи

раз топики не связаны, давай тогда вернемся от скорости программистов к разговору о дереве KPI

но имея статистику и эксель менеджеру даже знакомиться не надо

и собранные показатели ведь?

раз топики не связаны, давай тогда вернемся от скорости программистов к разговору о дереве KPI

уже же решили, что в Agile KPI нет)

да есть там KPI

они просто д р у г и е

хорошо по этой теме заходит выступление Уразбаева на 15 по-моему AD

Статистика excel - всегда нужно понимать из каких задач эта статистика складывалась. Есть сайты визитки, а есть большие продукты с разным качеством кода

уже же решили, что в Agile KPI нет)

я об этом: т.е. с таким подходом [outcome] мы пытаемся влиять на какие-то компоненты деревьев KPI [заказчика]? глубокий подход, а он работает?

а не просто даем игрушку, которую он просит [output]

хорошо по этой теме заходит выступление Уразбаева на 15 по-моему AD

http://msk15.agiledays.ru/members/profile/867/#report-5 оно?

Подписка на #report-5

или в чем выражается outcome?

Статистика excel - всегда нужно понимать из каких задач эта статистика складывалась. Есть сайты визитки, а есть большие продукты с разным качеством кода

ну да надо понимать, понимать несложно

или в чем выражается outcome?

это вы должны решить

в margin например

ну да надо понимать, понимать несложно

а мне кажется это как раз основная сложность и бич всех менеджеров, кто не разбирается в software ingenering

не, бич менеджеров - это узкий кругозор

сверху намазанный излишней самоуверенностью :)

(ИМХО)

тема со сроками кароче сложная*, вариативность - проблема, но не такая страшная

margin -- составляющая переменного дохода компании, вполне себе компонент дерева KPI. еще варианты?

хорошо бы послушать agile команды

685 чел

думаю кто-нибудь да найдется про свои OUTCOMEs рассказать

Слава, а что именно рассказать? по истории переписки тяжело искать, в чем вопрос?

как мы в agile командах боремся с обещаниями и сроками?

а зачем вы с ними боретесь?

нет, какие outcome вы поставляете заказчику

Так это был коммент про KPI

а не про сроки

:(

в agile командах хочется верить борятся с другими вещами ))

а зачем вы с ними боретесь?

Карина, очень старнный вопрос. В agile так же стоит вопрос сроков и прогнозов.

да, они могут менятся

но на первичном грумминге с учетом velovity команды все равно делается примерный прогноз

Карина, очень старнный вопрос. В agile так же стоит вопрос сроков и прогнозов.

и бороться с обещаниями и сроками зачем?

Опять этот велосити )

и бороться с обещаниями и сроками зачем?

умение декомпозировать задачу и оценивать ее это такие же навыки команды как и все остальное

нельзя работать с рисками по срокам, когда данные в попугаях

ок, не нравятя формулировки. Расскажите мне как у вас проходит процесс груминга и спринт пленнига?

умение декомпозировать задачу и оценивать ее это такие же навыки команды как и все остальное

куда-то не туда всё ушло. мне так и непонятно, зачем бороться со сроками и обещаниями, но это ваше дело

куда-то не туда всё ушло. мне так и непонятно, зачем бороться со сроками и обещаниями, но это ваше дело

Команда формирует спринт и ставят с продуктом цели спринта

и если команда постоянно фелит спринты

то это проблема, которую нужно решать

никто не говорит про сроки в год, в пол года

борьбой со сроками и обещаниями? не будут обещать != перестанут фейлить спринты

(В скраме команда не берет обязательства сделать в срок, она берет обязательство - постараться, если что - то скрам аккуратно все связанное со сроками выпилил, потому что нет там никакой номральной модели работы с рисками)

JFYI

это самое смешное, то есть по сути скрам и есть сам по себе митигатор риска

из-за коротких спринтов

может посмотреть в сторону книги Mike Cohn "Agile Estimating and Planning"

Д!

http://focusedobjective.com/story-size-estimates-matter-experiment/

вот еще пытливым менеджерам - для анализа

"The ratio between hands-on versus total elapsed time called “process efficiency.” Often for software development this is between 5-15%. Meaning even if we nailed the effort estimates in points, we would be accurately predicting 5-15% of elapsed delivery time! "

5% !!!!

либо можно вывести коэффициент качества планирования и понят на сколько команда ошибается. От этого и отталкиваться при купировании рисков

Можно построть trend для lead time

по выбранным размерам

и увидеть как выставленные размеры соотносятся со сроками с течением времени

позвони покажу ))

ок, сейчас

(В скраме команда не берет обязательства сделать в срок, она берет обязательство - постараться, если что - то скрам аккуратно все связанное со сроками выпилил, потому что нет там никакой номральной модели работы с рисками)

ок, стараются и постоянно фейлятся. Возвращаемся к тому, что значит процесс оценки у них не работает - нужно садится и разбиратся

зачем знать, почему программисты плохо оценивают сроки? (не пофиг ли вообще) обычно исходный вопрос в том, когда зарелизят то или иное - как раз возвращаемся к outcome и output - и тогда уже другой вопрос - релизить фичу (вот такую реализацию чего-то) или ценность (не завязано на функциональные требования, как таковые - бизнес-требования). И тогда уже сроки релиза понятнее. ИМХО

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

По определению, хорошая оценка в 75% случаев находится в пределах 25% от фактического результата (Конте, Дансморе и Шэнь, 1986 г.).

@Wasyan можете пояснить? интересная тема

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

расскажите, пожалуйста, что вы называете груммингом. в скрамгайде это понятие я не нашла. в планировании спринта вообще ничего нет про сроки и обещания

Бэклог Спринта принадлежит исключительно Команде Разработки и служит наглядным представлением реального объема работ, который планирует выполнить Команда Разработки в течение Спринта.

для чего команда декомпозирует задачи и формурет спринт бэклог, если не собирается его выполнять

а, ну точно, для сроков и обещаний

вы путаете тёплое с мягким, почитайте скрамгайд. я не претендую на знание его от и до, но базовые понятия уж можно прочитать. Далее не вижу смысла объяснять что-то.

@Wasyan можете пояснить? интересная тема

это значит что если вы ошиблись в пределах 25% по срока, то это хорошая оценка

при вероятности в 75% случаях