А вот эти вот пустые области, что у меня красным выделены, они какую функцию выполняют? Чисто для красоты? Понятно, что ваш UI/UX-дизайнер сидел за монитором 24" и делал "красиво", но как это будет выглядеть на экране обычного ноута с коим обычно и ходит проджект? А когда задач несколько сотен? Плохо будет выглядеть, уверяю вас.
Такие проекты есть и довольно много, если говорить про аутсорс. Но прикол в том, что быстрее трёх месяцев все равно не въедешь, ибо объем документации и всяких неочевидностей -- огромен.
Мне кажется, вы путаете понятия "время вхождения" и "время через которое сотруднику можно поручить первую задачу".
Первую несложную задачу, действительно можно дать уже через неделю, а то и раньше. Но нас же в контексте оценки выгодности текучки интересуют совсем не это, а то, через какое время новый сотрудник сможет стать полноценной заменой выбывшего. И по моему опыту работы в проектах с хорошей документацией с автотестами и тд, этот срок от трёх месяцев до полугода: просто из-за того, что нужно освоить большой объем информации и научиться ориентироваться во всей кодовой базе проекта. Без этого, увы, говорить о полноценной замене невозможно.
По моему опыту (английской учил уже после института), главное -- баланс между лексикой и грамматикой. Если ты знаешь 10.000 слов, но не можешь составить из них предложение сложнее чем "give me two beers please" -- то какой смысл в твоем словарном запасе?
Что касается чувства языка, то лично у меня оно начинало появляться именно после осознавания (не заучивания) тех или иных грамматических конструкций. Возможно, если бы я жил в англоязычной среде и каждый день слышал вокруг себя только английскую речь, то все было бы по другому, приближено к тому, как учат родной язык дети: сначала неосознанное накопление информации и лишь затем ее структурирование.
У вас есть беклог из 100500 задач, вам нужно понять: 1) сколько из них вы возьмете в ближайший спринт? 2) сколько времени потребуется, чтобы переработать весь беклог (или его часть)? Эстимация в стори-поинтах отлично решает обе эти задачи. И главное -- решает быстро и достаточно точно.
И, кстати, считать, что велосити падает пропорционально выбывшим сотрудникам как раз говорит про бесполезность оценок в SP. Так как для сложных задач и разных сотрудников никакой пропорциональности быть не может, а если она есть - значит SP измеряют что-то не связанное с производительностью.
Падает оно, разумеется, не ровно пропорционально. Но если человек ходит в отпуск 2 недели за полгода, то влияние этой самой "непропорциональности" на проект будет столь невелико на фоне остальных факторов, что упарываться на это счет точно не стоит.
Но меня забавляет настойчивость в использовании плохих методов менеджмента,
Возможно дело в том, что у многих эти методы работают и приносят результат? А если у вас они не работают, возможно, дело вовсе не в методах? )
Касаемо 2 и 3 пунктов -- все ровно наоброт: когда сотрудники имеют одинаковую производительность, а задачи одинаковые и рутинные, -- то нет ничего проще, как рассчитать нормы времени в часах и использовать их при планировании.
Сложность наступает тогда, когда задачи не рутинные, а сотрудники имеют разную производительность. Каким образом вы предлагаете в этом случае проводить оценку? И отдельный вопрос: сколько времени вы на нее потратите?
Между тем стори-поинты как раз и помогают быстро и с достаточно большой степенью вероятности оценить сроки доставки объема задач. Ключевые слова здесь вероятность и объем задач: не стоит цели точно оценить конкретную задачу, цель в том чтобы оценить доставку всего объема работ.
Практика показывает, что уже после второй-третьей итерации, за счет обратной связи в расчете велосити, оценки становятся исключительно точными. То что вы этого не наблюдали, говорит либо о том, что либо вы работаете на каком-то очень специфичном проекте, либо у вас не было опыта правильного их использования.
Что касается первого пункта -- да, как я говорил изначально, при смене структуры команды беклог следует переэстимировать. Но как часто у вас меняется структура команды, если не брать отпуска или больничные? Раз в полгода-год? -- это не смертельно. А в случае отпусков или больничных -- просто уменьшаем велосити пропорционально выбывшим часам сотрудников -- и плюс/минус с большой степенью вероятности попадем в оценку.
бессмысленность оценок сложности, не соотнесенных с исполнителем достаточно очевидна, не понятно, зачем для этого что-то читать
Говоря так, вы заблуждаетесь. Оценка в стори-поинтах обязательно соотносится с исполнителем. Только исполнитель в данном случае -- это не конкретный человек, а конкретная команда людей. И если состав команды изменился -- беклог следует переэстимировать.
Насчет сылок на статьи -- там речь, скорее, не про сами стори-поинты, а про их неправильное использование. Собственно, первый же коммент под одной из статей ровно об этом:
It seems to me that your issue isn't story points themselves, but the usage of them.
Story Points (in combination with Team Velocity) - allows PMO to forecast delivery, to know if the set of requirements is achievable by the deadline or not.
Story Points isn't, and shouldn't ever be, a way to measure developer productivity (either within a Team or between Teams). There's better tools for that job (such as Git Quick Stats).
Ну потому что управление рисками, равно как и бюджетирование не имеет никакого отношения к методологии разработки софта. Поэтому вы и не находили там ответы на вопросы.
Между тем материалов по риск-менеджменту, бюджетированию, ченч-менеджменту в сети великое множество -- можно брать любой материал, который кажется более понятным и начинать использовать и совершенно неважно, какую методологию вы используете на уровне команд.
С этим никто не спорит, это как бы очевидно. Вопрос лишь в том, что вы в исходном своем комменте про "кукурузу" не упомянули потерю тяги вторым двигателем, между тем именно это являлось критичным фактором.
Статья интересная, подход внушает уважение, однако, прирост довольно скромен. Не могло ли получиться так, что вы бы достигли такого же прироста производительности, просто потратив немного времени в клавиатурном тренажере стандартной ЙЦУКЕН-клавиатуры?
А вот эти вот пустые области, что у меня красным выделены, они какую функцию выполняют? Чисто для красоты? Понятно, что ваш UI/UX-дизайнер сидел за монитором 24" и делал "красиво", но как это будет выглядеть на экране обычного ноута с коим обычно и ходит проджект? А когда задач несколько сотен? Плохо будет выглядеть, уверяю вас.
И да, где ссылка на демо версию?
Такие проекты есть и довольно много, если говорить про аутсорс. Но прикол в том, что быстрее трёх месяцев все равно не въедешь, ибо объем документации и всяких неочевидностей -- огромен.
Мне кажется, вы путаете понятия "время вхождения" и "время через которое сотруднику можно поручить первую задачу".
Первую несложную задачу, действительно можно дать уже через неделю, а то и раньше. Но нас же в контексте оценки выгодности текучки интересуют совсем не это, а то, через какое время новый сотрудник сможет стать полноценной заменой выбывшего. И по моему опыту работы в проектах с хорошей документацией с автотестами и тд, этот срок от трёх месяцев до полугода: просто из-за того, что нужно освоить большой объем информации и научиться ориентироваться во всей кодовой базе проекта. Без этого, увы, говорить о полноценной замене невозможно.
По моему опыту (английской учил уже после института), главное -- баланс между лексикой и грамматикой. Если ты знаешь 10.000 слов, но не можешь составить из них предложение сложнее чем "give me two beers please" -- то какой смысл в твоем словарном запасе?
Что касается чувства языка, то лично у меня оно начинало появляться именно после осознавания (не заучивания) тех или иных грамматических конструкций. Возможно, если бы я жил в англоязычной среде и каждый день слышал вокруг себя только английскую речь, то все было бы по другому, приближено к тому, как учат родной язык дети: сначала неосознанное накопление информации и лишь затем ее структурирование.
Но чтобы смонтировать директорию, надо же каким-то образом указать сетевой путь до нее. Он же указывается точно так же, разве нет?
Возможно, я ошибаюсь, но разве такой формат пути характерен именно для Windows? В Linux же, вроде как, точно такой же синтаксис сетевых путей?
Был в Тае лет десять назад, кухня оставила самые восторженные воспомининия: потрясающий си-фуд, очень вкусная еда у торговцев на улице.
У вас есть беклог из 100500 задач, вам нужно понять:
1) сколько из них вы возьмете в ближайший спринт?
2) сколько времени потребуется, чтобы переработать весь беклог (или его часть)?
Эстимация в стори-поинтах отлично решает обе эти задачи. И главное -- решает быстро и достаточно точно.
Падает оно, разумеется, не ровно пропорционально. Но если человек ходит в отпуск 2 недели за полгода, то влияние этой самой "непропорциональности" на проект будет столь невелико на фоне остальных факторов, что упарываться на это счет точно не стоит.
Возможно дело в том, что у многих эти методы работают и приносят результат? А если у вас они не работают, возможно, дело вовсе не в методах? )
Касаемо 2 и 3 пунктов -- все ровно наоброт: когда сотрудники имеют одинаковую производительность, а задачи одинаковые и рутинные, -- то нет ничего проще, как рассчитать нормы времени в часах и использовать их при планировании.
Сложность наступает тогда, когда задачи не рутинные, а сотрудники имеют разную производительность. Каким образом вы предлагаете в этом случае проводить оценку? И отдельный вопрос: сколько времени вы на нее потратите?
Между тем стори-поинты как раз и помогают быстро и с достаточно большой степенью вероятности оценить сроки доставки объема задач. Ключевые слова здесь вероятность и объем задач: не стоит цели точно оценить конкретную задачу, цель в том чтобы оценить доставку всего объема работ.
Практика показывает, что уже после второй-третьей итерации, за счет обратной связи в расчете велосити, оценки становятся исключительно точными. То что вы этого не наблюдали, говорит либо о том, что либо вы работаете на каком-то очень специфичном проекте, либо у вас не было опыта правильного их использования.
Что касается первого пункта -- да, как я говорил изначально, при смене структуры команды беклог следует переэстимировать. Но как часто у вас меняется структура команды, если не брать отпуска или больничные? Раз в полгода-год? -- это не смертельно. А в случае отпусков или больничных -- просто уменьшаем велосити пропорционально выбывшим часам сотрудников -- и плюс/минус с большой степенью вероятности попадем в оценку.
Говоря так, вы заблуждаетесь. Оценка в стори-поинтах обязательно соотносится с исполнителем. Только исполнитель в данном случае -- это не конкретный человек, а конкретная команда людей. И если состав команды изменился -- беклог следует переэстимировать.
Насчет сылок на статьи -- там речь, скорее, не про сами стори-поинты, а про их неправильное использование. Собственно, первый же коммент под одной из статей ровно об этом:
Честно говоря, диаграмма Ганта выглядит избыточной на столь коротком временном промежутке, как спринт. В остальном -- все разумно.
Кстати, ваш подход со сторипоинтами и часами прекрасно ложится на Microsoft Azure DevOps -- у них оно заточено именно на такой процесс.
Ну потому что управление рисками, равно как и бюджетирование не имеет никакого отношения к методологии разработки софта. Поэтому вы и не находили там ответы на вопросы.
Между тем материалов по риск-менеджменту, бюджетированию, ченч-менеджменту в сети великое множество -- можно брать любой материал, который кажется более понятным и начинать использовать и совершенно неважно, какую методологию вы используете на уровне команд.
В общем, при всем уважении, вы просто заново изобрели велосипед. Но то, что смогли извлечь из этого пользу -- это безусловный плюс )
А в чем новизна? Это же обычное дело: верхнеуровневое планирование осуществляется в виде гант-чарта (водопадной модели), а разработка -- по скраму.
Она принципиальная. Это абсолютно разные профессии.
Да все ловят пик глупости, просто некоторые идут дальше, а некоторые на нем и зависают.
А при чем тут мой бизнес? Это же вы, не разбираясь в ИТ-профессиях смело советуете, какую ИТ-професссию лучше выбрать, а не я.
Проджекта от продакта не отличаете, чем занимается скрам-мастер -- не знаете, но при этом взялись за статью про выбор карьеры. Смело )
А про эффект Даннинга-Крюгера доводилось слышать?
С этим никто не спорит, это как бы очевидно. Вопрос лишь в том, что вы в исходном своем комменте про "кукурузу" не упомянули потерю тяги вторым двигателем, между тем именно это являлось критичным фактором.
Статья интересная, подход внушает уважение, однако, прирост довольно скромен. Не могло ли получиться так, что вы бы достигли такого же прироста производительности, просто потратив немного времени в клавиатурном тренажере стандартной ЙЦУКЕН-клавиатуры?