Здравствуйте, landerhigh, Вы писали:
P>>Про то и речь — исследования, эксперименты.
L>И "исседования" и "эксперименты" тоже требуют планирования и деления на задачи.
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, landerhigh, Вы писали:
P>>>Про то и речь — исследования, эксперименты.
L>>И "исседования" и "эксперименты" тоже требуют планирования и деления на задачи.
P>А можно на примере?
Ну вот, к примеру.
Есть библиотека X, реализующая протокол общения с некими внешними устройствами. Она делает то, что тебе надо, но у нее есть ограничение — экспоненциальный рост требований к памяти/процессору от количества обслуживаемых устройств. Ваша задача — выкатить продукт, который сможет на стандартном компьютере обслуживать сотни или даже тысячи устройств.
Вот так просто "пойду ресерч делать" — подход в корне неправильный. Нужно иметь хоть какой-то план действий, и если не план, то хотя бы означенное направление.
Первый спринт. Пока ничего не известно, но нужно же что-то делать.
Проводим анализ, это библиотека такая кривая или протокол настолько тяжелый, что задача нереализуема.
Создаем таски
1. Поиск альтернативных коммерческих или опенсорс решений
2. Анализ продукта А конкурента А на предмет ограничений.
3. Анализ продукта Б конкурента Б на предмет ограничений.
4. Изучение спеков протокола на предмет принципиальных ограничений.
В итоге, во-первых, тебе каждый день есть что сказать по конкретному таску. К концу спринта у тебя есть список из альтернативных платных библиотек, пары опенсорс библиотек, ты выяснил, что подддержка протокола в продукте А находится на зачаточном уровне, а продукт Б использует ту же библиотеку Х и в документации ограничения описаны на русском по-английски. Ты также прочитал спеки по диагонали и никаких очевидных ляпов там не увидел, плюс, из описания найденной платной библиотеки Y ты увидел, что требования по памяти на одно устройство крайне малы, и рост требований к памяти и процессорному времени от числа устройств — линейный. Плюс, у нее в комплекте поставляется симулятор.
Результат первого спринта:
1. Принципиальных ограничений для реализации проекта нет
2. Конкуретнов пока не наблюдается. Самое время занимать нишу.
3. Есть возможность провести эксперимент по масштабируемости
Для второго спринта уже можно спланировать подготовку более конкретного эксперимента, так же разбив его на осязаемые таски.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, CreatorCray, Вы писали:
_AB>>>Stand up — это банальная пятиминутка или летучка CC>>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
L>Ну вот у нас редко за 5-7 минут выходит.
если непонятно что-то или проблема то отдельно митинг делаете или остаетесь после митинга?
Здравствуйте, merge, Вы писали:
L>>Ну вот у нас редко за 5-7 минут выходит. M>если непонятно что-то или проблема то отдельно митинг делаете или остаетесь после митинга?
Скрам-летучка однозначно не для этого, нет ничего зазорного в том, чтобы пресечь отход в сторону, или поправить, если кто-то начинает зачитывать конспект вчерашних коммитов.
В итоге вырабатывается привычка "делал ХХХ, сегодня буду делать УУУ" или "делал KKK, наступил на грабли с MMM, не могу понять как решать"
Вот возникшие вопросы потом отдельно обсуждаем. Иногда имеет смысл сказать "всем спасибо, а мы сейчас с Петей и Васей будем обсуждать, что нам делать с MMM, у кого есть идеи — можете остаться".
L>Да, смена профессии. L>Скрам (или канбан) сейчас стандарт де-факто. Он неидеален, но все (что? Водопад? ) остальное еще хуже.
L>Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
а что делаете если поступает задача на рефактор типа убрать константы по проекту?
и непонятно в какой объем это выльется и без отдельной задачи на анализ проще сказать "2 недели займет"
M>а что делаете если поступает задача на рефактор типа убрать константы по проекту? M> и непонятно в какой объем это выльется и без отдельной задачи на анализ проще сказать "2 недели займет"
Здравствуйте, CreatorCray, Вы писали:
CC> Впрочем это в общем то повсеместно в местах с хреновыми манагерами.
С хреновыми менеджерами инженеры всегда уверены что митинги, в частности, стандапы, не важны, и вообще, обсуждёж итд. Что вобщем то логично — менеджер свою задачу не решил. Так часто бывает, когда менеджеры с сильным уклоном в технику.
Задача менеджера — сделать коммуникацию эффективной, следовательно, митинги — полезными.
Здравствуйте, landerhigh, Вы писали:
L>Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
последняя задача которую я делал
в инете три примера решения (искал все топики вокруг этих трех примеров) — один не работает и Intel пишет да мы знаем оно не работает ну зато код красивый
второй не работает и 10+ человек пытались исправить но не смогли (и я не смог исправить ошибку)
третий пример работает но делает не то что нужно
я напписал что задача займет две недели а делал 5 недель
Здравствуйте, sergey2b, Вы писали:
S>я напписал что задача займет две недели а делал 5 недель
Так это, собственно говоря, и не проблема. В нашей индустрии ожидается, что предсказывать сроки на проектах, реализация которых гарантированно занимает больше нескольких часов/дней, в общем случае бессмысленно.
Задача скрама состоит в том, чтобы помогать разработчикам (да, именно разработчикам) последовательно и итеративно убирать неопределенность.
Соответственно, когда разработчик говорит, "ну недели две", следует читать "да черт его знает, может и пару лет" и нужно садиться и идентифицировать достижимые цели и дробить на осязаемые задачи.
Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову.
Здравствуйте, sergey2b, Вы писали:
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Как-то подыгрывать.
Но мне было бы сложно, я бы отказался. Мне нужно войти в состояние потока, это не просто — может даже за целый день не войду. Если вошел — лучше меня не трогать несколько недель. Тогда результат будет.
Если же постоянно дергать — я просто не смогу работать и обсуждать будет тупо нечего.
Здравствуйте, landerhigh, Вы писали:
L>Ну вот, к примеру. L>Есть библиотека X, реализующая протокол общения с некими внешними устройствами. Она делает то, что тебе надо, но у нее есть ограничение — экспоненциальный рост требований к памяти/процессору от количества обслуживаемых устройств. Ваша задача — выкатить продукт, который сможет на стандартном компьютере обслуживать сотни или даже тысячи устройств.
L>Вот так просто "пойду ресерч делать" — подход в корне неправильный. Нужно иметь хоть какой-то план действий, и если не план, то хотя бы означенное направление.
L>Первый спринт. Пока ничего не известно, но нужно же что-то делать. L>Проводим анализ, это библиотека такая кривая или протокол настолько тяжелый, что задача нереализуема. L>Создаем таски L>1. Поиск альтернативных коммерческих или опенсорс решений L>2. Анализ продукта А конкурента А на предмет ограничений. L>3. Анализ продукта Б конкурента Б на предмет ограничений. L>4. Изучение спеков протокола на предмет принципиальных ограничений.
L>В итоге, во-первых, тебе каждый день есть что сказать по конкретному таску. К концу спринта у тебя есть список из альтернативных платных библиотек, пары опенсорс библиотек, ты выяснил, что подддержка протокола в продукте А находится на зачаточном уровне, а продукт Б использует ту же библиотеку Х и в документации ограничения описаны на русском по-английски. Ты также прочитал спеки по диагонали и никаких очевидных ляпов там не увидел, плюс, из описания найденной платной библиотеки Y ты увидел, что требования по памяти на одно устройство крайне малы, и рост требований к памяти и процессорному времени от числа устройств — линейный. Плюс, у нее в комплекте поставляется симулятор.
L>Результат первого спринта: L>1. Принципиальных ограничений для реализации проекта нет L>2. Конкуретнов пока не наблюдается. Самое время занимать нишу. L>3. Есть возможность провести эксперимент по масштабируемости
L>Для второго спринта уже можно спланировать подготовку более конкретного эксперимента, так же разбив его на осязаемые таски.
Странно, видел пару раз планирование в таком бравом ключе на начальном этапе проектов
с TTM~=5лет и количеством участников ~=10 человек.
И оба раза через пару-тройку лет выяснялось, что такой ресеч оказывался фатально ложным
из-за того что правильное решение было вне этих 'очевидных' пунктов.
В другой паре-тройке случаев с тем же ТТМ и количеством народа, когда находили некоего
толкового Васю, и говорили пусть Вася подумает вначале сам, затем задачу побьет, и еще
если в добавок Васе нормальных денег платили, то получалась конфетка, до сих пор они
продаются.
Хотя конечно, когда конфетка уже продается, а Вася грезит следующими заоблачными
достижениями, то обычно акционеры решают для энтереса нанять дешевых исполнителей
со всеми скрам-мастерами и посмотреть, что получится. Вот просто тяга у них к этому
какая-то наблюдается, но тут ничего не попишешь.
Здравствуйте, no_ise, Вы писали:
_>И оба раза через пару-тройку лет выяснялось, что такой ресеч оказывался фатально ложным _>из-за того что правильное решение было вне этих 'очевидных' пунктов.
И такое бывает.
_>В другой паре-тройке случаев с тем же ТТМ и количеством народа, когда находили некоего _>толкового Васю, и говорили пусть Вася подумает вначале сам, затем задачу побьет, и еще _>если в добавок Васе нормальных денег платили, то получалась конфетка, до сих пор они _>продаются.
Сейчас уже прошли времена Вась, которые подумали и выдали шедевр.
А еще бывает, что без "фатально ложного ресерча" не нашлось бы и новое, более правильное решение.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, no_ise, Вы писали:
L>Сейчас уже прошли времена Вась, которые подумали и выдали шедевр.
Ну ведь и биткоин и Илья Суцкевер, и те же передовые OCR это ведь 'Васи',
все они в нашем времени.
В нашем времени развелось не-шедевров с шедевральным маркетингом, там конечно
'Васи' не нужны, а нужно бежать куда маркет показывает.
L>А еще бывает, что без "фатально ложного ресерча" не нашлось бы и новое, более правильное решение.
Согласен, бывает.
L>Не бывает серебряных пуль.
И я о том же. Но бывают люди которые и стеклянными оловянными деревянными могут задачу выполнить.
Здравствуйте, landerhigh, Вы писали:
L>Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову.
Скрам плохо подходит для исследований или багфикса.
Между тем, что Вася может за пару недель на коленке нашедеврить, до работающего продукта нынче — огромная пропасть. Просто в силу обстоятельств.
Речь идет не о самородках, которые выдают гениальные идеи, и которые в основном закончились в 90-е, а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета.
Здравствуйте, Kernan, Вы писали:
L>>Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову. K>Скрам плохо подходит для исследований
Как раз для исседований он прекрасно подходит.
K>или багфикса.
Здравствуйте, CreatorCray, Вы писали:
CC>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
Ну, это проблемы компаний, в которых ты работал.
CC>А на деле каждый что то бурчит для отмазки и тут же отвлекается продолжать делать что то своё, слушая в полуха.
Если на полчаса растягивать, то конечно.
CC>А все проблемы решаются путём прихода к правильным людям и взятием их за пуговицу, чтоб не сбежали.
Пятиминутки и не призваны решать проблемы. Они призваны запланировать необходимые действия для решения проблем. У вас они затягиваются потому, что вы тупо не понимаете их смысл и цель.
Здравствуйте, Kernan, Вы писали:
K>Скрам плохо подходит для исследований
Э-э-э... Куда лучше водопада, скажем так.
K>или багфикса.
Основная проблема в том, что багфикс в принципе — не проектная деятельность, а операционная. Поэтому любая методология управления проектами плохо для неё подходит. Да, багфиксингом приходится заниматься и в ходе реализации проекта, разумеется, но тут скрам ничем не хуже других моделей, даже, возможно, получше.
А если проект уже сдан в эксплуатацию и команда перешла в режим операционной деятельности (поддержки продукта, если нашим языком), то применять для неё систему управления проектами просто глупо. Тут, как подсказывает landerhigh, куда удобнее системы управления операционной деятельностью — тот же канбан, например.
Разумеется, жизнь в конторе, разрабатывающей продукты, куда сложнее. Есть текущая версия в операционном режиме поддержки, есть разработка новых фич, которая в проектном режиме идёт. И всё это внутри одной команды зачастую. Это очень осложняет ситуацию. Тем не менее, необходимо понимать разную природу проектной и операционной деятельности и не пытаться решать проблемы одной методами другой.
Я, кстати, тоже пытался впендюрить в скрам багфиксинг хоть как-то и считал этот аспект признаком полной отрованности скрама от жизни. Пока не понял для себя эту разницу. Хреново только, что ответа в чистом виде я не находил ни в англоязычном, ни в русскоязычном сегменте. Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта. Пришлось доходить своим умом, а он у меня не блестящий и менеджер я хреновый, так что дошло только совсем недавно. Вышестоящие менеджеры, так уж исторически сложилось, все из консультантов, не разработчиков, тоже подсказать не могли. На всяких курсах по управлению проектами и во всяких книгах я тоже, почему-то, этого не видел. Может мимо проходило, а может и нет там этого в явном виде.
Здравствуйте, Pauel, Вы писали:
P>Вероятно, это ты себе такое окружение выбрал.
Угу, практически все задачи немаленького размера, DRI, Feature owner. В двух словах как правило не рассказать.
P>Телепат? Предполагаю, это ты сам так поступаешь.
Ну видно жеж как народ в лапотопы/телефоны обратно утыкается и начинает что нить активно тайпать и тебе мессаги от них приходят.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
) остальное еще хуже.
