я так понимаю, то с плавающими стори поинтами у вас ни одного спринта в срок и полностью сделать не удалось?)

Поэтому сказать что велосити упало разработчикам, которым просто попалась сложнее задача и выплыли другие проблемы - создавать лишнюю суету

Но оценки не коррелируют

Если стори поинты не равнозначны между спринтами, то любые ретроспективные метрики идут в пень:) так как они совсем не соответствуют реальности…как итог, начинает сыпаться планирование.

Увы

А они не коррелируют

Мне интересно, как вы в таком случае планируете спринт?

Как думаете откуда у меня данные?

Я - никак, у меня нет предпосылок к Scrum

А вот как я планирую релиз - другой вопрос :)

Вячеслав, вы можете возглавить новое направление agile методологий:) Будет называться SkyFingering Agile )))

А вы уверены что нет способов спланировать с высокой вероятностью количество сделанных тасков, группы тасков без велосити? Ничего нового, просто есть другие методы ;)

Слава, конечно есть:) Но вы так категорично заявляете о том, что велосити полная никому не нужная хрень, что становится страшно за весь аджайл))

Я не заявляю, я говорю что это штука промежуточная, она скорее позволяет команде научиться обсуждать задачи

В остальном она бестолковая

Но вы читаете не то что я пишу, а что-то другое :)

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

velocity не имеет отношения к скраму, но чаще всего к нему приписывается

Знаете какая хорошая метрика, чтобы что-то спрогнозировать?

Любимая тема :)

Есть метрика которая не зависит от уровня разработчка, от процесса, даже оценивать ничего не надо - но спрогнозировать сроки позволяет лучше чем любое velocity

Фантастическая метрика

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

Ну че интгрига есть или нет?

А то неинтересно

Очень надо сделать к - это цель

а не метрика

сейчас внезапно выяснится, что самая эффективная метрика - количество ударов плетью перед началом спринта:) Чем больше ударов, тем выше эффективность разработчика в конкретном спринте, тем больше «очень надо сделать к» :)

Скучно

Эффективность разработчика в конкретном спринте никому не интересна, интересно достигнута цель или нет. Но разговор про оценку - сделают ли набор задач к дате или нет

сейчас внезапно выяснится, что самая эффективная метрика - количество ударов плетью перед началом спринта:) Чем больше ударов, тем выше эффективность разработчика в конкретном спринте, тем больше «очень надо сделать к» :)

Это не метрика

Если мы говорим о том, как повысить общую эффективность, то это вопрос вовлеченности

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

У меня был случай, когда согласовали заведомо невыполнимый план, потому что «так надо»

Да-да, как посчитать мы к дате успеем или нет?

Наверняка только на исторических данных, поэтому я всегда начинаю с маленьких проектов и постепенно расширяю-разгоняю команду.

Ответ лежит примерно в той же плоскости как прогнозируется погода на 30 дней вперед ;)

Ну здесь все равно скороть реализации вылазит.

Владислав смелее

Не наверника, а ТОЛЬКО

И да, она по истории, а вот погода по движению воздушных потоков которые какбы предскажуемые но сложно

А распределение вейбулла? ;)

Алексей, думал вы знаете :p

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

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

Держите, а то нет времени уже вас мучать

Поэкспериментируйте и перестаньте мучать команды :)

Алексей, думал вы знаете :p

ЖЖешь. (с) Я вообще со статистикой на примитивном уровне работаю. Это Макс Дорофеев крут. но цифры которые мне система (знаете какая) дает - весьма интерсные, и вполне отражают действительность.

Там вопрос в точности

точность = риски

А риски закрываются буфером Цепи.

Алексей, уверен получите удовольсвтие от прочтения блога Троя. Подозреваю, много нового :)

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

А есть у вас входные исторические данные? Не хотите проверить ваш метод и инструменты троя?

Конечно проверю... хм, кажись похожую табличку у Макса видел.

У него интересный метод, но **можно проще**.

ЖЖешь. (с) Я вообще со статистикой на примитивном уровне работаю. Это Макс Дорофеев крут. но цифры которые мне система (знаете какая) дает - весьма интерсные, и вполне отражают действительность.

У меня есть смешной анекдот про Макса. В 13-ом году, когда я работал в модном стартапе на Октябре, он внедрял у нас аджайл. И через пару месяцев компания разорилась. Он потом приходил-переживал, не он ли в этом виноват (:

Какой-то несмешной :))

У меня есть смешной анекдот про Макса. В 13-ом году, когда я работал в модном стартапе на Октябре, он внедрял у нас аджайл. И через пару месяцев компания разорилась. Он потом приходил-переживал, не он ли в этом виноват (:

Процессы нужны устойчивой компании, стартапу нафиг не нужны TDD, CI, XP, Agile .wiki, PMBoK. Хорошие процессы это все-таки уровень CMM3. А стартапу нужно фигачить быстрее, пока актуально на своем хаосе CMM1. И желательно нос-к-носу чтобы коммуникации были немедленные. И да, преждевременное улучшение процессов может похоронить компанию.

ну… я бы не был так категоричен

> Alexey Процессы нужны устойчивой компании, стартапу нафиг не нужны TDD, CI, XP, Agile .wiki, PMBoK. Хорошие процессы это все-таки уровень CMM3. А стартапу нужно фигачить быстрее, пока актуально на своем хаосе CMM1. И желательно нос-к-носу чтобы коммуникации были немедленные. И да, преждевременное улучшение процессов может похоронить компанию. Бррр, нет. Процессы должны подходить компании (команде), но это не значит, что их не должно быть.

Хорошие процессы - это подходящие данной команде процессы, улучшить их - это сделать их более подходящими.

А не пытаться внедрить аджайл ради аджайла

И CMMI ради CMMI

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

Так что я присоединяюсь к рядам несогласных :p

Ходить руками на продакшен при любом уровне организации - большие риски

Тем более стоимость этого CI / CD - настроил за 1-2 дня и забыл

Слава прав

Процессы нужны устойчивой компании, стартапу нафиг не нужны TDD, CI, XP, Agile .wiki, PMBoK. Хорошие процессы это все-таки уровень CMM3. А стартапу нужно фигачить быстрее, пока актуально на своем хаосе CMM1. И желательно нос-к-носу чтобы коммуникации были немедленные. И да, преждевременное улучшение процессов может похоронить компанию.

Там была интересная ситуация, можно сразу в учебник по «как не надо». 1. Команда состояла на 3/4 из топовых разработчиков крупных компаний с зп 200-300 2. Топ-менеджмент состоял, опять же, из медийщиков, местами вообще не из ИТ 3. Проект шел несколько лет, финансировался в одиночку иностранным инвестором Итого: адский бернрейт, многочасовые совещания "куда подвинуть стрелочку" и вечеринки в модных клубах на др директора

Более того скажу - что из-за нормальной инженерки стартап имеет больше шансов выжить, потому что изначально не раздувается ФОТ (ручные тестировщики, админы - нафиг не нужны)

И может дольше находиться в стадии проверки гипотез.

Так что.. :)

Но тут другой момент - если стартапу надо "внедрять" Agile, а он еще на той стадии, когда не подтверждена венчурность истории - тут уже с большой вероятностью можно ставить крест

Более того скажу - что из-за нормальной инженерки стартап имеет больше шансов выжить, потому что изначально не раздувается ФОТ (ручные тестировщики, админы - нафиг не нужны)

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

Ну надо было не Agile, а ТОС применять и убедиться, что Agile - то что сейчас надо.

Зависит от уровня. за 4 недели проверки идеи, не нужен CI/CD, TDD и другие штуки. Если взлетело то уже через 6 недель начинаем думатьк ак попроправить так чтобы не отвалилось , и поднимается TDD и тесты которые можно прогнать перед коммитом. где-то через 8-10 недель, начинается понмание, что хотель бы упростить деплой, п поднимаается CI/CD через 3 месяца - если всё идет, возникает потребность в планах и координации и тут уже подлнимается канбан или xp/

:)

Это B2C, в B2B такиех сроков - 4 недели

...