Здравствуйте, _ABC_, Вы писали:

_AB>Пятиминутки и не призваны решать проблемы. Они призваны запланировать необходимые действия для решения проблем. У вас они затягиваются потому, что вы тупо не понимаете их смысл и цель.
Они не нужны, sync meeting раз в неделю хватает за глаза.

Здравствуйте, Pauel, Вы писали:

P>Задача менеджера — сделать коммуникацию эффективной, следовательно, митинги — полезными.
Митинг, который мог бы быть емылом — не нужны. У нормального менеджера колво митингов с большим колвом народу — исключения. А регулярные митинги с большим колвом народу — ещё бОльшее исключение.

Здравствуйте, CreatorCray, Вы писали:

CC>Они не нужны, sync meeting раз в неделю хватает за глаза.
Извини, но sync meeting раз в неделю — у вас менеджеры управляют командой раз в неделю?

Здравствуйте, CreatorCray, Вы писали:

CC>Митинг, который мог бы быть емылом — не нужны.
Тебе на то, чтобы написать то, что ты можешь сказать на стенд апе придётся затратить времени столько же, сколько должен длиться нормальный стенд ап.
Чтобы прочитать все письма от всех, менеджеру придётся затратить как минимум столько же. И это без учёта возможных быстрых уточняющих вопросов.

CC>У нормального менеджера колво митингов с большим колвом народу — исключения. А регулярные митинги с большим колвом народу — ещё бОльшее исключение.
У вас сколько народу на стенд апе? Что такое "большое количество народу"?

Здравствуйте, _ABC_, Вы писали:

CC>>Они не нужны, sync meeting раз в неделю хватает за глаза.
_AB>Извини, но sync meeting раз в неделю — у вас менеджеры управляют командой раз в неделю?
Всё остальное время регулярный индивидуальный контакт по надобности. Офисы рядом, ногами дойти как нефиг. Если кто не на месте — пиши в шлак.
Вот именно чтоб говорильни устраивать только если надо что то группе сообщить.
Если кому то надо что то сказать другим — есть канал в шлаке, пишут туда.
А вот такие stand up говорильни они только отвлекают.

Здравствуйте, _ABC_, Вы писали:

CC>>Митинг, который мог бы быть емылом — не нужны.
_AB>Тебе на то, чтобы написать то, что ты можешь сказать на стенд апе придётся затратить времени столько же, сколько должен длиться нормальный стенд ап.
Зато ты отвлечёшь кучу людей прямо сейчас. Емыл же прочитают когда будет удобно.

_AB>Чтобы прочитать все письма от всех, менеджеру придётся затратить как минимум столько же.
Правильный менеджер и без standup знает кто что делает, и один фиг нормальный статус во время standup не расскажешь. Ну если только таски не типа "переименовать foo в bar".

_AB> И это без учёта возможных быстрых уточняющих вопросов.
Это всё один фиг надо 1:1 обсуждать, не вовлекая остальных.

_AB>У вас сколько народу на стенд апе?
обычно человек 10-12.
У нас стендапы уже искоренили почти все, остались только в дни когда народ работает из дому, видимо просто чтоб не сачковали

_AB> Что такое "большое количество народу"?
Человек 30+ это уже много

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, baxton_ulf, Вы писали:

_>>ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды
CC>Как вариант кстати.
CC>Но это похоже припарка, после того как там "вынудили удалить все что относиться к IDE", "редактировать в mc собирать make и отлаживать через логи".
CC>Когда в культуре компании превозносится девиз "Стоя! В гамаке! И на лыжах!" то это нехороший знак это та из контор, где надо всем и всегда рассказывать как тебе было тяжко, как всё было плохо, но ты таки превозмог! Даже если речь шла про пойти отлить. Ибо там работу будут оценивать не по тому, как ты её быстро и хорошо сделал, а по тому, как ты рассказывал как ты устал превозмогая. Впрочем это в общем то повсеместно в местах с хреновыми манагерами.

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

ПС: я со скрамом столкнулся когда стал на амазон работать. вот там стендап был что то типа — все помямлили и разошлись самая интересная часть была когда онколл выбирал где сегодня будет тимланч
но даже при таком стендапе, таски создавались так, чтоб не более 3-4 дней на таск, все что больше сразу же разбивалось на мелкие субтаски. на исследования, если прям вот совсем надо провести, выделялся отдельный толи таск толи как-то еще назывался, но со своим лимитом времени. типа если за пару дней не получилось сделать как предполагали, то стоп — фиксируем прибыль/убыль. кстати похоже у Сереги с этим и проблема — не может он придти к босу и сказать: "ну не шмагла я"

Здравствуйте, CreatorCray, Вы писали:

CC>Зато ты отвлечёшь кучу людей прямо сейчас.
Зачем "отвлечёшь", если это де-факто открытие дня? Или закрытие, у кого как.

CC>Емыл же прочитают когда будет удобно.
Если его напишут и если его прочитают. И если поздно не будет на него отреагировать.

CC>Правильный менеджер и без standup знает кто что делает,
Отвлекая каждого за пределами стэндапа на распросы?

CC>и один фиг нормальный статус во время standup не расскажешь.
Расскажешь, если научишься.

CC>Ну если только таски не типа "переименовать foo в bar".
Кстати, о "научишься".

CC>Это всё один фиг надо 1:1 обсуждать, не вовлекая остальных.
Опять "обсуждать"...

CC>обычно человек 10-12.
Что значит "обычно"? Стендап же для всех членов команды, которые вышли сегодня на работу.
Сколько всего человек в вашей команде? В той, что, грубо говоря, работает над одними и теми же кусками кода/продукта, которая делит один и тот же план работы на неделю (sprint backlog, whatever you call it)?

CC>Человек 30+ это уже много
Стенд-ап на 30+ человек? Серьёзно?

Здравствуйте, CreatorCray, Вы писали:

_AB>>Чтобы прочитать все письма от всех, менеджеру придётся затратить как минимум столько же.
CC>Правильный менеджер и без standup знает кто что делает, и один фиг нормальный статус во время standup не расскажешь. Ну если только таски не типа "переименовать foo в bar".

У меня для тебя плохие новости.
Стендап — он не для менеджера.
В принципе, скрам методология — это не об управлении.

CC>обычно человек 10-12.

Это уже много

Здравствуйте, sergey2b, Вы писали:

S>где мои коллеги бодро рапортую о запилинных за 24 часа фичах или исправленных багах
S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up

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


S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?

Смени деятельность, будь каа радостные коллеги. Но тебе же нравится ковыряться в C++- тогда не жалуйся.

Здравствуйте, _ABC_, Вы писали:

_AB>Я, кстати, тоже пытался впендюрить в скрам багфиксинг хоть как-то и считал этот аспект признаком полной отрованности скрама от жизни. Пока не понял для себя эту разницу. Хреново только, что ответа в чистом виде я не находил ни в англоязычном, ни в русскоязычном сегменте. Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта. Пришлось доходить своим умом, а он у меня не блестящий и менеджер я хреновый, так что дошло только совсем недавно. Вышестоящие менеджеры, так уж исторически сложилось, все из консультантов, не разработчиков, тоже подсказать не могли. На всяких курсах по управлению проектами и во всяких книгах я тоже, почему-то, этого не видел. Может мимо проходило, а может и нет там этого в явном виде.

В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное.
Нужно будет при планировании спринтов учитывать, что часть времени команды будет отвлечена на отдельный канбан проект.
Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт. Так еще можно реализовать ротацию ответственности за багфиксы.

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

Здравствуйте, landerhigh, Вы писали:

L>В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное.
Вопрос не в джире, такое везде, наверное, можно провернуть. Вопрос именно в том, что это не часть проекта per se.

L>Нужно будет при планировании спринтов учитывать, что часть времени команды будет отвлечена на отдельный канбан проект.
Именно.

L>Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт.
Тут два момента.
1. Эти таски не способствуют достижения цели спринта (ну, как правило не способствуют).
2. Если их добавлять в течение спринта, то они "воруют" team capacity.

L>Так еще можно реализовать ротацию ответственности за багфиксы.
Да, согласен. Но всё это по сути сводится к одному — часть времени команда тратит не на проект, а на операционную деятельность.
А все возможные варианты — это лишь способы учесть и попытаться проконтролировать эту деятельность.

ИМХО, конечно.

L>У нас багфиксы редко бывают рафинированными, чаще всего они вырастают в отдельные проекты по изменению функциональности.
Тогда это не баг, а фича.

S>у меня задача в среднем длиться от неделю до 12 недель
У нас есть такой проект, который сам по себе, коллега сначала начал говорить каждое утро, что у него все то же самое, потом стал принимал участие только слушателем, а после уволился.
Сейчас другой на его месте что-то бурчит каждое утро, не уверен, что его кто-то слушает.
И нужно это только присутствующим начальникам, чтобы видеть, что проект движется.

Здравствуйте, landerhigh, Вы писали:

Невозможно спланировать то, что ты еще не знаешь точно как решать. Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту. Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, landerhigh, Вы писали:

C>Невозможно спланировать то, что ты еще не знаешь точно как решать. Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту. Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.

Такое тоже не исключено.
Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, landerhigh, Вы писали:

L>>В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное.
_AB>Вопрос не в джире, такое везде, наверное, можно провернуть. Вопрос именно в том, что это не часть проекта per se.

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

L>>Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт.
_AB>Тут два момента.
_AB>1. Эти таски не способствуют достижения цели спринта (ну, как правило не способствуют).

Просто плейсхолдер, чтобы не забывали, что часть времени будет потрачено вне проекта.

L>>У нас багфиксы редко бывают рафинированными, чаще всего они вырастают в отдельные проекты по изменению функциональности.
_AB>Тогда это не баг, а фича.

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

Здравствуйте, Codealot, Вы писали:

C>Здравствуйте, landerhigh, Вы писали:

C>Невозможно спланировать то, что ты еще не знаешь точно как решать.
Можно спланировать свое исследование задачи.

C>Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту.
Поэтому и существуют гибкие методологии, которые не требуют создание плана на месяцы вперед.
Спланируй на день, ты ведь сможешь прикинуть что ты будет делать сегодня? Потом спланируй на 5 дней. Причем ты вполне можешь накидать несколько вариантов задач на неделю в зависимости от результатов исследования каждый день. Этого уже достаточно.

C>Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.
Детализация задач до размера одного дня и ежедневные стендапы позволят это узнать пораньше.

Здравствуйте, landerhigh, Вы писали:

L>>>Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову.
K>>Скрам плохо подходит для исследований

L>Как раз для исседований он прекрасно подходит.

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

Здравствуйте, Pauel, Вы писали:

P>На счет прекрасно — это крайне сомнительно, т.к. именно в исследованиях неопределенности на порядок выше чем в любых продуктовых фичах.

Что, по твоему, исследования?
Набежали ученые в белых халатах и давай исследовать, аж фуфайки халаты заворачиваются?

Нет, это та же самая проектная работа. Зачастую даже более рафинированная, нежели более приземленные проекты.
У любого исследования есть некая цель — проверка гипотезы, поиск решения для некоей проблемы и т.п. В любом случае подобная работа начинается с предварительных исследования — поиск научных публикаций по смежным темам, предлагаются эксперименты и так далее. Постановка экспериментов — самая что ни на есть проектная работа. Особенно в тех случаях, когда требуется изготовить оборудование конкретно под эксперимент

P>Чем больше неопределенности, тем хуже работает скрам.

Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет.

Здравствуйте, landerhigh, Вы писали:

P>>На счет прекрасно — это крайне сомнительно, т.к. именно в исследованиях неопределенности на порядок выше чем в любых продуктовых фичах.

L>Что, по твоему, исследования?

Исследования это решение проблемы вида: неизвестно а можно ли сделать, а как вообще стоит сделать, а какие будут требования к этому

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

L>У любого исследования есть некая цель — проверка гипотезы, поиск решения для некоей проблемы и т.п. В любом случае подобная работа начинается с предварительных исследования — поиск научных публикаций по смежным темам, предлагаются эксперименты и так далее. Постановка экспериментов — самая что ни на есть проектная работа. Особенно в тех случаях, когда требуется изготовить оборудование конкретно под эксперимент

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

Отсюда ясно, что хотя и работа проектная, продуктовые подходы типа скрама применять не факт что целесообразно.

P>>Чем больше неопределенности, тем хуже работает скрам.

L>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет.

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

В исследованиях ровно наоборот — часто бывает так, что не известно, ни решаема ли задача, ни каким путём, ни требования.