S>где мои коллеги бодро рапортую о запилинных за 24 часа фичах или исправленных багах S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up
S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды
Здравствуйте, Pauel, Вы писали:
P>Здравствуйте, landerhigh, Вы писали:
P>>>Про то и речь — исследования, эксперименты.
L>>И "исседования" и "эксперименты" тоже требуют планирования и деления на задачи.
P>А можно на примере?
Ну вот, к примеру.
Есть библиотека X, реализующая протокол общения с некими внешними устройствами. Она делает то, что тебе надо, но у нее есть ограничение — экспоненциальный рост требований к памяти/процессору от количества обслуживаемых устройств. Ваша задача — выкатить продукт, который сможет на стандартном компьютере обслуживать сотни или даже тысячи устройств.
Вот так просто "пойду ресерч делать" — подход в корне неправильный. Нужно иметь хоть какой-то план действий, и если не план, то хотя бы означенное направление.
Первый спринт. Пока ничего не известно, но нужно же что-то делать.
Проводим анализ, это библиотека такая кривая или протокол настолько тяжелый, что задача нереализуема.
Создаем таски
1. Поиск альтернативных коммерческих или опенсорс решений
2. Анализ продукта А конкурента А на предмет ограничений.
3. Анализ продукта Б конкурента Б на предмет ограничений.
4. Изучение спеков протокола на предмет принципиальных ограничений.
В итоге, во-первых, тебе каждый день есть что сказать по конкретному таску. К концу спринта у тебя есть список из альтернативных платных библиотек, пары опенсорс библиотек, ты выяснил, что подддержка протокола в продукте А находится на зачаточном уровне, а продукт Б использует ту же библиотеку Х и в документации ограничения описаны на русском по-английски. Ты также прочитал спеки по диагонали и никаких очевидных ляпов там не увидел, плюс, из описания найденной платной библиотеки Y ты увидел, что требования по памяти на одно устройство крайне малы, и рост требований к памяти и процессорному времени от числа устройств — линейный. Плюс, у нее в комплекте поставляется симулятор.
Результат первого спринта:
1. Принципиальных ограничений для реализации проекта нет
2. Конкуретнов пока не наблюдается. Самое время занимать нишу.
3. Есть возможность провести эксперимент по масштабируемости
Для второго спринта уже можно спланировать подготовку более конкретного эксперимента, так же разбив его на осязаемые таски.
Здравствуйте, merge, Вы писали:
L>>Ну вот у нас редко за 5-7 минут выходит. M>если непонятно что-то или проблема то отдельно митинг делаете или остаетесь после митинга?
Скрам-летучка однозначно не для этого, нет ничего зазорного в том, чтобы пресечь отход в сторону, или поправить, если кто-то начинает зачитывать конспект вчерашних коммитов.
В итоге вырабатывается привычка "делал ХХХ, сегодня буду делать УУУ" или "делал KKK, наступил на грабли с MMM, не могу понять как решать"
Вот возникшие вопросы потом отдельно обсуждаем. Иногда имеет смысл сказать "всем спасибо, а мы сейчас с Петей и Васей будем обсуждать, что нам делать с MMM, у кого есть идеи — можете остаться".
Здравствуйте, CreatorCray, Вы писали:
CC>Stand up — одна из реально бесполезных менеджерских ужимок.
Stand up — это банальная пятиминутка или летучка, существовавшая долгие и долгие годы, если не столетия, до изобретения любых agile.
CC>Если уж приходится в этом участвовать то лучше хоть с пользой для себя.
Для тебя польза — понять, что делают остальные и озвучить любые свои проблемы, если они есть. Решать их надо отдельно.
Здравствуйте, Pauel, Вы писали:
S>>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика
P>То есть, когда у нас есть некоторая свобода в требованиях, они меняются, но реализацию можно или растянуть во времени, или переформулировать требования. P>То есть, минимальная неопределенность. Максимум, что мы себе можем позволить — нагуглить либу, написать poc на фичу, посчитать вычислительную сложность итд. Вроде бы тоже ресёрч, но ооочень маленький.
Мое впечатление от Agile (по крайней мере от SCRUM и Kanban, т.к. по ним информации больше, тогда как Crystal зверь более редкий и малоизученный) заключается в том, что Agile это отличный компромисс по защите интересов и тех, и других:
— проектная команда защищается от внезапных вбросов от заказчика. Типа "мы же согласовали скоуп спринта, если у вас что-то появилось или что-то отвалилось, то все это учтем на будущий спринт, а пока подождите и дайте нам завершить текущий спринт". Сейчас это звучит дико, наверное, но еще лет 10-12 назад отшить заказчика, который внезапно примчался с криками "бросаем все, мне вот это нужно уже прям вчера", было сложно и требовало железных яиц у ключевых людей на стороне проектной команды (в том числе и у владельцев конторы, в которой проектная команда трудится, если заказчик внешний). Теперь же есть принятые многими правила игры: мол, все согласились, что работаем по SCRUM-у, поэтому никто в уже согласованный скоуп спринта ничего насильно не впихивает. Как я понимаю, ограничение на длину спринта и рекомендация иметь небольшие спринты (две недели) как раз отсюда и происходит: до разумных пределов сокращается лаг по реакции на изменяющиеся условия;
— заказчик защищается от того, что проектная команда занимается какой-то неведомой деятельностью, последствия которой не очевидны и непонятно на что же тратятся кровные деньги заказчика. Нет такого, что команда ушла в подполье на 2 месяца для сбора и анализа требований, по истечению которого получается какой-то фолиант на 100500 страниц с описаниями всякого разного, что нужно вкуривать еще несколько недель. После чего команда опять исчезает на написание пояснительной записки к проекту, результатом чего будет еще один фолиант на 100500 страниц. А при необходимости среагировать на какие-то входящие изменения (типа новой фичи в продукте основного конкурента или изменениями в требованиях от регулятора) приходится переписывать часть этих фолиантов. И т.д., и т.п. Вместо этого идет итерационный процесс выдачи конкретных результатов заказчику, сперва от примитивных и минималистичных PoC и MVP, до постепенного превращения PoC/MVP в полноценный продукт за счет инкрементального наращивания возможностей. Т.е. благодаря относительно коротким итерациям заказчик постоянно видит на что уходят его деньги.
При этом (с моей колокольни глядя) Agile отлично работает в проектах, когда общий скоуп более-менее понятен изначально и есть постоянный поток хотелок, которые можно резать на небольшие кусочки, дабы эти кусочки были реализуемы в рамках спринтов. Отличную демонстрацию этого желающие могут сейчас наблюдать в процессе эволюции сервиса deepl.com: за пару лет на моих глазах он превращается из примитивной демки по возможностям новой разработки в области машинного перевода в полноценный сервис, который конкурирует и с Google.Translate, и с Grammarly. Постепенно в него добавляются и новые фичи (переводы документов, выбор из разных вариантов перевода, и нативные приложения, чтобы Web-интерфейсом не пользоваться), и новый подход к работе с пользователями (подписки с разными планами и прием платежей). Вот все это, имхо, отлично ложится на SCRUM/Kanban.
Еще один (потенциально возможный) пример: разработка компилятора для языка программирования по спецификации языка. Вот тот же C++ если взять: есть зафиксированный стандарт (C++20, к примеру), к нему должен появится компилятор. Вполне себе понятный скоуп работ, который можно оценить и разрезать на отдельные шаги (спринты). Возможно, по каким-то направлениям нужно провести исследования (скажем, как можно минимизировать динамические аллокации при создании короутин). Но это будут исследования на предмет "как лучше", а не "можно ли вообще что-то хорошее получить".
Тогда как в рамках приведенных выше примеров есть задачи, которые на SCRUM/Kanban (а может и вообще на Agile) ложатся не очень хорошо.
Вот то же самое ядро машинного перевода. Кто-то должен был озадачится тем, чтобы попытаться создать ядро, которое будет эффективнее (т.е. и дешевле в эксплуатации, и с более качественными результатами), чем существующие у того же Google. Возможно, в этой области куча готовых исследований, но ведь одно дело -- это теоретические выкладки, другое дело работающий программный продукт. Далеко не всегда можно взять голую теорию и сходу получить искомый программный продукт. А если еще и теория недостаточно прокачана и нужно делать какой-то прорыв в области тех же нейросетей...
Или стандарт языка C++. Он же формируется из предложений, а предложение кому-то нужно родить. Потом довести до ума. Потом пройти через согласования. Возможно, выдержать несколько ревизий. Чтобы потом быть отвергнутым. Как это было с большим куском работы над концептами в рамках C++11, которые были выброшены, а вошли концепты, в видоизмененном состоянии в C++20. Или как это было с контрактами, которые хотели включить в C++20, но которые (емнип) не попали даже в C++23. Или как это происходит с Concurrency TS и Networking TS.
Тут даже в рамках 3-х летнего цикла работы над стандартом скоуп очередного стандарта более-менее точно заранее сформировать не могут. А работы над предложениями имеют спорадический характер.
Помещать это все в рамки жесткой методологии (вроде SCRUM), заточенный под частое удовлетворение клиента мелкими релизами... Ну не знают, выглядит как такое себе.
Отсюда и интерес к теме использования SCRUM в исследовательских проектах. Но, сложилось у меня ощущение, что отметившиеся здесь евангелисты SCRUM сами над исследовательскими проектами по SCRUM и не работали. Либо подразумевали под "исследовательскими проектами" что-то свое.
в том смысле, что внимательно слушай, что отвечают популярные амбициозные коллеги, которые нравятся начальнику, и учись эмулировать их ответы.
Спрашивать на форуме советских кибернетиков-пенсионеровпрограммистов из другой культуры, это конечно идея, но живой пример правильного поведения, скорее всего, ходит у тебя прямо под носом.
CC>А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Это не командная разработка, а одиночная (silo-ed).
Скрам и подобия предназначены для командной работы, где предполагается, что упавшее знамя нужно подобрать немедленно, и тут же понести (другим членом команды).
Применять скрам в одиночно-индивидуальной разработке (когда нет постоянных команд, есть лишь проектные группировки) смысла не имеет.
Здравствуйте, sergey2b, Вы писали: S>у нас например за каждую выполненную задачу начисляют баллы S>каждая команда набравшая меньше 50 баллов получает всенародное порецание на собрании команд Северной Америки
Да это известный прикол всяких скрамов — они мотивируют браться только за предсказуемые простые задачи. Все что требует вдумчивого решения навсегда тонет в бэклоге. В общемто каждая нормальная нерешенная задача требует постоянной поддержки то есть потока тех самых простых задач, что радует хомячков
Когда ты уже перестанешь поступать как в том анекдоте "Что,вот так вот просто взять и уйти из авиации?"
Впрочем это риторический вопрос и ты опять скажешь что мол злопыхатели злопыхают.
Здравствуйте, CreatorCray, Вы писали:
CC> Впрочем это в общем то повсеместно в местах с хреновыми манагерами.
С хреновыми менеджерами инженеры всегда уверены что митинги, в частности, стандапы, не важны, и вообще, обсуждёж итд. Что вобщем то логично — менеджер свою задачу не решил. Так часто бывает, когда менеджеры с сильным уклоном в технику.
Задача менеджера — сделать коммуникацию эффективной, следовательно, митинги — полезными.
Здравствуйте, sergey2b, Вы писали:
S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре
Почему сразу "вынужден"? Я в таких ситуациях красочно рассказываю, с какими проблемами столкнулся, вовлекаю коллег в дискуссию по поводу способов решения этих проблем, в следующий раз рассказываю, сколько героических усилий мне понадобилось, чтобы проверить предыдущие, предложенные коллегами, гипотезы, как и почему это ни к чему не привело, и тд, и тп.
S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
Это есть немного, да, но я начал привыкать справляться с этим
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
S>у нас каждле утро в 8:30 или 10 утра проводят stand up
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
радикально понизить роль Стэндапов в структуре ценностей индустрии
как и вообще scrum — убогий с точки зрения чистой разработки стиль
у меня (дело было в Luxoft) был случай, когда менеджер проекта (он же скрам мастер) опаздывал на митинг
возник спонтанный трёп, в ходе которого я случайным образом завладел вниманием толпы, перевёл тему в химию, химию цементов, и в итоге прочитал всем типа минилекцию про ~технологию заливки бетона (преднапряжённого)
к её концу заканчивалось и время митинга, и я сказал "ну время митинга закончилось, я пошёл работать"
уверен, что для проекта такая подмена темы митинга ничего не поменяла
ещё и народ поржал как у нас получился стэндап про бетон — то есть плюс мораль
Здравствуйте, sergey2b, Вы писали:
S>я напписал что задача займет две недели а делал 5 недель
Так это, собственно говоря, и не проблема. В нашей индустрии ожидается, что предсказывать сроки на проектах, реализация которых гарантированно занимает больше нескольких часов/дней, в общем случае бессмысленно.
Задача скрама состоит в том, чтобы помогать разработчикам (да, именно разработчикам) последовательно и итеративно убирать неопределенность.
Соответственно, когда разработчик говорит, "ну недели две", следует читать "да черт его знает, может и пару лет" и нужно садиться и идентифицировать достижимые цели и дробить на осязаемые задачи.
Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову.
P>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Такова разработка любого продукта, кроме совсем уж тривиальных.
Я в третий (и последний) раз повторяю: когда вы проходите этот процесс в десятый раз (на 11м спринте), у вас уже накоплено столько статистики, что вы В СРЕДНЕМ знакте, сколько этих фейлов произойдет, и как долго их исправляь. ПОДЧЕРКИВАЮ: В СРЕДНЕМ!!! Да, в каждый конкретный спринт вы можете выполнить "лишнюю" таску, а можете провалить спринт, не доделав ожидаемую (хотя в этом случае вам должны помочь другие члены команды, которые, В СРЕДНЕМ, уже освободились от их собственных задач на спринт).
P>Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Да, накрылся! И первые 7-8 спринтов это будет происходить чуть менее чем всегда. Система начинает работать тогда, когда вы уже накопили статистику, и опыт в оценке задач. Я не знаю, сколько раз нужно еще это повторить, чтобы вы поняли.
P>В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
Задача скрам — ограничить потери. Если в середине проекта стало ясно, что вы не уложитесь в бюджет (по времени или деньгам), можно либо свернуть проект, либо убрать фичи, либо добавить людей, либо исправить сроки. Суть процесса — в существовании этой накопленной статистики. Это точно работает, и потому столь нелюбимо многими любителями "покопаться годик в прикольных кишочках ресерч-проекта". Оно для бизнеса, а не для хобби.
K>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Нет. Выше landerhigh уже правильно объяснил — стори поинт — это "самая маленькая законченная фича в проекте".
Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться.
у нас каждле утро в 8:30 или 10 утра проводят stand up
где мои коллеги бодро рапортую о запилинных за 24 часа фичах или исправленных багах
у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up
я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре
из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Здравствуйте, sergey2b, Вы писали:
S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up
Если время "в среднем" отличается в 12 раз, то это очень странное "среднее"...
S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре
И?
S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
Ну, разбей свою задачу на подзадачи, если в этом "видимый прогресс" заключается.
И будешь рапортовать о закрытии хоть пятнадцати задач в день, если в этом заключается самоцель вашей команды.
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
В чём конкретно заключается проблема-то?
Сядь с тим лидом и владельцем продукта, да расскажи о своих горестях, пусть советуют.
Если твои исследования и эксперименты важны для продукта, они решат твою проблему.
А если нет — то пусть дадут задачи, которые важны.
Здравствуйте, _ABC_, Вы писали:
_AB>Только это не stand up.
Stand up — одна из реально бесполезных менеджерских ужимок.
Если уж приходится в этом участвовать то лучше хоть с пользой для себя.
Здравствуйте, Codealot, Вы писали:
L>>Может, в иной вселенной и ложная. В нашей дело обстоит именно так. C>Пардон, но это просто чушь. Никто тебе не запрещает делать разработку поэтапно
Да, даже целая методология разработки, основанная на коротких этапах, есть. Угадаешь, как называется?
C>и ничего не планировать. Ну, кроме религиозных соображений.
Если Ничего не планировать, то получится примерно Ничего.
C>На самом деле, пытаться все планировать — это характерная черта именно водопадной модели, а не ее противоположность.
На самом деле, пытаться рассуждать на темы, о которых имеешь очень отдаленное представление, это характерная черта кывта
Здравствуйте, sergey2b, Вы писали:
S>у нас например за каждую выполненную задачу начисляют баллы S>каждая команда набравшая меньше 50 баллов получает всенародное порецание на собрании команд Северной Америки
О, это ж классика "как разогнать всех толковых людей".
S>а затемо стал каждый день тупо готовиться к собеседованиям
И правильно сделал
Здравствуйте, sergey2b, Вы писали:
S>у нас каждле утро в 8:30 или 10 утра проводят stand up
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Обсудить это с менеджером, предложить ежедневные стендапы сделать еженедельными или раз в две недели. Если люди хотят продолжать собираться каждый день (может у них кранч тайм и надо каждый день синхронизироваться), то ходить на стендап раз в неделю или две, а остальные отклонить.
P>Вот это и требует бОльшей гибкости, а не просто выдавание результата спринтами. Пока основной эксперимент не закончен, у вас вообще никакого результата нет.
Результат есть. И выдаете вы его ровно теми же спринтами.
Надо просто понимать, что именно за результат вы ждете. В данном случае вы ждете результат "проверка гипотезы ХХ". Да, гипотеза может оказаться неверной — и это тоже РЕЗУЛЬТАТ. Который вы все равно заносите в лог работ и т.п..
Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. Все эти "магические процедуры" — банальная телеметрия, для понимания, что сколько стоит. Проработав так год-другой, приличная лаборатория уже знает, сколько будет стоить проверка очередной гипотезы (вне зависимости от результата).
Скрам для такой работы вполне подходит. Знаю по собственному опыту. Просто нужно понимать, что результат — это не условный "успех запуска ракеты в космос", а более простые и приземленные цели. Разбитые на те самые задачи поменьше.
P>Еще раз — я говорю об исследованиях, а не продуктовых проектах. То есть — R&D, а не абы что вида "нагуглил либу и пример кода"
Сколько лет вы в индустрии, сколько уже видели разных проектов, как исследовательских, так и "продуктовых"? (отмечу, что "продуктовых" проектов не существует, если только речь не идет о типовых интернет-магазинах, которые здесь не обсуждаются).
P>Вы мне талдычите как у вас хорошо было на продуктах. Можете себя не утруждать — это я и без вас знаю.
Нет, я вам объясняю, что исследования тоже можно структурировать. И что по исследованиям тоже накоплена статистика. Каждый конкретный раз каждое конкретное исследование будет отличаться от предыдущих. Поэтому конкретный спринт будет отличаться от предыдущий.
Но на длинной дистанции все будет отлично видно.
P>Цель исследования — получить новое знание. P>Отсюда ясно, что измеряемость результата в одном случае есть, в другом — нет. Сами догадатесь, где измерямости результата нет?
Вот мы и дошли до сути разногласий: вы считает, что измерить результат исследований нельзя. Я считаю, что можно. Более того, если речь не о попиле бабла, первым, что должно оговариваться при старте очередной задачи/проекта/исследования — определение, что считать результатом, и как это измерить.
Скажем, "проверка гипотезы, что применение вот такой-то модели позволяет различить такой-то fraud от такого-то", — это очень даже результат.
P>И планирование делается совершенно разными методами. В исследовании — процесс, операционная деятельность. Попытки планировать это проектными методами дают тупик.
Вы это утверждаете, так и не попробовав. Я тоже так утверждал (до того, как попробовал). На осознание, что метод таки работает, у меня ушло некоторое время. Хоть я и скептически относился с самого начала.
P>Собственно в начале проекта у вас всё очень похоже на исследование, и именно поэтому скрам не работает. Вот дальше, когда неопределенность устранена, всё идет пучком.
Вообще-то, в середине проекта он был pivoted на совсем другие рельсы, так что неопределенность подпрыгнула до потолка. Собственно, и сам pivot случился потому, что стало ясно — с нынешней velocity мы ну никак не доберемся до feature complete к ожидаемой дате. Скрам вам не создаст определенность, его задача — примерно как у телеметрии (counters): записать реальную статистику, и на основе этой статистики прогнозировать.
Здравствуйте, Pauel, Вы писали:
P>Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев P>Почему ресёрч похож на опрационную деятельность — уже показал
Честно говоря, я не убеждён, что ресёрч похож на операционную деятельность. Я, конечно, не настоящий сварщик, но в моём понимании исследование имеет цель (причём цель — это получить новое, неизвестное), имеет сроки, имеет бюджет. Другими словами — это проект ну просто тупо и буквально по определению слова "проект".
Понятно, что в рамках реализации проекта или исследования, часть работы — это текучка. Но отслеживать, что проект движется в правильном направлении (и что это направление при текущих ограничениях вообще достижимо), что бюджет ещё есть, что сроки ещё не завалены, всё равно надо. И agile методологии управления проектами здесь лучше других именно из-за того, что они куда лучше справляются с размытыми требованиями и неизвестными путями решения задачи. Канбан же не является метдологией управления проектом и поэтому не может в принципе подходить лучше или хуже того же скрама. ИМХО.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, Pauel, Вы писали:
P>>Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев P>>Почему ресёрч похож на опрационную деятельность — уже показал _AB>Честно говоря, я не убеждён, что ресёрч похож на операционную деятельность. Я, конечно, не настоящий сварщик, но в моём понимании исследование имеет цель (причём цель — это получить новое, неизвестное), имеет сроки, имеет бюджет. Другими словами — это проект ну просто тупо и буквально по определению слова "проект".
Совершенно верно.
Любое исследование, особенно прикладное, делится на этапы. Этапы натурально будут состоять из последовательных и параллельные задач.
К примеру, по итогам предыдущего спринта выяснилось, что в hotpath есть некий алгоритм O(N^2) (ну, ладно, я сегодня добрый, пусть будет всего лишь O(N*M) ), который в общем виде не упрощается. Это не deal breaker, но у нас всего лишь четвертый спринт, а сложность имеет дурацкое свойство накапливаться, и было бы неплохо алгоритм улучшить, если можно. Команда собирается на мозговой штурм, выносятся предложения/предположения:
1. Заменить неким более быстрым, но аппроксимированным алгоритмом
2. Выяснить, нельзя ли ограничить домен входных данных и вычислять/кешировать результат, чтобы потом его использовать с O(1)
3. Вася утверждает, что можно вообще по большому счету забить на сложность этого алгоритма. Этот параметр никому прямо сразу не нужен, поэтому его можно в офлайне как-нибудь потом, в отдельном треде, а то и вовсе в отдельном процессе по ночам. Странный он, этот Вася.
Команда Васю решила проигнорировать, поэтому на следующий спринт планирует работу над пунтками 1 и 2. А для того, чтобы над ними работать, нужно для начала собрать статистику по входным данным M и N. Вася настоял на включении таска "анализ use cases" данного вычисляемого параметра.
В итоге в новом спринте — несколько тасков из беклога плюс еще парочка "сбор статистики" и "анализ use cases".
И пока Петя собирает статистику, Вася смотрит, как предполагается дальнейшее использование значений этого параметра.
К середине спринта Петя тихонечко зовет Васю в сторонку и говорит, что разброс значений N такой, что кеширование однозначно отвалится сразу. Ограничить по M теоретически можно, поскольку в 99% случаев оно будет не более 10, но мы обязаны поддерживать и все остальные возможные значения, которые могут достигать очень больших значений.
А Вася говорит, что пообщался с product owner и выяснил, что для непосредственного функционирования логики системы этот параметр никогда использоваться не будет. Пользователю же видеть эти значения в realtime тоже смысла нет. Он должен присутствовать в выдаче данных за день/месяц/год для подсчета статистики. А еще Вася посмотрел на беклог и обнаружил, что в следующих спринтах нам придется добваить вычисление кучи других параметров, которые не обязательно будут O(e^N), но могут включать в себя поиск во внешних БД или вызов внешних API, некоторые из которых используют голубиную почту в качестве транспорта. Поэтому решение с выгрузкой тяжелых вычислений за пределы hotpath, возможно, не просто будет одним из возможных, а единственно верным для успеха проекта.
По итогам этого спринта команда принимает предложение Васи. Его хлопают по плечу, берут автографы, целуют в десна. В проект добавляется новый epic "Вычисления в фоновом режиме".
Вот это — слегка модифицированный (имена изменены) пример прикладного исселедования из жизни. Удалось ли решить задачу "улучшения алгоритма"? Нет. Удалось ли решить эту задачу с точки зрения успеха проекта? Более чем.
Здравствуйте, sergey2b, Вы писали:
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Да, смена профессии.
Скрам (или канбан) сейчас стандарт де-факто. Он неидеален, но все (что? Водопад? ) остальное еще хуже.
Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы,
Вполне норм
S>узнад на что влияет параметр XYZ в структуре
Всем насрать.
S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
А вот чтобы был видимый прогресс (или видимость прогресса, хотя в случае исследовательской задачи отсутствие прогресса — тоже своего рода прогресс) и следует дробить задачу. Даже если изначально получаются выглядящие глупостями таски вроде "выявление основных проблем и рисков", "поиск решений для похожих проблем в этих ваших интерентах". Чем дальше в проект, тем более осмысленными и четкими станут задачи, и в какой-то момент твои таски начнут "воровать" (в смысле, захотят реализовать) другие участники команды.
Здравствуйте, _ABC_, Вы писали:
CC>>Stand up — одна из реально бесполезных менеджерских ужимок. _AB>Stand up — это банальная пятиминутка или летучка
Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
CC>>Если уж приходится в этом участвовать то лучше хоть с пользой для себя. _AB>Для тебя польза — понять, что делают остальные и озвучить любые свои проблемы, если они есть. Решать их надо отдельно.
А на деле каждый что то бурчит для отмазки и тут же отвлекается продолжать делать что то своё, слушая в полуха.
А все проблемы решаются путём прихода к правильным людям и взятием их за пуговицу, чтоб не сбежали.
В лучшем случае озвучат какую нить свежую проблему чтоб другие не вступили.
Потому как один фиг времени хватает каждому что то пробурчать, если начинается обсуждёж то это один фиг надолго да и непричастные всё равно тупо отвалятся ибо работы хватает.
Здравствуйте, sergey2b, Вы писали:
S>где мои коллеги бодро рапортую о запилинных за 24 часа фичах или исправленных багах S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up
S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Смени деятельность, будь каа радостные коллеги. Но тебе же нравится ковыряться в C++- тогда не жалуйся.
Здравствуйте, CreatorCray, Вы писали:
L>>Это уже много CC>Эта фигня как то работает если есть небольшая кучка долбоклюев, которой раздали ключи, назначили гайки, и они их крутят. CC>А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Да, и в конце этих пары лет выясняется, что фича либо не нужна, либо нужна, но совсем другая, либо она "почти работает" и нужно "всего" еще два года.
Чаще всего все вместе и одновременно.
Здравствуйте, Codealot, Вы писали:
C>Не позволят, потому что обычно самые большие риски идут в конце, и ты скорее всего "успешно сделаешь" две трети задач, прежде чем вляпаться в непреодолимую проблему. C>Попытки все спланировать только приводят к потере времени на собственно планирование и попытки следовать плану, и создают ложное чувство контроля, что еще хуже. Потому что самые опасные риски — это те, наличие которых ты не осознаешь.
где же, где же, где же она, эта оценка "фейспалм"?
Здравствуйте, CreatorCray, Вы писали:
L>>Ну тогда скоро не будет и на квартал. А потом и на год. L>>Примерно так загнивание выглядит. CC>Сколько уже загниваем а всё никак.
Если ты в эпл, то они славятся кривым софтом чуть ли не везде.
Здравствуйте, SkyDance, Вы писали:
SD>Результат есть. И выдаете вы его ровно теми же спринтами. SD>Надо просто понимать, что именно за результат вы ждете. В данном случае вы ждете результат "проверка гипотезы ХХ". Да, гипотеза может оказаться неверной — и это тоже РЕЗУЛЬТАТ. Который вы все равно заносите в лог работ и т.п..
я думаю вы пишите как оно должно быть
у нас например за каждую выполненную задачу начисляют баллы
каждая команда набравшая меньше 50 баллов получает всенародное порецание на собрании команд Северной Америки
соотвественно на уровни команды, набрал меньше 5 балов за спринт получи свою порцию призрения
я вначале фрустировал, тк у меня больше исследовательские задачи за которе дают малло баллов и часто результат отрицательный
а затемо стал каждый день тупо готовиться к собеседованиям
Здравствуйте, Pauel, Вы писали:
P>В исследованиях у вас вообще всё непредсказуемо, а не только человеки. Разница с обычным продуктовым приложением в том, что в одном случае вы знаете более менее что класс задач более-менее решаем, и вам не надо заботиться о проверке большинства гипотез.
Разработка (именно разработка, а не клепка взрывом из фрейворков на node.js) софта — это именно исследовательская деятельность.
Как раз на этом и водопад с "сначала пишем исчерпывающие спеки, разбиваем на этапы" и пролетает в разработке софта.
Невозможно предсказать, как именно должна быть реализована функциональность А до того, как будет реализована функциональность Б и Ц. Более того, невозможно сказать, нужна ли вообще она будет (будет ли в ней смысл).
P>В исследованиях ровно наоборот — во первых, вы не знаете, а решаема ли задача, не знаете много чего другого. Соответственно, ваши планы будут ломаться довольно часто до тех пор, пока собственно не найдете ответ а решаема ли задача и каким путём.
И?
P>Собственно в этот период скрамовские итерации особого смысла не имеют, т.к. вам постоянно приходится менять планы прямо на ходу, т.к. они будут меняться.
Скрамовские итерации позволяют, помимо всего прочего, гибко адаптироваться к постоянно меняющимся платам.
__>В общемто каждая нормальная нерешенная задача требует постоянной поддержки то есть потока тех самых простых задач, что радует хомячков
я сейчас конкретный пример из жизни дам
работал я в одной известной конторе и там текучкой была починка тестовых конфигов. их правили одновременно каждодневно сотни людей для своих нужд, для прохождения своих тестов, что ломало тесты других. причем самая частая проблема — правили автогенеренный код.
рабочий день часто начинался с того, что создавался тикет на упавшие тесты, нужно было лезить туда, править некоторые файлы, перегенерировать что автогенерится и тестить и т.д. по кругу. я занимался этим несколько месяцев подряд. мартышкин труд.
просто запретить кому попало править тесты и любые файлы не вариант, так как это поставит работу колом. я за эти несколько месяцев посидел, подумал и понял, что на самом деле тесты надо реорганизовать, чтобы правки в одних тестах не ломали другие и вообще убрать нефиг эту систему автогенерации, потому что по факту нужды в ней нет.
на что я наткнулся в итоге при обсуждении подобного подхода?
— нафиг менять то, что уже работает, надо просто научиться фиксить быстрее
— пока ты будешь что-то там менять у нас тут тесты поломанные, которые надо быстро фиксить
— ты собрался переписывать неполоманные тесты? а зачем?
— зачем ты будешь переписывать поломанный тест, когда ты знаешь как его можно просто пофиксить?
ну и самое главное
— это не "гавно какое-то", а начальник за эту систему автогенерации получил промо в свое время и презентовал как супирпупир решение всех проблем, поэтому система тут с нами навсегда
а поэтому каждый день — список поломанных тестов и фперед фиксить-фиксть бистро-бистро
__>на самом деле цель системы — снизить порог входа, чтобы все люди были взаимозаменяемы и любой, условно, с дипломом, точно так же работал, как тот кто половину проекта сам написал за пять лет.
Это святой грааль менеджмента, "derisking".
Но вот чего менеджмент обычно не понимает, так это последствий такого "снижения порога". На самом деле происходит не снижение порога, а потеря эффективности работы опытных людей. Иными словами, не новички начинают работать быстро, а опытные вынуждены замедлиться (потому что "долго компилируется", "медленно идут тесты", "slow rollout", "напиши вот эти бумаги" и все такое прочее).
Иногда, впрочем, менеджмент это понимает, и честно говорит, "нам пофиг, что эффективность намного ниже, зато мы говорим, что разработка теперь предсказуема, без колебаний производительности, и рисков, что уход сильных инженеров приведет к существенному замедлению работ". И потом, разумеется, менеджмент добавляет "но нам нужно больше людей". Подразумевая "моя зарплата должна вырасти". Ведь все дело в этом, а вовсе не в рисках или чем-то еще.
P>Исследование и проект это два различных рода деятельности, друг от друга никак не зависят. Как говорят "вещи ортогональные".
Спрошу еще раз: дайте определение термину "исследование". Желательно с позиций бизнеса, а не со стороны желающего эти исследования проводить.
P>Хотите — совмещайте проектное планирование с исследованием, получится исследовательский проект. Не хотите — не используйте, планируйте используя процессный подход.
Что такое "процессный подход?" Как в нем происходит планирование, как выделяется бюджет? Откуда, в конце концов, деньги-то берутся?!
P>Что характерно, вы всё время уходите от вопроса, как в этом случае применять скрам, т.е. для планирования той самой операционной деятельности.
Я уже четыре раза написал, и дал две ссылки на предыдущие сообщения по теме. Вы так и не удосужились их прочитать. Предполагаю, что и про скрам вы тоже краем уха слышали, но где звон, так и не узнали.
Здравствуйте, Kernan, Вы писали:
SD>>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time. K>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Это просто попугаи. Хрестоматийно — после разбиения проблемы на сторис (таски) полагается отранжировать таски по предполагаемым затратам (effort) для их реализации. А затем, самой легкой назначается 1 поинт или два, самой сложной — 10 (20, 40, 100500, неважно) и затем полагается играть в эстимейшен покер, используя эти таски как точки отсчета.
Задача не столько в том, чтобы оценить сложность каждой стори. А в том, чтобы создать конструктивную дискуссию. К пример, разногласие в оценке приводит к разговору, который по идее поможет команде увидеть, что стори, которая казалась довольно простой, на деле потребует намного больше усилий на реализацию.
Здравствуйте, landerhigh, Вы писали:
SD>>>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time. K>>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
L>Это просто попугаи.
У этих попугаев есть простой физический аналог навроде массы или работы, которую нужно затратить на перемещение массы на конкретное расстояние.
Это в официальном руководстве по SCRUM написано. Звиздун-собеседник, конечно же, мастерски может послать все это вдоль и наговорить массу умных слов в свое оправдание. Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
SD>Ни тот, ни другой не являются коммерческими продуктами.
Вы еще скажите, что на разработку Rust бюджеты не выделялись. Разработку Scala никто не спонсировал, Go/Dart в Google в свободное от работы время и за свой счет пилили и пилят, равно как Kotlin в JetBrains, да RedHat ничего своим сотрудникам не платил за Ceylon. Сплошной энтузиазм, ага
SD>Любые проекты на базе энтузиазма не рассматриваются бизнесом как проект.
А вы не только за "якобы" SCRUM, но еще и за бизнес можете позвиздеть? Ну сильны, чё.
По итогу: натрындели вы здесь много, но ничего конкретного не сказали: ни своего примера исследовательского проекта не привели, ни описали как же должно выглядеть применение SCRUM для исследовательских задач. Разве что общий звиздежь о том, что "все украдено до нас" и "идей вокруг полно".
Здравствуйте, sergey2b, Вы писали:
S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up
Если твои исследования важны для разработке, то в чём проблема? S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Хмм. Как вариант, делать презентации по исследованиям периодически рассказывая как работает это или то и зазывая туда всех вообще. Конечно, если результаты исследования важны для команды.
Только не рассказывай все секреты чтобы job security было.
Здравствуйте, Sharov, Вы писали:
S>Не силен в обоих, но правильно ли я понимаю, что scrum для проектной деятельности подходит, а kanban -- для операционной?
Хм... Как бы свою кашу в голове изложить понятно...
Канбан — он немного перпендикулярен управлению проектами. Канбан — он про выстраивание процессов. Поэтому он подходит очень хорошо для операционной деятельности, которая по определению представляет из себя совокупность повторяемых и регламентированных процессов. Однако, внутри проекта тоже есть свои процессы, причём повторяемые и даже регламентированные, поэтому для их выстраивания канбан тоже применим.
При этом канбан (в том виде, что знаю его я) — он не про управление проектом в том плане, что он не даёт инструментов для оценки того, приближаетесь ли вы к цели проекта, с какой скоростью, и когда у вас кончится бюджет, и/или сроки выполнения проекта. Про это и многое другое, необходимое для реализации проекта рассказывают водопады, скрамы и прочие методологии управления проектами.
S>Т.е. когда только реализуем систему, т.е. проектная деятельность, то scrum лучше, после релиза, поддержка S>жизненного цикла, т.е. операционная деятельность, kanban лучше?
Я бы выразился более обще. Во время разработки системы, во время проектной деятельности, лучше придерживаться хоть какой-нибудь методологии управления проектами (например, скрам), а после релиза проект закрывается, поэтому эти методологии не могут быть применены и подойдёт что-то, что помогает выстраивать процессы операционной деятельности (например, канбан).
M>а что делаете если поступает задача на рефактор типа убрать константы по проекту? M> и непонятно в какой объем это выльется и без отдельной задачи на анализ проще сказать "2 недели займет"
Здравствуйте, Kernan, Вы писали:
K>Скрам плохо подходит для исследований
Э-э-э... Куда лучше водопада, скажем так.
K>или багфикса.
Основная проблема в том, что багфикс в принципе — не проектная деятельность, а операционная. Поэтому любая методология управления проектами плохо для неё подходит. Да, багфиксингом приходится заниматься и в ходе реализации проекта, разумеется, но тут скрам ничем не хуже других моделей, даже, возможно, получше.
А если проект уже сдан в эксплуатацию и команда перешла в режим операционной деятельности (поддержки продукта, если нашим языком), то применять для неё систему управления проектами просто глупо. Тут, как подсказывает landerhigh, куда удобнее системы управления операционной деятельностью — тот же канбан, например.
Разумеется, жизнь в конторе, разрабатывающей продукты, куда сложнее. Есть текущая версия в операционном режиме поддержки, есть разработка новых фич, которая в проектном режиме идёт. И всё это внутри одной команды зачастую. Это очень осложняет ситуацию. Тем не менее, необходимо понимать разную природу проектной и операционной деятельности и не пытаться решать проблемы одной методами другой.
Я, кстати, тоже пытался впендюрить в скрам багфиксинг хоть как-то и считал этот аспект признаком полной отрованности скрама от жизни. Пока не понял для себя эту разницу. Хреново только, что ответа в чистом виде я не находил ни в англоязычном, ни в русскоязычном сегменте. Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта. Пришлось доходить своим умом, а он у меня не блестящий и менеджер я хреновый, так что дошло только совсем недавно. Вышестоящие менеджеры, так уж исторически сложилось, все из консультантов, не разработчиков, тоже подсказать не могли. На всяких курсах по управлению проектами и во всяких книгах я тоже, почему-то, этого не видел. Может мимо проходило, а может и нет там этого в явном виде.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, baxton_ulf, Вы писали:
_>>ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды CC>Как вариант кстати. CC>Но это похоже припарка, после того как там "вынудили удалить все что относиться к IDE", "редактировать в mc собирать make и отлаживать через логи". CC>Когда в культуре компании превозносится девиз "Стоя! В гамаке! И на лыжах!" то это нехороший знак это та из контор, где надо всем и всегда рассказывать как тебе было тяжко, как всё было плохо, но ты таки превозмог! Даже если речь шла про пойти отлить. Ибо там работу будут оценивать не по тому, как ты её быстро и хорошо сделал, а по тому, как ты рассказывал как ты устал превозмогая. Впрочем это в общем то повсеместно в местах с хреновыми манагерами.
я про такое уже забыл. как перестал в российских говноконторках работать, так прям не нарадуюсь. жалею, что раньше не ушёл в фаанги всякие.
такие конторки, где Серега все время работает, я знаю — туда всегда легко попасть. потому что народ от туда бежит теряя тапки. туда можно пойти, если совсем прижало, но зависать там точно не надо.
ПС: я со скрамом столкнулся когда стал на амазон работать. вот там стендап был что то типа — все помямлили и разошлись самая интересная часть была когда онколл выбирал где сегодня будет тимланч
но даже при таком стендапе, таски создавались так, чтоб не более 3-4 дней на таск, все что больше сразу же разбивалось на мелкие субтаски. на исследования, если прям вот совсем надо провести, выделялся отдельный толи таск толи как-то еще назывался, но со своим лимитом времени. типа если за пару дней не получилось сделать как предполагали, то стоп — фиксируем прибыль/убыль. кстати похоже у Сереги с этим и проблема — не может он придти к босу и сказать: "ну не шмагла я"
P>Чем канбан какой. Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Первые 7-8 спринтов так и будет, ничего не понятно, планы не планируются, фичи делаются внезапно и т.п..
Но спринтов через 10-12 оказывается, что накоплено достаточно опыта и исторических знаний. И оно вдруг начинает довольно точно показывать реальность, что будет сделано, а что нет. В общем, как и везде, поначала бардак, потом устаканивается.
Здравствуйте, Pauel, Вы писали:
L>>Канбан — это тот же скрам, только вид в другой проекции. P>Эдак у вас все стало скрамом. Забавно.
В основе что скрама, что канбана лежит принцип разделения задач на более мелкие таски до тех пор, пока каждый таск не станет достаточно конкретным, чтобы затраты на его реализацию можно было обоснованно оценить.
Остальное — это детали, котоыре делают канбан более подходящим для операционных задач, а скрам — для проектных.
Делить проект на осязаемые подзадачи, обсуждать, оценивать и т.п. нужно в любом случае.
МП>>возник спонтанный трёп, в ходе которого я случайным образом завладел вниманием толпы, перевёл тему в химию, химию цементов, и в итоге прочитал всем типа минилекцию про ~технологию заливки бетона (преднапряжённого) E>Как там бункер поживает? Блин, тебе по идее можно не работать, завел бы блог типа "строю бункер" и "как я отшиваю девушек так как они не девственницы", и заимел бы до хрена подписчиков. Я б точно подписался . E>А то, скучно чет.
мой бункер наверно выдержит 2-3 артиллерийских попадания, но вряд ли поможет в случае щебекенизации территории
я для полуавтоматизации стройки из бетона разработал из фанеры и досок вагонетку с воронкой из майкрафта
она ездит на тяге от электротельфера от большой воронки-загрузочного бункера для щебня по деревянным рельсам к бетономешалке
в какой-то момент я надорвался, залив за раз 700 литров бетона (связка воспалилась в колене),
и после этого разработал комплекс мер по разгрузке замеса от прочих работ по копанию и переноске щебня, песка и цемента
я посадил конечно картошку, но без бабок выживать будет тяжко
работу не нашёл даже с 40% дисконтом от довоенного времени
думаю придётся доизучить геймдев и пойти туда работать хоть с 70% дисконтом
(ради геймдева я изначально пришёл в индустрию программирования)
ну это если хоть где-то вообще будут деньги в экономиках
P>Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.
И, следовательно, скрам не нужен вообще от слова совсем, да?
P>Еще один ресёрч длился два года, и в самом конце я подвис на месяц или два, чуть не поседел. Ну есть у меня подзадачи "написать чтонибудь еще" и "собрать статистику", а дальше то что?
А дальше то, что в любом исследовательском проекте, которым является в том числе разработка нового ПО, нужно в первую очередь идентифицировать и оценить главные риски, которые могут помешать, усложнить, или вообще сделать реализацию невозможной или непрактичной. Бессмысленно проводить бесчисленные совещания о расположении кнопок на пользовательском интерфейсе, если неизвестно, существует ли в принципе подход или алгоритм, который позволит решить задачу.
Вот это и нужно помещать самые первые спринты. Затем, по результатам, принимать решение. Быстро вышли на идеальное решение — превосходно, нашли решение, которое работает, но с ограничениями — пингуем проджект овнера и ждем ответа. Напоролись на принципиальное или физическое ограничение, ну что ж, как говорят теоретические физики из одного анекдота, "гребаная гравитация".
Ну и в конце такого проекта подвиснуть можно только на деталях. Лечится переключением на другие задачи.
P>С приложением все иначе — сходимость прогозов и результатов рано или позно обеспечивается. А вот с исследованием это не так.
P>Результат по проекту он аддитивный.
Нет.
P>Даже если вы пишете плохо, то все равно доберётесь до конца.
Нет.
Верхние два утверждения лежат в основе водопада, который, как известно, в разработке ПО не работает.
P>По исследованию это мягко говоря не так.
Разработка ПО — это исследовательская деятельность.
P>Необязательно. Траблшутинг, суппорт тоже сюда относятся.
... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time.
P>Больше двух десятков лет. Первые десять — наукоёмкие, с теми самыми исследованиями. Последние 5 — уклон в R&D
Можно уточнить, что есть "те самые исследования", на конкретных примерах? Коммерческие компании не так и часто занимаются наукоемкими исследованиями. А в некоммерческих НИИ я что-то не Сприпомню применения методологий разработки софта.
P>Структурировать — можно. Только это делается другими методами, т.к. результат неизмеримый, а качественный.
Результат, повторю в четвертый уже раз, очень даже измеримый. Результат — это не обязательно открытие мирового уровня. "Закрытие" (суть опровержение гипотезы) тоже результат. Задача ставится как "проверить такую-то идею". В терминах скрам это будет "эпик". Состоящий из задач поменьше: получить такие-то данные, написать такие-то программы, найти такие-то параметры. Ни про одну из этих задач нельзя точно сказать, сколько времени займет ее выполнение. Но это и не нужно! Все, что требуется, это отранжировать задачи, оценивая, какая задача сложнее, и какая проще. Выбираете самую простую задачу: ее сложность равна 1. Остальные задачи ранжируете по кажущейся сложности (вот эта в 2 раза сложнее, эта — в 5, а эта тоже легкая, такая же, то есть 1).
P> В скраме все приводят к попугаям. Исследование — процесс.
Какая связь между этими двумя предложениями? Пусть исследование — процесс. Он не атомарен, в процессе исследований всегда есть какие-то промежуточные точки, вехи, результаты. Попугаи нужны лишь для прикидки сложности. Которая, статистически, транслируется в среднее время выполнения.
P>А если вам дают "какой материал наиболее пригоден для упаковки с т.з. А, Б и Ц" то здесь скрам просто так работать не будет.
Почему не будет? Как раз для подобных исследований скрам вполне годится. Более того, он потребует формализации процесса — придется вспомнить, какие именно шаги предпринимаются в процессе исследования. Например, в первом спринте такие: "читаем гугл — как другие решили схожую задачу", "придумываем тесты, которые проверяют соответствие критерию А, критерию Б, критерию Ц", "выбираем первый набор материалов". По окончанию спринта имеем на выходе артефакт "список материалов, которые хотим проверить в первом раунде". Второй спринт посвящен проверке материала ХХ и УУ. По окончании спринта результат может быть "оба материала не подходят, но ХХ лучше, а значит, меняем список следующих материалов на ГГ и ОО". Итерируем дальше.
Я понимаю, когда неохота заниматься формализацией процесса, можно придумать миллион причин, почему процесс не формализуем. И если это "НИИ просиживаем штаны", или, как в сериале "Стартап", занимаемся исследованиями стрельбы картошкой, то любые методологии бессильны. Но я-то речь веду про коммерческую компанию, у которой есть бюджет, окупаемость и т.п..
P> Хоть обскрамайтесь, у вас всё равно будет эта последовательность. Постоянно валится траблшутинг-суппорт — каждая аномалия уводит вас с этой последовательности.
Вы так и не поняли основной идеи скрама. Если траблшутинг-саппорт в самом деле "постоянно валится", он будет учтен в параметре "available time". Уже через несколько спринтов у вас будет накоплена статистика: в среднем, 50% времени спринта уходит на траблшутинг. И, вот же чудо, оказывается, что это позволяет весьма точно прогнозировать будущее (в среднем!!! не каждый спринт, но на дистанции).
В мою бытность product owner'ом, я обслуживал две команды. Одна как раз maintain'ила предыдущую версию продукта, примерно в том самом режиме "на нас постоянно валятся срочные запросы от кастомеров". С ними оказалось даже проще, чем с той, которая новый продукт разрабатывала. Потому что операционная деятельность присутствует всегда, и ее легче прогнозировать на основе имеющейся истории.
P>Зато это стандартная последовательность действий при аномалии.
Вы понимаете, что сейчас сами написали? "СТАНДАРТНАЯ АНОМАЛИЯ"! Да это ж просто прекрасно, уже через несколько спринтов вы уже знаете, сколько нужно время на решение "средней жо.", тьфу, "аномалии".
P>Это результат, только он неизмеримый, а качественный — новое знание о применимости конкретной модели.
Результат "да/нет" — вполне себе измеримый. Тип boolean Собственно, это классика скрам — иметь задачу, которая называется "понять, как работает ХХХ, и на основе этого выработать стратегию решения проблемы ЧЧЧ".
P>Вы так и не поделились примером планирования операционной деятельности по скраму.
Я предположил, что вы имеете представление о том, как работает скрам (и что такое available time), но, видимо, ошибся. Операционная деятельность именно так и планируется: вы знаете, что в среднем (за последение 10 спринтов) у вас 40% времени команды уходило на эту деятельность. Значит, во время planning вы принимаете этот показатель в расчет (инымы словами, оставляете 40% буфер на каждый спринт, — в некоторые спринты он не понадобится, в некоторые будет использовано больше, но В СРЕДНЕМ все равно получится 40%).
S>Накопили статистику для команды, и? В чем инсайт?
Что значит "инсайт" в данном контексте? В чем секрет? Так нет его, секрета. Накопили статистику, снизили уровень бардака, и, внезапно, работы по проекту стали хорошо прогнозируемы. Видно, что и когда НА САМОМ ДЕЛЕ будет сделано. Не по заявлениям разработчиков (умноженным на буферные 3.14), а реально.
Собственно, скрам для этого и нужен — понимать, когда и что будет готово.
Здравствуйте, _ABC_, Вы писали:
_AB>Скорее, это просто что-то, что далеко не очевидно очень и очень многим, включая тех, кто обучает, а создатели всех этих фреймворков, методологий и прочего, скорее всего, это, наборот, считают слишком очевидным, чтобы затрагивать.
Думаю, тут дело в классическом "у нас процесс, а все остальное — вторично"
_AB>Плюс обучают либо управлению операционной деятельностью (канбаны, итили и прочее), либо управлению проектами. По отдельности. Не задумываясь над их пересечением. Управлению жизненным циклом разработки программного продукта если и обучают, то эти методологии, видимо, не так широко известны. Я про них не слышал, например.
У нас был опытный менеджер, перешедший из разработки железа. Его хватило на 1 софтверный проект.
K>Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
Этому скрам не обучен. Он работает в обратном направлении: к проекту есть требования (по реализации тех или иных фич), лежащие в том самом бэклоге. Который не статичен: в него добавляются все новые и новые задачи (в некоторых случаях могут и удаляться, но как-то в моей практике это было совсем редким событием).
С течением времени, на основании накопленной статистики (team velocity в первую очередь) при неизменном бэклоге можно делать некие приблизительные (с точностью до пары спринтов) оценки завершения проекта. Но, во-первых, мне еще ни разу не попадался статичный бэклог, а во-вторых, диаграмму Ганта из бэклога сделать не получится (хотя зависимости между тасками в бэклоге могут быть видны).
Здравствуйте, CreatorCray, Вы писали:
_AB>>Stand up — это банальная пятиминутка или летучка CC>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
L>Да, смена профессии. L>Скрам (или канбан) сейчас стандарт де-факто. Он неидеален, но все (что? Водопад? ) остальное еще хуже.
L>Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
а что делаете если поступает задача на рефактор типа убрать константы по проекту?
и непонятно в какой объем это выльется и без отдельной задачи на анализ проще сказать "2 недели займет"
Здравствуйте, landerhigh, Вы писали:
L>Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
последняя задача которую я делал
в инете три примера решения (искал все топики вокруг этих трех примеров) — один не работает и Intel пишет да мы знаем оно не работает ну зато код красивый
второй не работает и 10+ человек пытались исправить но не смогли (и я не смог исправить ошибку)
третий пример работает но делает не то что нужно
я напписал что задача займет две недели а делал 5 недель
Здравствуйте, sergey2b, Вы писали:
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Как-то подыгрывать.
Но мне было бы сложно, я бы отказался. Мне нужно войти в состояние потока, это не просто — может даже за целый день не войду. Если вошел — лучше меня не трогать несколько недель. Тогда результат будет.
Если же постоянно дергать — я просто не смогу работать и обсуждать будет тупо нечего.
Между тем, что Вася может за пару недель на коленке нашедеврить, до работающего продукта нынче — огромная пропасть. Просто в силу обстоятельств.
Речь идет не о самородках, которые выдают гениальные идеи, и которые в основном закончились в 90-е, а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета.
Здравствуйте, _ABC_, Вы писали:
_AB>Пятиминутки и не призваны решать проблемы. Они призваны запланировать необходимые действия для решения проблем. У вас они затягиваются потому, что вы тупо не понимаете их смысл и цель.
Они не нужны, sync meeting раз в неделю хватает за глаза.
Здравствуйте, landerhigh, Вы писали:
L>В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное.
Вопрос не в джире, такое везде, наверное, можно провернуть. Вопрос именно в том, что это не часть проекта per se.
L>Нужно будет при планировании спринтов учитывать, что часть времени команды будет отвлечена на отдельный канбан проект.
Именно.
L>Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт.
Тут два момента.
1. Эти таски не способствуют достижения цели спринта (ну, как правило не способствуют).
2. Если их добавлять в течение спринта, то они "воруют" team capacity.
L>Так еще можно реализовать ротацию ответственности за багфиксы.
Да, согласен. Но всё это по сути сводится к одному — часть времени команда тратит не на проект, а на операционную деятельность.
А все возможные варианты — это лишь способы учесть и попытаться проконтролировать эту деятельность.
ИМХО, конечно.
L>У нас багфиксы редко бывают рафинированными, чаще всего они вырастают в отдельные проекты по изменению функциональности.
Тогда это не баг, а фича.
S>у меня задача в среднем длиться от неделю до 12 недель
У нас есть такой проект, который сам по себе, коллега сначала начал говорить каждое утро, что у него все то же самое, потом стал принимал участие только слушателем, а после уволился.
Сейчас другой на его месте что-то бурчит каждое утро, не уверен, что его кто-то слушает.
И нужно это только присутствующим начальникам, чтобы видеть, что проект движется.
Здравствуйте, _ABC_, Вы писали:
_AB>Здравствуйте, landerhigh, Вы писали:
L>>В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное. _AB>Вопрос не в джире, такое везде, наверное, можно провернуть. Вопрос именно в том, что это не часть проекта per se.
Вот, кстати, неспособность (узколобость? туннельное видение? приверженность карго-культу?) вот это понять зачастую и приводит к кошмарным попыткам применения скрама, от которых бегут, роняя тапки и потом рассказывают на форумах.
L>>Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт. _AB>Тут два момента. _AB>1. Эти таски не способствуют достижения цели спринта (ну, как правило не способствуют).
Просто плейсхолдер, чтобы не забывали, что часть времени будет потрачено вне проекта.
L>>У нас багфиксы редко бывают рафинированными, чаще всего они вырастают в отдельные проекты по изменению функциональности. _AB>Тогда это не баг, а фича.
ну вот если баг признан фичей, то он мигрирует с канбан борды на скрам борду
Здравствуйте, _ABC_, Вы писали:
_ABС_>Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта.
Раз все тут продвинутые проеджекты, может посоветуете пару книг по операционному и проектному управлению, наверное. Пришлось недавно вписаться во всё это, снова, но я просто кроме как "скрам бук", "как пасти котов" и "мифический человеко-месяц" что-то ничего не знаю, а освежить знания надо.
Здравствуйте, gandjustas, Вы писали:
G>Поэтому и существуют гибкие методологии, которые не требуют создание плана на месяцы вперед.
Надо заметить что некоторые из них настолько гЫбкие что при достижении определённого размера не могут самостоятельно стоять.
_AB>>Если его напишут и если его прочитают. И если поздно не будет на него отреагировать. CC>Ну очень нужная мне информация что вася пупкин крутил свою гайку на 15, да!
Если у вас в скрам проекта разработки блока питания к туннельному микроскопу включают кухонных работников, которые вам будут готовить обед, то все вопросы к руководству.
_AB>>которая делит один и тот же план работы на неделю CC>У нас нет планов именно на неделю.
Ну тогда скоро не будет и на квартал. А потом и на год.
Примерно так загнивание выглядит.
Здравствуйте, SkyDance, Вы писали:
SD>Писал об этом еще с 2007. Равно как и о том, что сия прозрачность зачастую противоречит интересам участников процесса поэтому внедрение методики испытывает жестокие фейлы.
Ну да, особенно когда привыкли в одиночку "пилить проект два года"
Здравствуйте, landerhigh, Вы писали:
L>Да, даже целая методология разработки, основанная на коротких этапах, есть. Угадаешь, как называется?
То есть ты действительно веришь, что до скрам-фанатиков никто до этого не додумался?
Хотя это типично, каждое поколение детишек думает, что это именно они изобрели секс. Причем делать это надо стоя и в гамаке, и никак иначе.
L>Если Ничего не планировать, то получится примерно Ничего.
То есть, у тебя все сводится именно к религиозным соображениям. Ну ок.
L>На самом деле, пытаться рассуждать на темы, о которых имеешь очень отдаленное представление, это характерная черта кывта
Здравствуйте, no_ise, Вы писали:
L>>Между тем, что Вася может за пару недель на коленке нашедеврить... _>Вася за пару недель на коленке не шедеврит. Вася делает нормальную инженерно-изобретательскую работу. Примеры я уже привел.
Нет там никаких примеров.
В лучшем случае, ключевые инженеры, где кроме них, на проекте работают еще пара десятков инженеров уровня не меньше.
L>>...а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета. _>Так скрам и все такое подобное это подчастую и есть про то, как законно и на вполне _>легальных основаниях затягивать сроки до бесконечности путем непрерывных улучшений _>косячного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Так водопад и все такое подобное и есть про то, как на вполне легальных основаниях затягивать сроки до бесконечности путем непрерывных "улучшений" изначально неправильно заложенного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Здравствуйте, Артём, Вы писали:
Аё>Висеть долго на подзадаче- нехороший признак. Значит, она не по зубам, или в принципе не решаема.
висеть долго — вообще нельзя. к тебе будут приходить, спрашивать "ну как?", а ты только мычать в ответ лишний день потратил и нет результатов — всё, вперед с докладом к начальству. твоя не решаемая задача может быть ключевой для команды. чем быстрее все узнают, что задача не решаема, тем быстрее поменяют планы, сохранят время и деньги
Ну да, есть — или решаемо, или нет, или месяц, или год, или в одно лицо, или командой.
SD>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. Все эти "магические процедуры" — банальная телеметрия, для понимания, что сколько стоит. Проработав так год-другой, приличная лаборатория уже знает, сколько будет стоить проверка очередной гипотезы (вне зависимости от результата).
Вы лучше расскажите, как вы будете спринты планировать, когда содержание меняется от каждого нового промежуточного результата. Здесь слишком много т.н. грязных задач, почти что операционная деятельность — обслуживание процесса, регулярно задачи типа траблшутинга-суппорта, которые заранее не видны.
Ну вот делаю, скажем, прогон тестов. Полезли неожиданные ошибки. По плану — брать другую подзадачу. А с этими ошибкими весь баклог спринта коту под хвост.
Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.
Еще один ресёрч длился два года, и в самом конце я подвис на месяц или два, чуть не поседел. Ну есть у меня подзадачи "написать чтонибудь еще" и "собрать статистику", а дальше то что?
С приложением все иначе — сходимость прогозов и результатов рано или позно обеспечивается. А вот с исследованием это не так. Результат по проекту он аддитивный. Даже если вы пишете плохо, то все равно доберётесь до конца. По исследованию это мягко говоря не так.
Здравствуйте, CreatorCray, Вы писали:
CC>И правильно сделал
Директора HR заменят через 1-3 года, а проект нужно зафейлить?
Опытные прогеры не истерят, а с пофигизмом наблюдают за калейдоскопом "внедрителей более лучшей производительности".
Здравствуйте, SkyDance, Вы писали:
L>>Серьезно, хватит заниматься перепевками Битлз по телефону, почитай уже основы, а?
SD>Да не поможет это, я тоже читал, и думал, что понимал, но реально осмыслил происходящее только через 7-8 месяцев работы с опытным тренером (тем самым "скрам коучем", да). SD>Самым сложным было осознание простоты происходящего процесса. Я все где-то искал подвох, старался быть умнее и т.п., а всего-то надо было накопить историю выполнения задач конкретно взятой командой. Ключевое тут именно "команда", если люди постоянно меняются, не факт, что будет хорошо работать.
На самом деле беда в твердолобости и косности мышления.
Из того, что я лично видел в свое время, менеджмент, сходив на тренинг по скраму, выносил для себя, что решение всех проблем — это двухнедельные спринты. И выходил приказ всю запланированную работу на год разбить на двухнедельные периоды. Тут тоже такие отметились, кстати.
Люди реально не понимают, что разработка ПО — это не строительство дома, где все на самом деле делается по предсказуемым этапам. Наша работа намного ближе к разработке проекта этого самого дома, иными словами — это исследовательская деятельность в чистом ее виде.
Здравствуйте, baxton_ulf, Вы писали:
S>>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
_>ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды
Это не всегда возможно: иногда задачи бывают действительно сложные. Тогда в процессе их решения возникают подзадачи, а в процессе решения подзадач возникают ещё подзадачи, по несколько штук в день. Т.о. получается, что у тебя в работе будет стек задач.
К примеру: решаем задачу GUI-A. В процессе её решения появились задачи GUI-A001, GUI-A002. Ознакомился с A001 (т.е. оценил), перешёл к A002 глянул — поставил на паузу, вернулся к A001 — создал GUI-A003, GUI-A004. Положил в стек GUI-A001, решаем GUI-A003.
В итоге список выглядит вот так:
GUI-A — InProgress
GUI-A001 — InProgress
GUI-A002 — Paused
GUI-A003 — InProgress
GUI-A004 — TODO
Собственно, после решения GUI-A003 перейдём к GUI-A004, а после неё GUI-A001 будет автоматически решена.
В таком случае спрашивается: 1) на кой ляд нужны были A003 и A004, если это этапы одной задачи?
2) Стоило ли вообще заморачиваться со всей сетью задач GUI-A00X, если вся эта канитель — решение одной задачи: GUI-A
Когда у меня были такие задачи, я не заморачивался. Не заморачивался кстати не только я. У меня тогда в YouTrack'е были задачи на 12 и больше экранов текста. Там и рабочие материалы были, и скриншоты, и результаты тестирования — 2 месяца канители над одной задачей.
Всё сказанное выше — личное мнение, если не указано обратное.
Здравствуйте, SkyDance, Вы писали:
SD>Такова разработка любого продукта, кроме совсем уж тривиальных.
Нет не любого. Иногда люди пишут совсем нетривиальные вещи, и именно с этого чаще всего начинается бизнес. Да и невозможно всегда писать одно и тоже.
Я когда-то насмотрелся на одни и те же повторяющиеся действия: простенький Select, маппинг результатов на коллекцию объектов, отображение, редактирование. После сотого повторения я написал сначала простенький генератор таких селектов с генератором классов для маппинга результатов на коллекцию. А о том, что гуй можно автоматом генерировать я и раньше слышал — так ещё мой школьный товарищ делал.
Рано или поздно вот такая тупая работа автоматизируется и ты оказываешься не нужен.
Всё сказанное выше — личное мнение, если не указано обратное.
Да, на собеседовании уже было видно, что к ним идти не надо
S>>а затемо стал каждый день тупо готовиться к собеседованиям Аё>Чтобы в следующий раз наступить на те же грабли.
Здравствуйте, Артём, Вы писали:
CC>>C чего ты взял? Аё>Наблюдения.
Какие?
Аё>>> а проект нужно зафейлить? CC>>Надо принести себя на алтарь долбоклюйства менеджмента, да! Аё>HR- это не продакт менеджмент.
То, что он описывает это не про HR, это как раз про менеджмент.
Аё>стоит ли менять контору из-за политик отдела кадров.
Стоит.
Аё>В теории. А на практике кое-кто держится за Эппл.
Артёмка,
Наш внутренний менеджмент отлично понимает что на самом деле важно а что всего то для галочки.
Здравствуйте, Antidote, Вы писали:
A>Да, на собеседовании уже было видно, что к ним идти не надо
Ох меня припекает на них. Они типа учат другие компании, как нужно бустить мораль- а сами провели 2 жёстких сокращения за 3 года.
S>>>а затемо стал каждый день тупо готовиться к собеседованиям Аё>>Чтобы в следующий раз наступить на те же грабли.
A>Грабли у всех разные
Сергей везде находит одинаковые
Здравствуйте, SkyDance, Вы писали:
SD>Такова разработка любого продукта, кроме совсем уж тривиальных. SD>Я в третий (и последний) раз повторяю: когда вы проходите этот процесс в десятый раз (на 11м спринте), у вас уже накоплено столько статистики, что вы В СРЕДНЕМ знакте, сколько этих фейлов произойдет, и как долго их исправляь. ПОДЧЕРКИВАЮ: В СРЕДНЕМ!!! Да, в каждый конкретный спринт вы можете выполнить "лишнюю" таску, а можете провалить спринт, не доделав ожидаемую (хотя в этом случае вам должны помочь другие члены команды, которые, В СРЕДНЕМ, уже освободились от их собственных задач на спринт).
Звучит как: "В каждом инженерном проекте раз в N недель случается K больших жоп и M жоп поменьше, на преодоление большой жопы тратится L человеко-часов, на преодоление средней жопы -- P человекочасов, на преодоление маленькой жопы -- Q."
Вне зависимости от типа проекта. Просто так случается и все. Так устроен мир.
А вопрос лишь в том, чтобы экспериментальным путем для своей команды выяснить значения N, K, M, L, P и Q.
Здравствуйте, CreatorCray, Вы писали:
CC>Какие?
Я наблюдал смену директоров кадровиков регулярную.
CC>То, что он описывает это не про HR, это как раз про менеджмент.
Это может быть уровень CEO. Наскучит CEO эта техника "повышения производительности"- найдёт другого массовика-затейника.
CC>Наш внутренний менеджмент отлично понимает что на самом деле важно а что всего то для галочки.
Это хорошо заметно по глюкам в яблочных продуктах. Нет если тебя устраивает по деньгам и технически работа нравится- я не призываю бросать.
P>Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев
Это вы не в курсе про планирование операционной деятельности. Там тоже все давно известно. Включая рекомендацию вместо скрама использовать канбан (который по сути есть квинтэссенция "операционной деятельности"). Лично мне не довелось долго работать с этой методикой, поэтому от комментариев я лучше воздержусь.
Здравствуйте, Pauel, Вы писали:
P>Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности.
Кхм. И?
P>Т.е. когда тикеты нужно фиксить сразу по мере их появления.
Вообще говоря, если мы говорим о скрам и о проектах, то там "тикетов" нет.
И я не очень понимаю, зачем они нужны именно вам. Что вы под ними понимаете?
Помимо непосредственно исследования, у вас есть существующие продукты в промышленной эксплуатации, на которые вам необходимо тратить ненормированное количество времени?
Ты же не это имеешь в виду, если судить по тому, что ты дальше пишешь?
P>Здесь нечего пихнуть в спринт — баклог пустой.
Как пустой, если вы "тикетами" занимаетесь? Ничего, что эти "тикеты" — это вполне себе backlog items?
P>В таком варианте скрам вполне себе работает.
Скрам работает в разных вариантах, но у меня складывается впечатление, что о скраме тебе Рабинович напел...
Здравствуйте, Pauel, Вы писали:
P>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
Никак. "У юзеров" — это не часть проекта. Это эксплуатация. Решается в рамках операционной деятельности, SLA и т.д. и т.п.
Ты же, вроде, говорил о создании того, что никто раньше не делал? Откуда юзеры взялись?
Т.е., получается, всё-таки, у вас есть что-то в эксплуатации и вместо работы над исследованием (проектом), вы должны ненормированное количество времени тратить на поддержку существующего?
_AB>Честно говоря, я не убеждён, что ресёрч похож на операционную деятельность. Я, конечно, не настоящий сварщик, но в моём понимании исследование имеет цель (причём цель — это получить новое, неизвестное), имеет сроки, имеет бюджет. Другими словами — это проект ну просто тупо и буквально по определению слова "проект".
Поддерживаю. Но, сдается мне, для большинства работа со сроками, бюджетами и прочими реалиями чугунной задницы мира не является чем-то интересным и приятным. Это вообще ни разу ни фан, все эти планирования, отчеты, демо...
L>У нас разные понимания того, что является исследованием.
Скорее, разные цели: у кого-то цель "поисследовать" с безграничным бюджетом и вечным местом в советском НИИ (а как еще можно назвать такие место, где можно бесконечно протирать штаны, без каких-то результатов, сроков и планов). Мы же смотрим с точки зрения бизнеса.
Здравствуйте, SkyDance, Вы писали:
L>>У нас разные понимания того, что является исследованием.
SD>Скорее, разные цели: у кого-то цель "поисследовать" с безграничным бюджетом и вечным местом в советском НИИ (а как еще можно назвать такие место, где можно бесконечно протирать штаны, без каких-то результатов, сроков и планов). Мы же смотрим с точки зрения бизнеса.
Меня терзают смутные сомнения, что некоторые под словом "исследование" подразумевают сбор и обработку данных по четкой методологии. Исследование отложенного спроса или общий анализ крови там.
Это имеет право на жизнь, но не имеет ни малейшего отношения к методам разработки ПО.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, SkyDance, Вы писали:
SD>>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. K>А как и где всю эту статистику смотреть? На ретроспективе собирать фидбэк и записывать с "блокнотик" для дальнейшей оценки/переоценки, подсчёта локов и т.п.?
Ее вообще не нужно смотреть и записывать.
Она — для команды.
См. "self managing teams".
На практике в джире ее видно в burndown chart, например.
Здравствуйте, Sharov, Вы писали:
S>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы.
Это всё херня на самом деле. Когда надо что-тио делать приходится просто садиться и делать вне зависимости то того девопс ты или нет.
Здравствуйте, landerhigh, Вы писали:
S>>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду. L>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Писались же крупные системы типа ОС или бд, под 1млн. строк кода. Без всякого скрама. Др. вопрос,
что в массе своей все это писалось математиками и физиками, а не закончившими курсы. Кмк, уровень был
в массе своей выше, выше была дисциплина, меньше всяческих дистракторов и т.п. Поэтому можно было жить
и без скрама. Т.е. когда все зависило от исполнительского мастерства, тогда особых проблем не было.
Как отрасль стала массовой, решили тащить с помощью менеджерских практик. Так вижу.
Здравствуйте, so5team, Вы писали:
S>Да что вы говорите?!!! https://scrumguides.org/scrum-guide.html#scrum-events S>* The Sprint S>* Sprint Planning S>* Daily Scrum S>* Sprint Review S>* Sprint Retrospective S>Это в официальном руководстве по SCRUM написано. Звиздун-собеседник, конечно же, мастерски может послать все это вдоль и наговорить массу умных слов в свое оправдание. Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
К этому можно относится как к какому-нибудь фреймворку и адаптировать для команды. Т.е. все брать
не обязательно. Если пуристы будут говорить, что это не настоящий скрам, то их можно посылать нафиг,
т.к. для комнды и для ее задач это работает. Т.е. тут необходимое vs достаточное.
S>что в массе своей все это писалось математиками и физиками, а не закончившими курсы. Кмк, уровень был S>в массе своей выше, выше была дисциплина, меньше всяческих дистракторов и т.п. Поэтому можно было жить
Дело не столько в дисциплине, сколько в мотивации: то, что "писалось математиками и физиками", обычно было на энтузиазме. Которого при разработке типового интернет-магазина (или очередного "революционного подхода к RPC") скорее всего не будет, т.к. людей нанимали работать за деньги.
Здравствуйте, Marty, Вы писали:
M>Почему сразу "вынужден"? Я в таких ситуациях красочно рассказываю, с какими проблемами столкнулся, вовлекаю коллег в дискуссию по поводу способов решения этих проблем, в следующий раз рассказываю, сколько героических усилий мне понадобилось, чтобы проверить предыдущие, предложенные коллегами, гипотезы, как и почему это ни к чему не привело, и тд, и тп.
Здравствуйте, sergey2b, Вы писали:
S>где мои коллеги бодро рапортую о запилинных за 24 часа фичах или исправленных багах
А ты послушай внимательнее, далеко не у всех отчёт будет сильно отличаться от твоего.
S>у меня задача в среднем длиться от неделю до 12 недель и поэтому на большенстве stand up S>я вынужден рапортовать — занимался исследованиям, проводил эксперементы, узнад на что влияет параметр XYZ в структуре S>из за отсуствия видимого прогресса стала падать мое визабилите в проектеи я не чуствую хепиниса от работы
Как же нет прогресса, когда показания каждый день разные — то исследования, то эксперименты, то узнал что то? Или это результат 12 недель? Тогда надо сказать "нужен совет и другая пара глаз".
S>есть ли какие то варианты улучшить ситуацию кроме смены работы ?
Выдели день/два в неделю на починку багов и бодро рапортуй.
Здравствуйте, baxton_ulf, Вы писали:
_>ну дык разбей на 10 маленьких задач. как говорится "в попугаях оно все значительно длиннее". и будешь самым производительным членом команды
Как вариант кстати.
Но это похоже припарка, после того как там "вынудили удалить все что относиться к IDE", "редактировать в mc собирать make и отлаживать через логи".
Когда в культуре компании превозносится девиз "Стоя! В гамаке! И на лыжах!" то это нехороший знак это та из контор, где надо всем и всегда рассказывать как тебе было тяжко, как всё было плохо, но ты таки превозмог! Даже если речь шла про пойти отлить. Ибо там работу будут оценивать не по тому, как ты её быстро и хорошо сделал, а по тому, как ты рассказывал как ты устал превозмогая. Впрочем это в общем то повсеместно в местах с хреновыми манагерами.
Здравствуйте, CreatorCray, Вы писали:
_AB>>Stand up — это банальная пятиминутка или летучка CC>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
Вероятно, это ты себе такое окружение выбрал.
_AB>>Для тебя польза — понять, что делают остальные и озвучить любые свои проблемы, если они есть. Решать их надо отдельно. CC>А на деле каждый что то бурчит для отмазки и тут же отвлекается продолжать делать что то своё, слушая в полуха.
Телепат? Предполагаю, это ты сам так поступаешь.
CC>Потому как один фиг времени хватает каждому что то пробурчать, если начинается обсуждёж то это один фиг надолго да и непричастные всё равно тупо отвалятся ибо работы хватает.
Здравствуйте, landerhigh, Вы писали:
L>Если разработчик говорит, что задача займет от "недели до квартала", то в переводе на человеческий язык это означает, что разработчик понятия не имеет, как задача будет решаться ввиду объема и/или наличия неопределенности.
Здравствуйте, landerhigh, Вы писали:
P>>Про то и речь — исследования, эксперименты.
L>И "исседования" и "эксперименты" тоже требуют планирования и деления на задачи.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, CreatorCray, Вы писали:
_AB>>>Stand up — это банальная пятиминутка или летучка CC>>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
L>Ну вот у нас редко за 5-7 минут выходит.
если непонятно что-то или проблема то отдельно митинг делаете или остаетесь после митинга?
Здравствуйте, 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% попыток применения скрама — это карго-культ, где все поставлено с ног на голову.
Скрам плохо подходит для исследований или багфикса.
Здравствуйте, Kernan, Вы писали:
L>>Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову. K>Скрам плохо подходит для исследований
Как раз для исседований он прекрасно подходит.
K>или багфикса.
Здравствуйте, CreatorCray, Вы писали:
CC>Вот только я за последнее десятиление чот не помню чтоб хоть раз видел чтоб это было быстрее чем полчаса.
Ну, это проблемы компаний, в которых ты работал.
CC>А на деле каждый что то бурчит для отмазки и тут же отвлекается продолжать делать что то своё, слушая в полуха.
Если на полчаса растягивать, то конечно.
CC>А все проблемы решаются путём прихода к правильным людям и взятием их за пуговицу, чтоб не сбежали.
Пятиминутки и не призваны решать проблемы. Они призваны запланировать необходимые действия для решения проблем. У вас они затягиваются потому, что вы тупо не понимаете их смысл и цель.
Здравствуйте, Pauel, Вы писали:
P>Вероятно, это ты себе такое окружение выбрал.
Угу, практически все задачи немаленького размера, DRI, Feature owner. В двух словах как правило не рассказать.
P>Телепат? Предполагаю, это ты сам так поступаешь.
Ну видно жеж как народ в лапотопы/телефоны обратно утыкается и начинает что нить активно тайпать и тебе мессаги от них приходят.
Здравствуйте, 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>Зато ты отвлечёшь кучу людей прямо сейчас.
Зачем "отвлечёшь", если это де-факто открытие дня? Или закрытие, у кого как.
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.
Здравствуйте, _ABC_, Вы писали:
_AB>Я, кстати, тоже пытался впендюрить в скрам багфиксинг хоть как-то и считал этот аспект признаком полной отрованности скрама от жизни. Пока не понял для себя эту разницу. Хреново только, что ответа в чистом виде я не находил ни в англоязычном, ни в русскоязычном сегменте. Про разницу между проектами и операционной деятельностью есть, но в материалах по управлению проектами людей, далёких от разработки софта. Пришлось доходить своим умом, а он у меня не блестящий и менеджер я хреновый, так что дошло только совсем недавно. Вышестоящие менеджеры, так уж исторически сложилось, все из консультантов, не разработчиков, тоже подсказать не могли. На всяких курсах по управлению проектами и во всяких книгах я тоже, почему-то, этого не видел. Может мимо проходило, а может и нет там этого в явном виде.
В случае, когда бакгфиксы являются именно багфиксами, можно применять комбинированный подход — иметь и скрам для проектной работы и отдельный канбан для систематезации операционных задач. Jira позволяет подобное.
Нужно будет при планировании спринтов учитывать, что часть времени команды будет отвлечена на отдельный канбан проект.
Но можно, например, добавлять таски вроде "работа над багами" в каждый спринт. Так еще можно реализовать ротацию ответственности за багфиксы.
У нас багфиксы редко бывают рафинированными, чаще всего они вырастают в отдельные проекты по изменению функциональности.
Невозможно спланировать то, что ты еще не знаешь точно как решать. Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту. Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, landerhigh, Вы писали:
C>Невозможно спланировать то, что ты еще не знаешь точно как решать. Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту. Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.
Такое тоже не исключено.
Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, landerhigh, Вы писали:
C>Невозможно спланировать то, что ты еще не знаешь точно как решать.
Можно спланировать свое исследование задачи.
C>Всегда есть простор для появления подводных камней, которые пустят все твои планы по одному месту.
Поэтому и существуют гибкие методологии, которые не требуют создание плана на месяцы вперед.
Спланируй на день, ты ведь сможешь прикинуть что ты будет делать сегодня? Потом спланируй на 5 дней. Причем ты вполне можешь накидать несколько вариантов задач на неделю в зависимости от результатов исследования каждый день. Этого уже достаточно.
C>Так что вся эта простыня — имитация полезной деятельности, а в реальности задача займет либо в 10 раз меньше времени, а свободное время будет потрачено на срач в форуме, либо в 10 раз больше, либо не будет решена вообще.
Детализация задач до размера одного дня и ежедневные стендапы позволят это узнать пораньше.
Здравствуйте, landerhigh, Вы писали:
L>>>Это не отменяет того, что 95% попыток применения скрама — это карго-культ, где все поставлено с ног на голову. K>>Скрам плохо подходит для исследований
L>Как раз для исседований он прекрасно подходит.
На счет прекрасно — это крайне сомнительно, т.к. именно в исследованиях неопределенности на порядок выше чем в любых продуктовых фичах. Чем больше неопределенности, тем хуже работает скрам.
Здравствуйте, Pauel, Вы писали:
P>На счет прекрасно — это крайне сомнительно, т.к. именно в исследованиях неопределенности на порядок выше чем в любых продуктовых фичах.
Что, по твоему, исследования?
Набежали ученые в белых халатах и давай исследовать, аж фуфайки халаты заворачиваются?
Нет, это та же самая проектная работа. Зачастую даже более рафинированная, нежели более приземленные проекты.
У любого исследования есть некая цель — проверка гипотезы, поиск решения для некоей проблемы и т.п. В любом случае подобная работа начинается с предварительных исследования — поиск научных публикаций по смежным темам, предлагаются эксперименты и так далее. Постановка экспериментов — самая что ни на есть проектная работа. Особенно в тех случаях, когда требуется изготовить оборудование конкретно под эксперимент
P>Чем больше неопределенности, тем хуже работает скрам.
Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет.
Здравствуйте, landerhigh, Вы писали:
P>>На счет прекрасно — это крайне сомнительно, т.к. именно в исследованиях неопределенности на порядок выше чем в любых продуктовых фичах.
L>Что, по твоему, исследования?
Исследования это решение проблемы вида: неизвестно а можно ли сделать, а как вообще стоит сделать, а какие будут требования к этому
Вы привели пример совсем небольшой проблемы — у либы не та вычислительная сложность. Это исследование с минимальной неопределенностью. Конечно, если у вас только такие проблемы, то можно и в скрам. Представьте другой вариант — у вас нет этой либы, вообще, и вы не знаете, а решаема ли задача, реализуема ли в конкретные сроки, не займет ли это годы, а можно ли хоть как иначе.
L>У любого исследования есть некая цель — проверка гипотезы, поиск решения для некоей проблемы и т.п. В любом случае подобная работа начинается с предварительных исследования — поиск научных публикаций по смежным темам, предлагаются эксперименты и так далее. Постановка экспериментов — самая что ни на есть проектная работа. Особенно в тех случаях, когда требуется изготовить оборудование конкретно под эксперимент
Тут важно добавить, что негативный результат или даже отсутствие результа вполне себе нормально для исследовательской работы. Копали-копали-копали, и выяснили, что на данном этапе исключить неопределенность не выйдет, мощностей конкретного проекта не хватит. И сколько на это времени потрачено будет известно в конце исследования.
Отсюда ясно, что хотя и работа проектная, продуктовые подходы типа скрама применять не факт что целесообразно.
P>>Чем больше неопределенности, тем хуже работает скрам.
L>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет.
Это вы перевираете. Скам вырос из продуктовой разработки, где неопределенность по определению невысокая. Т.е. уже на старте проекта почти всегда известно, что задача решаема и более менее известно, как именно. Неопределенность в основном в изменчивости требований и их количестве.
В исследованиях ровно наоборот — часто бывает так, что не известно, ни решаема ли задача, ни каким путём, ни требования.
Здравствуйте, Pauel, Вы писали:
P>Исследования это решение проблемы вида: неизвестно а можно ли сделать, а как вообще стоит сделать, а какие будут требования к этому
P>Вы привели пример совсем небольшой проблемы — у либы не та вычислительная сложность.
Очень легко осуждать, глядя на результаты.
А вото то, что проблема была исключительно в либе, стало известно только по результатам исследования.
Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным.
P>Это исследование с минимальной неопределенностью.
Это оно задним числом минимальное.
P>Конечно, если у вас только такие проблемы, то можно и в скрам. Представьте другой вариант — у вас нет этой либы, вообще, и вы не знаете, а решаема ли задача, реализуема ли в конкретные сроки, не займет ли это годы, а можно ли хоть как иначе.
Не вижу разницы.
P>Тут важно добавить, что негативный результат или даже отсутствие результа вполне себе нормально для исследовательской работы. Копали-копали-копали, и выяснили, что на данном этапе исключить неопределенность не выйдет, мощностей конкретного проекта не хватит. И сколько на это времени потрачено будет известно в конце исследования.
Ну да, как только стало известно, что сделать нельзя, исследование заканчивается.
L>>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет. P>Это вы перевираете. Скам вырос из продуктовой разработки, где неопределенность по определению невысокая.
Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса.
Здравствуйте, landerhigh, Вы писали:
L>Очень легко осуждать, глядя на результаты. L>А вото то, что проблема была исключительно в либе, стало известно только по результатам исследования. L>Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным.
Цель скрама — сделать разработку предсказуемой. С исследованием до самого конца вы этой предсказуемости не получите. Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта.
Максимум, что вы можете добиться — большей прозрачности. Только зачем вам скрам для этого?
L>>>Скрам и был создан как методология работы над проектами, где в начале проекта ничего, кроме неопределенности, нет. P>>Это вы перевираете. Скам вырос из продуктовой разработки, где неопределенность по определению невысокая.
L>Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса.
Здравствуйте, _ABC_, Вы писали:
_AB>Зачем "отвлечёшь", если это де-факто открытие дня?
У кого как.
_AB> Или закрытие, у кого как.
Если поставить к закрытию то вообще мало шансов даже половину увидеть.
CC>>Емыл же прочитают когда будет удобно. _AB>Если его напишут и если его прочитают. И если поздно не будет на него отреагировать.
Ну очень нужная мне информация что вася пупкин крутил свою гайку на 15, да!
Мне надо статус по нужному мне функционалу от совсем других людей, с бОльшего из других команд. И я с ними и так держу прямой контакт.
Наиболее полезное времяпровождение бывает когда сразу говорится что ай пофиг на то, кто что пилил недавно, тут относительно глобальный нежданчик случился, давайте обсудим вот такую заморочку.
_AB>Расскажешь, если научишься. А с чего ты взял что я вообще собираюсь? Наоборот идёт push извести эти статусы совсем, их у нас их в общем то и не было раньше, а ввели когда народ разогнали на ковидлу и манагерам полоскали мозги верхний менеджмент. Нынче же они играют роль будильника по дням когда народ глобально работает из дома.
_AB>Сколько всего человек в вашей команде? В той, что, грубо говоря, работает над одними и теми же кусками кода/продукта
Человек 20 примерно, лень считать, команда распределена географически. Работа идёт над разными компонентами проекта, друг дружке в функционал не лазят, разишо по мелочи какой.
_AB>которая делит один и тот же план работы на неделю
У нас нет планов именно на неделю.
Здравствуйте, landerhigh, Вы писали:
L>Стендап — он не для менеджера.
Он для "процесса"
L>В принципе, скрам методология — это не об управлении.
Это про онанизм на процесс, да.
CC>>обычно человек 10-12. L>Это уже много
Эта фигня как то работает если есть небольшая кучка долбоклюев, которой раздали ключи, назначили гайки, и они их крутят.
А когда команда состоит в основном из DRI, которые берут фичу, дизайнят, планируют, договариваются с другими командами о том, что понадобится от них, и потом пару лет её пилят, координируясь с другими feature owner как внутри как и cross-team, то эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Здравствуйте, Pauel, Вы писали:
L>>Вначале, мы вообще предполагали, что ввиду того, что протокол дико overengineered, может существовать принципиальное ограничение, которое сделает весь проект бессмысленным или не практичным. P>Цель скрама — сделать разработку предсказуемой. С исследованием до самого конца вы этой предсказуемости не получите.
Получаем, при этом мы уменьшаем неопределенность с каждым таском. Вплоть до того, что к достижению точки, которая станет примерно серединой проекта, мы можем давать очень точные estimations для всех тасков.
P>Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта. P>Максимум, что вы можете добиться — большей прозрачности. Только зачем вам скрам для этого?
Я делюсь своим опытом, где скрам сработал именно так. И добиться большей прозрачности — это уже сама по себе очень серьезная ачивка.
Не надо меня пытаться ни в чем убеждать, аппелируя к примерам карго-культа, мне это неинтересно, никого я переубеждать не собираюсь.
L>>Нет. Он вообще не из айти пришел. Советую ознакомиться с историей вопроса. P>По вашему, продуктовая разработка только в айти?
Он вообще не из продуктовой разработки пришел. Вообще не из разработки.
Еще раз — почитайте уже первоисточники, пересказывать их у меня нет ни времени, ни желания.
Здравствуйте, landerhigh, Вы писали:
L>Вот, кстати, неспособность (узколобость? туннельное видение? приверженность карго-культу?) вот это понять зачастую и приводит к кошмарным попыткам применения скрама, от которых бегут, роняя тапки и потом рассказывают на форумах.
Скорее, это просто что-то, что далеко не очевидно очень и очень многим, включая тех, кто обучает, а создатели всех этих фреймворков, методологий и прочего, скорее всего, это, наборот, считают слишком очевидным, чтобы затрагивать.
Плюс обучают либо управлению операционной деятельностью (канбаны, итили и прочее), либо управлению проектами. По отдельности. Не задумываясь над их пересечением. Управлению жизненным циклом разработки программного продукта если и обучают, то эти методологии, видимо, не так широко известны. Я про них не слышал, например.
Здравствуйте, CreatorCray, Вы писали:
CC>А с чего ты взял что я вообще собираюсь?
Ну, умение сжато самому себе рассказать о том, чем ты занимаешься, для чего и есть ли у тебя какие-то зависимости от других, в чём заключается эти зависимости и знаешь ли ты, кто тебе может с ними помочь, чисто ИМХО, полезно прежде всего себе самому.
CC>У нас нет планов именно на неделю.
На период работы. Можно спринтом обозвать. Не важно.
В целом по описанию у вас какой-то бардак получается. В котором все процессы по управлению зарыты где-то внутри, а сверху что-то прикручено для галочки и ИБД. Только в таком случае стендапы это не проблема, а лишь то, что делает ваши скрытые проблемы видимыми.
Здравствуйте, CreatorCray, Вы писали:
CC>эти модные методологии только под ногами путаются. Нормально работают прямые коммуникации и периодические sync митинги.
Забавно только одно. Эти "модные методологии" вот буквально про прямые коммуникации и периодические sync митинги.
Повторюсь, буквально один из принципов, который лежит под всеми этими модными фреймворками:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Ещё более забавен другой факт — ты ни разу не упомянул общение со своими пользователями, с клиентами. По твоему описанию, вы там варитесь внутри в своём соку, разрабатывая фичи в одиночку и исходя из собственного понимания того, что нужно пользователям. Либо ты упрощаешь всё до невозможности, либо просто не понимаешь всего, что находится над тобой и даёт тебе требования, которые ты реализуешь.
Здравствуйте, Pauel, Вы писали:
P>Цель скрама — сделать разработку предсказуемой.
Нет, цель скрама другая.
Если взять самоопределение скрама, то:
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.
Если перевести это на человеческий, то цель скрама — получить хоть сколь-нибудь полезный результат при решении сложных задач при помощи подстраивающихся под текущие условия процессов. Полезный результат не означает непременно работающий продукт. Например, знание, что вот это, то и то не приведёт тебя к желаемому — тоже полезный результат. Хоть и не настолько полезный, как получение желаемого.
P>С исследованием до самого конца вы этой предсказуемости не получите.
Т.к. предсказуемость не является целью скрама, это не является препятствием. Впрочем, к самому концу исследования предсказуемость уже должна быть. Ибо конец исследования — это приведение документации в порядок и повторные эксперименты, подверждающие результаты исследования.
P>Т.е. независимо от наличия спринтов или их отсутствия, как бы вы ни старались, вас это не приблизит к достижению целей основного проекта.
Это утверждение требует доказательства. И некоторых определений. Что такое "цели основного проекта" в контексте обсуждения?
P>Максимум, что вы можете добиться — большей прозрачности.
Прозрачность — это уже здорово и великолепно. Но это не максимум. Максимум, вдобавок к прозрачности, можно добиться ещё и быстрого изменения планов в зависимости от достигнутых промежуточных результатов. Вплоть до полной смены цели исследования.
P>Только зачем вам скрам для этого?
Если есть что-то ещё, работающее лучше, чем скрам — надо применять это. Что в таких условиях работает лучше, чем скрам?
P>По вашему, продуктовая разработка только в айти?
По-моему, разработка нового продукта включает в себя фазу исследования в условиях полной неопределённости. В начале проекта кроме самой идеи нет никакой информации.
Здравствуйте, Kernan, Вы писали:
K>Раз все тут продвинутые проеджекты, может посоветуете пару книг по операционному и проектному управлению, наверное.
Я не продвинутый и я ничего по книгам не посоветую, наверное.
Я считаю полезными PMBOK Guide, Agile manifesto, Scrum Guide. Их надо почитать, но уже после понимания основ и какого-то опыта. Как введение в тему они могут быть даже вредны, ИМХО.
Основы я лично осваивал через через практику/наставничество и обучающие курсы. У нас в компании есть несколько внутренних курсов по управлению проектами, плюс бесплатная подписка на udemy, на котором я нашёл интересные/полезные лично для себя курсы. Не сказал бы, что эти курсы прям что-то сверхценное, просто они пришлись очень кстати именно мне именно на том этапе. Если интересно, я поищу в истории, что именно за курсы это были. Плюс статьи, блоги, влоги.
Книги по управлению проектами я тоже читал, но не могу посоветовать ни одной, к сожалению. Может, кто-то другой посоветует.
Здравствуйте, sergey2b, Вы писали:
S>Здравствуйте, Артём, Вы писали:
Аё>>Смени деятельность, будь каа радостные коллеги. Но тебе же нравится ковыряться в C++- тогда не жалуйся.
S>я реально не понимаю как можно получать удвольствие от перекладывания байтов из базы на форму и обратно
S>я сейчас с желеозом вожусь, ставлю физические эксперементы, пишу софт, разбираюсь с драйверами S>и это все в рамках одной задачи
да, все здорово, но удовлетворения то нет
а может тебе в какой-нить локхид мартин? там железок много, ракеты или самолеты программировать можно, глядишь отладишь ф35 наконец
Здравствуйте, landerhigh, Вы писали:
L>Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года
Здравствуйте, Codealot, Вы писали:
L>>Но это в бесконечное число раз лучше неизбежного waterfall прикола, когда весь проект "все почти готово", а за неделю до дедлайна — аврал и срыв сроков на полтора года C>Ложная дилемма.
Может, в иной вселенной и ложная. В нашей дело обстоит именно так.
Вот, в соседней ветке зявили, что скрам работает плохо на задачах с неопределенностью. Мы спросили, в сравнении с чем. Но автора и след простыл.
L>Я делюсь своим опытом, где скрам сработал именно так. И добиться большей прозрачности — это уже сама по себе очень серьезная ачивка.
Писал об этом еще с 2007. Равно как и о том, что сия прозрачность зачастую противоречит интересам участников процесса поэтому внедрение методики испытывает жестокие фейлы.
_AB>Основы я лично осваивал через через практику/наставничество и обучающие курсы.
В моем случае курсы и прочие обучения сами по себе не дали особой пользы.
Зато полтора года реальной работы со скрам (в основном как product owner), плюс еще дольше часть meta-scrum команды, можно сказать, что глаза раскрыли.
Здравствуйте, SkyDance, Вы писали:
SD>Скрам и подобия предназначены для командной работы, где предполагается, что упавшее знамя нужно подобрать немедленно, и тут же понести (другим членом команды).
И даже не только, и не столько в этом, а в том, чтобы создать эффективную модель сотрудничества в команде, когда все члены команды принимают участие в реализации любых тасков, а не отвлеченно пилят свой проект два года
SD>Применять скрам в одиночно-индивидуальной разработке (когда нет постоянных команд, есть лишь проектные группировки) смысла не имеет.
На самом деле, даже там стоит. чтобы ставить планы и не терять фокус.
Здравствуйте, gandjustas, Вы писали:
G>Детализация задач до размера одного дня и ежедневные стендапы позволят это узнать пораньше.
Не позволят, потому что обычно самые большие риски идут в конце, и ты скорее всего "успешно сделаешь" две трети задач, прежде чем вляпаться в непреодолимую проблему.
Попытки все спланировать только приводят к потере времени на собственно планирование и попытки следовать плану, и создают ложное чувство контроля, что еще хуже. Потому что самые опасные риски — это те, наличие которых ты не осознаешь.
Здравствуйте, landerhigh, Вы писали:
L>Может, в иной вселенной и ложная. В нашей дело обстоит именно так.
Пардон, но это просто чушь. Никто тебе не запрещает делать разработку поэтапно и ничего не планировать. Ну, кроме религиозных соображений.
На самом деле, пытаться все планировать — это характерная черта именно водопадной модели, а не ее противоположность.
Здравствуйте, _ABC_, Вы писали:
P>>Чем больше неопределенности, тем хуже работает скрам. _AB>Хуже по сравнению с чем работает скрам в таких условиях?
Чем канбан какой. Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Здравствуйте, _ABC_, Вы писали:
_AB>Ещё более забавен другой факт — ты ни разу не упомянул общение со своими пользователями, с клиентами. По твоему описанию, вы там варитесь внутри в своём соку, разрабатывая фичи в одиночку и исходя из собственного понимания того, что нужно пользователям. Либо ты упрощаешь всё до невозможности, либо просто не понимаешь всего, что находится над тобой и даёт тебе требования, которые ты реализуешь.
Нет у него ни пользователей, ни клиентов — он же системщик. Специфика труда, отсюда и особенности мировозрения.
Здравствуйте, landerhigh, Вы писали:
L>Вот, в соседней ветке зявили, что скрам работает плохо на задачах с неопределенностью. Мы спросили, в сравнении с чем. Но автора и след простыл.
Вы так торопитесь, что умным мыслям вас не догнать.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, no_ise, Вы писали:
_>>все они в нашем времени.
L>Между тем, что Вася может за пару недель на коленке нашедеврить...
Вася за пару недель на коленке не шедеврит. Вася делает нормальную инженерно-изобретательскую работу. Примеры я уже привел.
L>... до работающего продукта нынче — огромная пропасть. Просто в силу обстоятельств.
Это точно. В цеху требуется много специальностей. И всех нужно синхронизировать в один процесс, так работает завод. Там возможны свои процессы, порядки, и строгие бригадиры.
L>Речь идет не о самородках, которые выдают гениальные идеи, и которые в основном закончились в 90-е...
Ну хорошо, пусть не о самородках. Но откуда такое убеждение, что они закончились в 90-е. После 90-х кто остался то, непонятно.
L>...а о работающих продуктах, реализованнх в означенные сроки без сильного выхода из бюджета.
Так скрам и все такое подобное это подчастую и есть про то, как законно и на вполне
легальных основаниях затягивать сроки до бесконечности путем непрерывных улучшений
косячного фундамента. И про то, как грамотно тянуть из заказчика деньги до бесконечности.
Тут мне приходилось недавно быть заказчиком одной не-софтверной компании. Но скрам
и все стендапы там прям по этой методологии были. Еле отделался от них, пришлось
обращаться к юристам и судиться с ними, а то задолбали со своими 'обсудили на планерке'.
Юристы такой гадюшник, к счастью, знают как правильно прижать.
Кстати, эти исполнители тоже время от времени жаловались на отсутствие эндорфинов.
Ну, такой уж это мошеннический процесс, как мне кажется.
Здравствуйте, Pauel, Вы писали:
_AB>>Хуже по сравнению с чем работает скрам в таких условиях?
P>Чем канбан какой.
Канбан — это тот же скрам, только вид в другой проекции.
P>Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
Скрам в первую очередь про гибкость. Там есть вполне документированная процедура, которую следует применять, если "в первый же день выясняется, что все планы насмарку".
Не все нынешние скрам кучеры до нее дочитали, впрочем.
Здравствуйте, landerhigh, Вы писали:
_AB>>>Хуже по сравнению с чем работает скрам в таких условиях?
P>>Чем канбан какой.
L>Канбан — это тот же скрам, только вид в другой проекции.
Здравствуйте, SkyDance, Вы писали:
P>>Чем канбан какой. Неопределенность требует гибкости. Не совсем понятно, что в спринт тащить, не ясно, что делать, если в первый же день выясняется, что все планы насмарку.
SD>Первые 7-8 спринтов так и будет, ничего не понятно, планы не планируются, фичи делаются внезапно и т.п..
Здравствуйте, Министр Промышленности, Вы писали:
МП>возник спонтанный трёп, в ходе которого я случайным образом завладел вниманием толпы, перевёл тему в химию, химию цементов, и в итоге прочитал всем типа минилекцию про ~технологию заливки бетона (преднапряжённого)
Как там бункер поживает? Блин, тебе по идее можно не работать, завел бы блог типа "строю бункер" и "как я отшиваю девушек так как они не девственницы", и заимел бы до хрена подписчиков. Я б точно подписался .
Здравствуйте, landerhigh, Вы писали:
L>Если у вас в скрам проекта
У нас нету скрама.
L>Ну тогда скоро не будет и на квартал. А потом и на год. L>Примерно так загнивание выглядит.
Сколько уже загниваем а всё никак.
Здравствуйте, _ABC_, Вы писали:
_AB>Ну, умение сжато самому себе рассказать о том, чем ты занимаешься, для чего и есть ли у тебя какие-то зависимости от других, в чём заключается эти зависимости и знаешь ли ты, кто тебе может с ними помочь, чисто ИМХО, полезно прежде всего себе самому.
Для этого мне не надо митинг, внутренний диалог работает на порядки быстрее чем это всё проговаривать.
_AB>На период работы. Можно спринтом обозвать. Не важно.
Если обозвать спринтом то и будет потом обсуждение именно как спринта, только путаницы добавит.
_AB>Только в таком случае стендапы это не проблема, а лишь то, что делает ваши скрытые проблемы видимыми.
Нет, их прикрутили по указке сверху к совсем другой системе, где они никогда не были нужны и потому прижились как пятая нога на собаке.
Здравствуйте, _ABC_, Вы писали:
_AB>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Вот только это про 1:1 а не пятиминутка проратарорить на всех.
_AB>Ещё более забавен другой факт — ты ни разу не упомянул общение со своими пользователями, с клиентами.
Я в кернеле, я смотрю на телеметрию. Конечные пользователи вообще не понимают что там под капотом происходит. Спросить напрямую "что ж ты с девайсиной такое делал что её так расколбасило" нельзя ибо privacy — всё приходит анонимизированое просто вусмерть.
_AB>исходя из собственного понимания того, что нужно пользователям.
Из того, что нужно тем, кто нас использует из юзерленда и того же кернела, а это практически все свои.
Здравствуйте, landerhigh, Вы писали:
L>когда все члены команды принимают участие в реализации любых тасков
Для этого надо будет чуть ли не удвоить колво людей чтоб в те же сроки справляться.
L>На самом деле, даже там стоит. чтобы ставить планы и не терять фокус.
Скрам тут будет оверкилл и perf killer
Здравствуйте, baxton_ulf, Вы писали:
_>но даже при таком стендапе, таски создавались так, чтоб не более 3-4 дней на таск, все что больше сразу же разбивалось на мелкие субтаски. на исследования, если прям вот совсем надо провести, выделялся отдельный толи таск толи как-то еще назывался, но со своим лимитом времени. типа если за пару дней не получилось сделать как предполагали, то стоп — фиксируем прибыль/убыль. кстати похоже у Сереги с этим и проблема — не может он придти к босу и сказать: "ну не шмагла я"
Думаю проблема в том, что босс считает его сеньором, который может ставить задачи мидлам/джуниорам, а он бросается на амбразуру делать все сам. Не обижайся, Серег Просто мне так кажется.
Здравствуйте, Министр Промышленности, Вы писали:
МП>мой бункер наверно выдержит 2-3 артиллерийских попадания, но вряд ли поможет в случае щебекенизации территории
Народ просит слайды! Прошлые были вообще огонь, а с тех то пор много лет прошло.
МП>я посадил конечно картошку, но без бабок выживать будет тяжко МП>работу не нашёл даже с 40% дисконтом от довоенного времени
Практически все знакомые, потерявшие работу в связи с переездом офиса или уходом работадателя, работу нашли без особых проблем и как минимум без потери в деньгах. ХЗ, мож у тебя конечно миллионы зарплата была, но за ручное тестирование женскому полу 200 тысяч вполне платят сейчас, знания именно в ИТ околонулевые, но опыт именно тестирования да, есть.
Здравствуйте, Antidote, Вы писали:
_>>но даже при таком стендапе, таски создавались так, чтоб не более 3-4 дней на таск, все что больше сразу же разбивалось на мелкие субтаски. на исследования, если прям вот совсем надо провести, выделялся отдельный толи таск толи как-то еще назывался, но со своим лимитом времени. типа если за пару дней не получилось сделать как предполагали, то стоп — фиксируем прибыль/убыль. кстати похоже у Сереги с этим и проблема — не может он придти к босу и сказать: "ну не шмагла я"
+1
A>Думаю проблема в том, что босс считает его сеньором, который может ставить задачи мидлам/джуниорам, а он бросается на амбразуру делать все сам. Не обижайся, Серег Просто мне так кажется.
Серёжа в команде- единственный C++ ник среди дюжины жавистов. Причём, я подозреваю, что никто из коллег — жавистов не хочет прикасаться к C++. Серёжа не хочет бить фичу на подзадачи (или в команде так не принято, или не видел такого). А может, быть, что на подзадачи разбил, и завис на чём-то.
Висеть долго на подзадаче- нехороший признак. Значит, она не по зубам, или в принципе не решаема.
МП>>мой бункер наверно выдержит 2-3 артиллерийских попадания, но вряд ли поможет в случае щебекенизации территории E>Народ просит слайды! Прошлые были вообще огонь, а с тех то пор много лет прошло.
слайдов не будет по соображениям разного рода безопасности
МП>>я посадил конечно картошку, но без бабок выживать будет тяжко МП>>работу не нашёл даже с 40% дисконтом от довоенного времени E>Практически все знакомые, потерявшие работу в связи с переездом офиса или уходом работадателя, работу нашли без особых проблем и как минимум без потери в деньгах. ХЗ, мож у тебя конечно миллионы зарплата была, но за ручное тестирование женскому полу 200 тысяч вполне платят сейчас, знания именно в ИТ околонулевые, но опыт именно тестирования да, есть.
нет, дело обстоит не так
на вакансии C# разработчика на 180 часто приходил отказ сразу на отклик резюме
по причине избыточного числа кандидатов
это при том, что до войны я стабильно со своим резюме находил работу за 7-10 дней
(нашёл одну, ушёл в начале испытательного срока, и тут же нашёл другую тоже быстрее 10 дней)
почитайте темы в этом же разделе раз
Здравствуйте, Antidote, Вы писали:
A>Думаю проблема в том, что босс считает его сеньором, который может ставить задачи мидлам/джуниорам, а он бросается на амбразуру делать все сам. Не обижайся, Серег Просто мне так кажется.
такие ожидания надо заранее обговаривать.
о вообще падаваны это хорошо настрочил им тасков с критериями принятия и только знай себе их код ревьювить не жизнь а малина
Здравствуйте, Министр Промышленности, Вы писали:
МП>слайдов не будет по соображениям разного рода безопасности
Ну хоть текстом больше тем про бункер давай.Как там живется и все такое, сколько построек, появился ли туалет, окна.
МП>нет, дело обстоит не так МП>на вакансии C# разработчика на 180 часто приходил отказ сразу на отклик резюме МП>по причине избыточного числа кандидатов МП>это при том, что до войны я стабильно со своим резюме находил работу за 7-10 дней
Скорее по возрасту уже тебя футболят. И полу. Ибо от возраста ждут совсем других зарплатных ожиданий (более высоких и сильно более высоких, именно возрастные миддлы не нужны). Но знакомая мадам в принципе без проблем нашла на не меньшую зарплату, чем была, именно на C#. Контору не помню, софт для беспилотников пишут, выбирала из нескольких контор. При этом лично я бы по качеству выполненного тестового задания не взял бы, я тут даже тему помнится создавал, типа что, на шаре принято на ровном месте городить сложности? ЗП не интересовался, но что то я сомневаюсь что будет меньше чем у тестировщиц.
А если брать мужской, то пару человек где то на 500 ушло. Один в Газпром мобильным разработчиком (ранее он на двух работах работал), второй пошел из девопсов в big data тоже где то на 500, при этом особо без опыта именно в big data. Кстати еще на испытательном оба. Точную ЗП не скажу, не спрашивал, но ранее они работали на несколько работах и у них было около 500 в месяц, они искали третью работу, а тут нашли третью и уволились со старых, а нужно было им 500 минимум ибо не хватает на жизнь. Соответственно у меня возникло впечатление что сейчас ЗП сильно подросли.
Здравствуйте, sergey2b, Вы писали:
S>А если в компании больше нет человека который может помочь с задачей
S>У меня начальник например занял позицию S>Не можешь решить, тебе выделили время сиди решай
что вообще за задача? заставить железку работать? ну погружайся в порты и прерывания (какие я слова то помню, со времен молодости. видать до деменции далеко )
только подумай — соответствует ли уровень безграничной благодарности решаемой задаче
МП>>слайдов не будет по соображениям разного рода безопасности E>Ну хоть текстом больше тем про бункер давай.Как там живется и все такое, сколько построек, появился ли туалет, окна.
окна самое то создавать накануне то ли мародёрств то ли ядерных бомбёжек
E>Скорее по возрасту уже тебя футболят. И полу. Ибо от возраста ждут совсем других зарплатных ожиданий (более высоких и сильно более высоких, именно возрастные миддлы не нужны).
я думал от опыта ждут упорядоченной продуктивности
ну да ладно, я уже свыкся с вселенской невменяемостью HR и людишек вообще
нет, мне пришла через месяц-полтора поисков гипотеза о возрасте
убрал из резюме дату рождения — ситуация с откликами не поменялась
правда один раз рекрутёрша прямо спросила дату рожденияя, но это лишь 1 раз
E>Но знакомая мадам в принципе без проблем нашла на не меньшую зарплату, чем была, именно на C#. Контору не помню, софт для беспилотников пишут, выбирала из нескольких контор. При этом лично я бы по качеству выполненного тестового задания не взял бы, я тут даже тему помнится создавал, типа что, на шаре принято на ровном месте городить сложности? ЗП не интересовался, но что то я сомневаюсь что будет меньше чем у тестировщиц. E>А если брать мужской, то пару человек где то на 500 ушло. Один в Газпром мобильным разработчиком (ранее он на двух работах работал), второй пошел из девопсов в big data тоже где то на 500, при этом особо без опыта именно в big data. Кстати еще на испытательном оба. Точную ЗП не скажу, не спрашивал, но ранее они работали на несколько работах и у них было около 500 в месяц, они искали третью работу, а тут нашли третью и уволились со старых, а нужно было им 500 минимум ибо не хватает на жизнь. Соответственно у меня возникло впечатление что сейчас ЗП сильно подросли.
а речь о удалёнке из РФ? и о тысячах рублей?
дичь пишете, думаю это если есть, то носит характер тонкой прослойки на основном фоне
Здравствуйте, Министр Промышленности, Вы писали:
МП>окна самое то создавать накануне то ли мародёрств то ли ядерных бомбёжек
Ты там хотя бы живешь? За это время всякие особенности вроде плесени не появились?
МП>а речь о удалёнке из РФ? и о тысячах рублей? МП>дичь пишете, думаю это если есть, то носит характер тонкой прослойки на основном фоне
Нет, не удаленка, а офис. Хотя мобильная разработка в Газпром — там удаленка. И есть одно очень интересное правило. Когда ищешь именно удаленку, тебе ее хрен когда предложат. Обычно всегда хотят возможность физически прийти в офис. И если ты из другого региона, где у тебя нет возможности выбирать работодателя, к которому нужно ездить в офис — тут да, будут и занижать зарплаты и вообще браковать. А самое смешное, что когда приходишь в офис, оказывается что возможность работать удаленно вполне есть.
Так и в исследованиях будет похоже. Суть метода именно в том, чтобы набрать статистику. Дальше — проще: угадывать на 100% все равно не получится, но приблизительно — вполне, не на одном спринте, а "в среднем". Я сначала тоже не верил, что так будет, но, оказывается, человеки — весьма предсказуемая штука, если есть много статистики. Биг дата, черт бы их подрал.
Здравствуйте, _>что вообще за задача? заставить железку работать? ну погружайся в порты и прерывания (какие я слова то помню, со времен молодости. видать до деменции далеко )
Наоборот, деменция обычно вышибает кратковременную память, тогда как стишки, прерывания, порты и "mov ax, cx" отлично помянся.
МП>>окна самое то создавать накануне то ли мародёрств то ли ядерных бомбёжек E>Ты там хотя бы живешь?
по соображениям безопасности опять же такую информацию не предоставлю
E>За это время всякие особенности вроде плесени не появились?
первое время была тенденция образования чёрной плесени на картонных вещах и фанерах
и другой плесени на хранящейся одежде
позже я начал отапливать помещение, и частично сделал утепление со стороны пола,
и эта тенденция уменьшилась
думаю если доделать все строительные работы, то проблем не будет никаких
МП>>а речь о удалёнке из РФ? и о тысячах рублей? МП>>дичь пишете, думаю это если есть, то носит характер тонкой прослойки на основном фоне E>Нет, не удаленка, а офис.
ну в разгар мясопереработки по заказу глобалистов,
офис принципиально не рассматривался
E>И есть одно очень интересное правило. Когда ищешь именно удаленку, тебе ее хрен когда предложат. Обычно всегда хотят возможность физически прийти в офис. И если ты из другого региона, где у тебя нет возможности выбирать работодателя, к которому нужно ездить в офис — тут да, будут и занижать зарплаты и вообще браковать. А самое смешное, что когда приходишь в офис, оказывается что возможность работать удаленно вполне есть.
ну да, я в связи с трудоустройствами отрабатывал и более безумные гипотезы
думаю описываемое может иметь место, спасибо
единственное, во время ковидобесия удалёнку очень даже охотно предлагали как основной вариант
но теперь ситуация могла действительно откатиться обратно
Здравствуйте, Министр Промышленности, Вы писали:
МП>единственное, во время ковидобесия удалёнку очень даже охотно предлагали как основной вариант МП>но теперь ситуация могла действительно откатиться обратно
Теперь где я живу, тренд на 3 дня в офисе при условии, что коммютить 1.5 часа в один конец. Если 3 часа, тогда уважительная причина. А народ перебрался подальше. Ну я запасся попкорном за тех, кто в ковидобесие влез в ипотеку в 4 часах от Сиднея- такие при смене работы узнают много интересного.
МП>>единственное, во время ковидобесия удалёнку очень даже охотно предлагали как основной вариант МП>>но теперь ситуация могла действительно откатиться обратно
Аё>Теперь где я живу, тренд на 3 дня в офисе при условии, что коммютить 1.5 часа в один конец. Если 3 часа, тогда уважительная причина. А народ перебрался подальше. Ну я запасся попкорном за тех, кто в ковидобесие влез в ипотеку в 4 часах от Сиднея- такие при смене работы узнают много интересного.
а чем мотивируют такую политику?
по-хорошему, раз правящее закулисье имеет нагшлость проводить какую-то там политику,
пользуясь трудовыми потребностями граждан,
то разработческому сообществу не попкорном следовало бы,
а тоже вправлять работодателям и их хозяевам мозги ответной политикой
но увы, на примере в том числе RSDN я убедился,
что разработческое сообщество ведёт себя как аморфная масса говна в проруби,
и ни к какой организованной силовой деятельности не способна
а я последние места работы перед ковидобесием селился рядом с работой (в радиусе 1 — 1.5 км)
соответственно, если не полная удалёнка, то она не нужна и совсем
Здравствуйте, SkyDance, Вы писали:
P>>Я про исследования, а не просто разработку.
SD>Так и в исследованиях будет похоже.
В исследованиях у вас вообще всё непредсказуемо, а не только человеки. Разница с обычным продуктовым приложением в том, что в одном случае вы знаете более менее что класс задач более-менее решаем, и вам не надо заботиться о проверке большинства гипотез.
В исследованиях ровно наоборот — во первых, вы не знаете, а решаема ли задача, не знаете много чего другого. Соответственно, ваши планы будут ломаться довольно часто до тех пор, пока собственно не найдете ответ а решаема ли задача и каким путём.
Собственно в этот период скрамовские итерации особого смысла не имеют, т.к. вам постоянно приходится менять планы прямо на ходу, т.к. они будут меняться.
Здравствуйте, landerhigh, Вы писали:
L>Остальное — это детали, котоыре делают канбан более подходящим для операционных задач, а скрам — для проектных.
Исследование это как раз те самые операционные задачи. Регулярное повторяете одни и те же действия, поддерживаете процесс, периодически перестраиваете, ждете пока сложится пазл. Сложился — хорошо. Нет — надо работать дальше.
Предсказуемости вроде бы много — типа "прогоним тесты еще раз" стоит вам, условно, два дня. Но этот прогон не делает желаемый результат ближе, ни капельки.
Ведение эксперимента это вроде бы и проектная работа, но там полно всякого траблшутинга, суппорта итд, которые вырастают постоянно буквально из ничего.
Вот это и требует бОльшей гибкости, а не просто выдавание результата спринтами. Пока основной эксперимент не закончен, у вас вообще никакого результата нет.
Здравствуйте, Министр Промышленности, Вы писали:
МП>и эта тенденция уменьшилась МП>думаю если доделать все строительные работы, то проблем не будет никаких
Называется за 3 года строительные работы так и не были доделаны, получается, и особо нового ничего не построено? Хотя бы туалет то есть? А то, просто для сведения, в России за копейки или вообще бесплатно в глуши можно получить жилье на много порядков комфортнее твоего бункера, в который ты скорее всего вбухал неимоверное количество времени и денег.
Сам кстати завтра еду в черти какую глушь, где удобств не будет даже туалета типа сортир . Глушь недалеко от Москвы кстати, мож даже Москву-Сити сфотографировать смогу если погода позволит .
Здравствуйте, Министр Промышленности, Вы писали:
МП>а чем мотивируют такую политику?
Тем же, чем мотивировали принудительную работу из дома в ковидобесие- "ведущие компании мира как Амазон" так делают. У нас тут наложилось на переезд офиса- половина выиграла, другая половина работников потеряла.
МП>а я последние места работы перед ковидобесием селился рядом с работой (в радиусе 1 — 1.5 км)
Ну если жить аскетично, то да, из вещей только саквояж и комп переместить. Мне бы сейчас логично было бы жить где-нить на сассекс стрит вблизи радужной сцены в 500м от офиса, в километре от гугла, танчиков, атлассиана и т п.
Здравствуйте, Pauel, Вы писали:
P>Вы лучше расскажите, как вы будете спринты планировать, когда содержание меняется от каждого нового промежуточного результата.
Ликбез:
В методологии скрам планируется только один спринт (следующий). И планируется он на основании результатов текущего (закончившегося) спринта.
Серьезно, хватит заниматься перепевками Битлз по телефону, почитай уже основы, а?
Здравствуйте, sergey2b, Вы писали:
S>у нас например за каждую выполненную задачу начисляют баллы S>каждая команда набравшая меньше 50 баллов получает всенародное порецание на собрании команд Северной Америки
Там у вас кукурузники из соломы еще перед офисом никто не строит?
Здравствуйте, landerhigh, Вы писали:
L>Там у вас кукурузники из соломы еще перед офисом никто не строит?
нет, а в чем смысл ?
у нас практически перед оффисом корабль на котором подписавли первую американскую конституцию, если не ошитаюсь его лет 10 назад взрывали
L>Серьезно, хватит заниматься перепевками Битлз по телефону, почитай уже основы, а?
Да не поможет это, я тоже читал, и думал, что понимал, но реально осмыслил происходящее только через 7-8 месяцев работы с опытным тренером (тем самым "скрам коучем", да).
Самым сложным было осознание простоты происходящего процесса. Я все где-то искал подвох, старался быть умнее и т.п., а всего-то надо было накопить историю выполнения задач конкретно взятой командой. Ключевое тут именно "команда", если люди постоянно меняются, не факт, что будет хорошо работать.
Здравствуйте, Артём, Вы писали:
CC>>И правильно сделал Аё>Директора HR заменят через 1-3 года
C чего ты взял?
Аё> а проект нужно зафейлить?
Надо принести себя на алтарь долбоклюйства менеджмента, да!
Артёмка, работу работают за деньги. Если нет денег — все остальные сказки идут побоку.
Аё>Опытные прогеры не истерят
А сразу сваливают туда, где их ценят а не полощут мозги ерундой.
Здравствуйте, sergey2b, Вы писали:
S>нет, а в чем смысл ?
Да примерно такой же смысл, как и в баллах за задачи.
S>у нас практически перед оффисом корабль на котором подписавли первую американскую конституцию, если не ошитаюсь его лет 10 назад взрывали
Здравствуйте, landerhigh, Вы писали:
L>Ликбез: L>В методологии скрам планируется только один спринт (следующий). И планируется он на основании результатов текущего (закончившегося) спринта.
Капитан Очевидность? Вместо хорошего примера вы занимаетесь словоблудием. Я уже говорил — ресерч в софтварных проектах больше похож на ту самую операционную деятельность в силу того, что постоянно возникает непредвиденный траблшутинг, суппорт и постоянное обнуление планов.
Вы начинаете играть во все слова и называете все софтварные проекты ресёрчем Между тем ключевая разница в степени неопределенности и наличии той самой операционной деятельности.
Собственно, вы уже ответили, что Канбан это тоже Скрам. Т.е. есть спринты, нету их — для вас всё едино.
Здравствуйте, landerhigh, Вы писали:
P>>Вот например маленький ресёрч который я делал, длился полгода — закончился тем, что все варианты решения были забракованы. Не сильно ясно, чем здесь помогает скрам.
L>И, следовательно, скрам не нужен вообще от слова совсем, да?
На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
Здравствуйте, CreatorCray, Вы писали:
CC>C чего ты взял?
Наблюдения.
Аё>> а проект нужно зафейлить? CC>Надо принести себя на алтарь долбоклюйства менеджмента, да!
HR- это не продакт менеджмент. Они играются в свои игры, нужно с этой неизбежностью считаться. Они даде стараются как лучше, для кого-то. Но лучше бы не старались.
CC>Артёмка, работу работают за деньги. Если нет денег — все остальные сказки идут побоку.
А я не спорю за деньги. Разговор про то, стоит ли менять контору из-за политик отдела кадров. Так вот чисто моё imho- политики hr меняются, как времена года.
Аё>>Опытные прогеры не истерят CC>А сразу сваливают туда, где их ценят а не полощут мозги ерундой.
В теории. А на практике кое-кто держится за Эппл.
Здравствуйте, Pauel, Вы писали:
P>Капитан Очевидность? Вместо хорошего примера вы занимаетесь словоблудием. Я уже говорил — ресерч в софтварных проектах больше похож на ту самую операционную деятельность в силу того, что постоянно возникает непредвиденный траблшутинг, суппорт и постоянное обнуление планов.
Я уже (единственный в этой теме, кстати) привел хороший, конкретный пример из жизни. Полегче с обвинениями, пожалуйста.
P>Вы начинаете играть во все слова и называете все софтварные проекты ресёрчем Между тем ключевая разница в степени неопределенности и наличии той самой операционной деятельности.
Отделяем операционную деятельность от разработки.
Степень неопределенности совершенно не важна, важно само наличие оной.
P>Собственно, вы уже ответили, что Канбан это тоже Скрам. Т.е. есть спринты, нету их — для вас всё едино. P>Итого — вам есть чего добавить по существу?
Я уже достаточно добавил. По существу и из собственного опыта.
Здравствуйте, Pauel, Вы писали:
L>>И, следовательно, скрам не нужен вообще от слова совсем, да?
P>На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
Операционная деятельность — это работа по плану/инструкции.
Вести ресерч по плану — это делать все то же самое, что и раньше, в надежде на иной результат. Кажется, в медицине этому даже название есть.
Здравствуйте, landerhigh, Вы писали:
L>Отделяем операционную деятельность от разработки. L>Степень неопределенности совершенно не важна, важно само наличие оной.
Наоборот, очень даже важна. Не ясно, как планировать спринт если у вас полно операционной деятельности которая зависит от этой самой неопределенности.
Здравствуйте, landerhigh, Вы писали:
P>>На эти полгода — нет, не нужен, т.к. здесь в чистом виде операционная деятельность.
L>Операционная деятельность — это работа по плану/инструкции.
Необязательно. Траблшутинг, суппорт тоже сюда относятся.
L>Вести ресерч по плану — это делать все то же самое, что и раньше, в надежде на иной результат. Кажется, в медицине этому даже название есть.
А кто сказал что всё то же самое? Вы усиленно стараетесь подметить тему разговора.
Здравствуйте, Философ, Вы писали: Ф>Это не всегда возможно: иногда задачи бывают действительно сложные. Тогда в процессе их решения возникают подзадачи, а в процессе решения подзадач возникают ещё подзадачи, по несколько штук в день. Т.о. получается, что у тебя в работе будет стек задач.
я некоторое время "продолжаю наблюдение" за работой менеджмента и да, он сильно меняется и они там постоянно придумывают новые системы. на самом деле цель системы — снизить порог входа, чтобы все люди были взаимозаменяемы и любой, условно, с дипломом, точно так же работал, как тот кто половину проекта сам написал за пять лет.
пока что им это не удается. при разбиении задач на подзадачи все все время забывают, что задачи действительно постоянно связаны между собой и образуют достаточно сложный граф зависимостей. воспринимать каждую задачу просто в вакууме это переупрощение
Здравствуйте, Pauel, Вы писали:
P>Наоборот, очень даже важна. Не ясно, как планировать спринт если у вас полно операционной деятельности которая зависит от этой самой неопределенности.
Это уже анекдот про мужиков и японскую бензопилу.
Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Здравствуйте, landerhigh, Вы писали:
L>Это уже анекдот про мужиков и японскую бензопилу.
L>Если полно операционной деятельности, которая не дает вести разработку, то нужно поднимать вопрос с менеджментом о реогранизации работы.
Вот смотрите, есть два основных кейса в разработке с т.з. используемых технологий:
1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, вы не знаете ни примерную архитектуру, ни проблемы, не можете оценить перформанс, издержки на инфраструктуру итд.
В первом случае вы можете начинать прямо со скрама, именно под такие кейсы он и заточен
Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему. Находите, снова хотите брать чтото из баклога, а QA приходит и говорит что клиент(сервер) не может...
Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
Здравствуйте, Pauel, Вы писали:
P>1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
Нет, не пишем.
Зачем?
P>2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, P>вы не знаете ни примерную архитектуру,
Можем. И оцениваем
P>издержки на инфраструктуру итд.
Можем. И оцениваем.
P>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть.
Здравствуйте, landerhigh, Вы писали:
P>>1. вы пилите, условно, еще одну приложуху из того класса что пишут везде. Неопределенность минимальна и ограничена почти что исключительно заказчиком, то есть — архитектура, стек, основные проблемы известны еще до старта проекта. Проблем хватает, но про них почти всегда известно, что "ну, можно и обойти" или "вернемся позже"
L>Нет, не пишем. L>Зачем?
Затем, что деньги платят за готовый продукт который делает чтото полезное, а не просто код
P>>2. вы пилите приложение, навроде которого до вас никто еще не писал — здесь у вас риски вообще везде, не считая заказчика, P>>вы не знаете ни примерную архитектуру,
L>Знаем.
Если знаете, то это п1, который по вашим словам вы не пишете.
P>>ни проблемы,
L>Знаем/преполагаем/оцениваем.
см п1
P>>не можете оценить перформанс,
L>Можем. И оцениваем
см п1
P>>издержки на инфраструктуру итд.
L>Можем. И оцениваем.
см п1
P>>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть.
L>Это уже какой-то клинический случай, если честно.
Это вы решили пометать понты когда про п1 написали "не пишем". А потом все свели именно к п1.
Здравствуйте, SkyDance, Вы писали:
P>>Необязательно. Траблшутинг, суппорт тоже сюда относятся.
SD>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time.
Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев
Почему ресёрч похож на опрационную деятельность — уже показал
Итого — у вас общие слова, и ничего про планировоание спринта у вас нет
Здравствуйте, SkyDance, Вы писали:
P>>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться.
SD>Такова разработка любого продукта, кроме совсем уж тривиальных.
Еще раз — я говорю об исследованиях, а не продуктовых проектах. То есть — R&D, а не абы что вида "нагуглил либу и пример кода"
Вы мне талдычите как у вас хорошо было на продуктах. Можете себя не утруждать — это я и без вас знаю.
SD>Задача скрам — ограничить потери. Если в середине проекта
Тут есть некоторая путаница. В проектах может быть исследование. В исследовании какие то части могут быть вполне себе проектом. Из этого не следует, что исследование и проект это одно и то же.
Цель исследования — получить новое знание. Цель продуктового проекта — получить собственно сам продукт.
Отсюда ясно, что измеряемость результата в одном случае есть, в другом — нет. Сами догадатесь, где измерямости результата нет?
И планирование делается совершенно разными методами. В исследовании — процесс, операционная деятельность. Попытки планировать это проектными методами дают тупик.
Собственно в начале проекта у вас всё очень похоже на исследование, и именно поэтому скрам не работает. Вот дальше, когда неопределенность устранена, всё идет пучком.
Собственно хаос в начале проекта совсем необязательно будет — когда команда сработана, проект типовой, продукт овнер адекватный, вот этого хаоса у вас просто так не будет.
Здравствуйте, Артём, Вы писали:
CC>>То, что он описывает это не про HR, это как раз про менеджмент. Аё>Это может быть уровень CEO. Наскучит CEO эта техника "повышения производительности"- найдёт другого массовика-затейника.
мое субективное мнение, что уволили часть програаемров в США
практически выкеосили программеров и QA в Европе (продаж нет тк кризис у них, мне вот поручили сопровождать проект за немецкими программситами)
а все это с баллами придумали что бы стимулировать людей работать больше
Здравствуйте, Артём, Вы писали:
A>>Грабли у всех разные Аё>Сергей везде находит одинаковые
отчего же
у меня зарплата не как в FB но 98% вакансий в Бостоне отсеиваеться тк там меньше
последнии полтора года 90% пишу новый код и 10% баг фикс, обычно в США наборот
узнал много нового, изучил новомодныен технологии
Здравствуйте, sergey2b, Вы писали:
S>у меня зарплата не как в FB но 98% вакансий в Бостоне отсеиваеться тк там меньше S>последнии полтора года 90% пишу новый код и 10% баг фикс, обычно в США наборот S>узнал много нового, изучил новомодныен технологии
Тебе неугодить. Многие кто "абсолютно успешен на работе, не то что сергей2б", на самом деле 90% багфикс и они счастливы. А ты нет.
Здравствуйте, sergey2b, Вы писали:
S>Я не настолько циничен что бы черное называть белым
М.б. у тебя искажённое восприятие мира?
Я понимаю, что факт сокращений в отрасли и ннпосредственно в компании, портит мораль и вгоняет в депрессию. Ещё и события в Украине.
Но очередная смена компании разве может это исправить?
Здравствуйте, SkyDance, Вы писали:
SD>Сколько лет вы в индустрии, сколько уже видели разных проектов, как исследовательских, так и "продуктовых"? (отмечу, что "продуктовых" проектов не существует, если только речь не идет о типовых интернет-магазинах, которые здесь не обсуждаются).
Больше двух десятков лет. Первые десять — наукоёмкие, с теми самыми исследованиями. Последние 5 — уклон в R&D
P>>Вы мне талдычите как у вас хорошо было на продуктах. Можете себя не утруждать — это я и без вас знаю.
SD>Нет, я вам объясняю, что исследования тоже можно структурировать. И что по исследованиям тоже накоплена статистика. Каждый конкретный раз каждое конкретное исследование будет отличаться от предыдущих. Поэтому конкретный спринт будет отличаться от предыдущий.
Структурировать — можно. Только это делается другими методами, т.к. результат неизмеримый, а качественный. В скраме все приводят к попугаям. Исследование — процесс.
SD>Но на длинной дистанции все будет отлично видно.
Если вам заказали исследование вида "найдите обоснование что стекло лучше пластика", то да, будет видно, т.к. ответ вам уже дали, и исследования здесь по большому счету нет.
А если вам дают "какой материал наиболее пригоден для упаковки с т.з. А, Б и Ц" то здесь скрам просто так работать не будет.
Отдельные фазы исследования могут идти по скраму, например, создание инструмента для хранения и обработки результатов. Все в целом — хрен там, это процесс, операционная деятельность.
Пример: Вы прогнали какой то тест, получили результаты — ушел день.
На следующий день вы берете задачу не из баклога, как в скраме, а обрабатывате результаты. Грубо говря, у вас последовательность известная заранее — тесты, результаты, анализ, тесты, результаты, анализ. Хоть обскрамайтесь, у вас всё равно будет эта последовательность. Постоянно валится траблшутинг-суппорт — каждая аномалия уводит вас с этой последовательности.
Вот вылезла аномалия — например, эксперименты фейлятся после 8ми вечера. Опаньки — все планы на смарку, вся команда разбирается что за хрень. Смысла двигаться по баклогу — ноль. Зато это стандартная последовательность действий при аномалии.
P>>Цель исследования — получить новое знание. P>>Отсюда ясно, что измеряемость результата в одном случае есть, в другом — нет. Сами догадатесь, где измерямости результата нет?
SD>Скажем, "проверка гипотезы, что применение вот такой-то модели позволяет различить такой-то fraud от такого-то", — это очень даже результат.
Это результат, только он неизмеримый, а качественный — новое знание о применимости конкретной модели. Дальше вы можете стартовать проект, запилить прототип приложение которое будет именно это и демонстрировать.
Первая часть — операционная деятельность, процесс. Вторая часть — уже проект с вашим скрамом. Вы же хотите обскрамить всё подряд, не глядя на принципиальные различия.
P>>И планирование делается совершенно разными методами. В исследовании — процесс, операционная деятельность. Попытки планировать это проектными методами дают тупик.
SD>Вы это утверждаете, так и не попробовав.
Вы так и не поделились примером планирования операционной деятельности по скраму.
SD>Вообще-то, в середине проекта он был pivoted на совсем другие рельсы, так что неопределенность подпрыгнула до потолка. Собственно, и сам pivot случился потому, что стало ясно — с нынешней velocity мы ну никак не доберемся до feature complete к ожидаемой дате. Скрам вам не создаст определенность, его задача — примерно как у телеметрии (counters): записать реальную статистику, и на основе этой статистики прогнозировать.
Здравствуйте, _ABC_, Вы писали:
_AB>Основная проблема в том, что багфикс в принципе — не проектная деятельность, а операционная. Поэтому любая методология управления проектами плохо для неё подходит. Да, багфиксингом приходится заниматься и в ходе реализации проекта, разумеется, но тут скрам ничем не хуже других моделей, даже, возможно, получше. _AB>А если проект уже сдан в эксплуатацию и команда перешла в режим операционной деятельности (поддержки продукта, если нашим языком), то применять для неё систему управления проектами просто глупо. Тут, как подсказывает landerhigh, куда удобнее системы управления операционной деятельностью — тот же канбан, например.
Не силен в обоих, но правильно ли я понимаю, что scrum для проектной деятельности подходит, а kanban -- для операционной?
Т.е. когда только реализуем систему, т.е. проектная деятельность, то scrum лучше, после релиза, поддержка
жизненного цикла, т.е. операционная деятельность, kanban лучше?
Здравствуйте, SkyDance, Вы писали:
P>> В скраме все приводят к попугаям. Исследование — процесс.
SD>Какая связь между этими двумя предложениями? Пусть исследование — процесс. Он не атомарен, в процессе исследований всегда есть какие-то промежуточные точки, вехи, результаты. Попугаи нужны лишь для прикидки сложности. Которая, статистически, транслируется в среднее время выполнения.
Вы все это описываете общими словами, по которым вроде как все складно выходит, но все больше и больше напоминает сферического коня в вакууме. Можно ли расписать как бы вы видели применение скрама для таких вещей, как разработка (относительно) новых языков программирования на начальных этапах? Возьмем, к примеру, Rust времен 2006-2009 годов, язык Go образца 2008-го года, Kotlin от 2010-го, или идущие сейчас работы над Cpp2 (cppfront) и Carbon. Ну или Zig, Nim или Crystal.
Причем интересен именно начальный этап, когда у кого-то появляется некая еще не формализованная идея о том, какими свойствами будет обладать новый язык.
Ведь когда основные контуры языка уже сформировались и встал вопрос в реализации стандартной библиотеки и инструментария для него, тут уже применимость хоть скрама, хоть канбана, хоть еще чего-нибудь из agile, понятно. А вот когда язык рождается в муках, вот где здесь место процессам и какая от них польза?
Можно вспомнить, как колбасило тот же Rust, где то был GC, то нет, то хотели делать actors прям на уровне языка, то нет, то не знали как сделать контроль за временем жизни, то придумали borrow checker. Или же можно вспомнить процесс добавления генериков в языки вроде Java и Go. Там же все не быстро и не просто шло. Вот и интересно, как какая-нибудь просветленная гибкая методология (тот же скрам) способствую появлению идей, вроде тех, которые позволили внедрить генерики в Java и Go.
А если рождению идей не способствует, то зачем все сопутствующие измерения? Чтобы на 10-ом спринте узнать, что бежим не туда?
А почему вы решили, что не туда? Результата пока нет, а затраты уже составили N*10k$? Так может вы сейчас в точке локального минимума. И не более того.
Здравствуйте, SkyDance, Вы писали:
SD>Можно уточнить, что есть "те самые исследования", на конкретных примерах? Коммерческие компании не так и часто занимаются наукоемкими исследованиями.
Исследование — найти точный алгоритм с заданной вычислительной сложностью, или доказать, что такого не существует, и найти приближенный алгоритм с такой то точностью, или доказать, что такого не сущетсвует, и найти другое решение...
> А в некоммерческих НИИ я что-то не припомню применения методологий разработки софта.
Ну вот и подумайте, что это значит.
P>>Структурировать — можно. Только это делается другими методами, т.к. результат неизмеримый, а качественный.
SD>Результат, повторю в четвертый уже раз, очень даже измеримый. Результат — это не обязательно открытие мирового уровня.
В любом случае в исследовании результат качественный, а не количественный. Например — доказательство, что точное решение задачи сводится к np полной задаче.
Никакими попугаями это не меряется.
SD>Какая связь между этими двумя предложениями? Пусть исследование — процесс. Он не атомарен, в процессе исследований всегда есть какие-то промежуточные точки, вехи, результаты. Попугаи нужны лишь для прикидки сложности. Которая, статистически, транслируется в среднее время выполнения.
Вы никак не приведете пример, как же спринт планировать. Во всех мануалах по скраму говорится, что он не подходит для планирования операционной деятельности. А исследование почти все делается по инструкции — нашли аномалию, сразу знаем, что делать. Нашли нормальный результат — тоже. Как обработать результаты — снова инструкция.
Вы хотите втащить скрам туда, куда его совать не нужно — в операционную деятельность. Здесь разновидности Канбана работают гораздо лучше.
Вы поймите — в операционной деятельности заранее нет никаких тикетов, что вы в спринт планировать собрались? Покажите уже чудо планирования работы колл-центра посредством спринтов.
Попробуйте распланировать по спринтам исследование неудовлетворенного спроса. Всё просто — рассылаете карточки на торговые точки, просите продавцов и покупателей ставить галочки.
Валяйте, покажите, как тут работает ваш скрам.
SD>Почему не будет? Как раз для подобных исследований скрам вполне годится. Более того, он потребует формализации процесса — придется вспомнить, какие именно шаги предпринимаются в процессе исследования.
Это и без скрама известно. Типовое исследование — все шаги известны заранее. Что вы в спринт толкать будете? "понедельник", "вторник", "среда"? Или может "ждать аномалию" ?
SD>Я понимаю, когда неохота заниматься формализацией процесса,
В который раз говорю — покажите чудо планирования деятельности колл-центра посредством скрама. Колл-центр — это что бы вам понятно было, что такое операционная деятельность.
В исследовании полно именно такой работы — например, исследование неудовлетворенного спроса это ровно тот самый колл-центр.
Вот и покажите, как вы здесь блеснете скрамом, как будете подзадачи нарезать. "понедельник — ждем репортов от операторов"
SD>Потому что операционная деятельность присутствует всегда, и ее легче прогнозировать на основе имеющейся истории.
Именно по этому есть вещи эффективнее Скрама — тот же Канбан
P>>Зато это стандартная последовательность действий при аномалии.
SD>Вы понимаете, что сейчас сами написали? "СТАНДАРТНАЯ АНОМАЛИЯ"!
Я пишу — стандартная последовательность, а вы читаете — стандартная аномалия. Стандартная последовательность при аномалии — задокументировать результат, обработать, найти причину. Идете исключительно по методике, а не валяете что в голову менеджеру взбредет.
P>>Это результат, только он неизмеримый, а качественный — новое знание о применимости конкретной модели.
SD>Результат "да/нет" — вполне себе измеримый. Тип boolean
Я вам говорю про новое знание, а у вас это сразу boolean. Похоже, у вас исследования дальше гугла не бывают. Или нашли, или нет — boolean!!!!1111111
P>>Вы так и не поделились примером планирования операционной деятельности по скраму.
SD>Я предположил, что вы имеете представление о том, как работает скрам (и что такое available time), но, видимо, ошибся. Операционная деятельность именно так и планируется:
Нет, не так — никаких спринтов, никаких тикетов заранее у вас нет. Потому вам не на чем планировать спринт.
> вы знаете, что в среднем (за последение 10 спринтов) у вас 40% времени команды уходило на эту деятельность. Значит, во время planning вы принимаете этот показатель в расчет (инымы словами, оставляете 40% буфер на каждый спринт, — в некоторые спринты он не понадобится, в некоторые будет использовано больше, но В СРЕДНЕМ все равно получится 40%).
Вот-вот, тот самый карго-культ. Активность колл-центра, активность покупателей вы смешали с велосити команды. Браво!
Здравствуйте, _ABC_, Вы писали:
K>>или багфикса. _AB>Основная проблема в том, что багфикс в принципе — не проектная деятельность, а операционная. Поэтому любая методология управления проектами плохо для неё подходит.
Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности. Т.е. когда тикеты нужно фиксить сразу по мере их появления. Здесь нечего пихнуть в спринт — баклог пустой. Завтра уже чтото появится, и завтра его снова выкачаем досуха. В понедельник все что знаем, это что будет тикетов от 1 до N.
А если багфикс не срочный, скажем, с выдержкой в пару месяцев, то разницы с фичами особо никакой нет, аномалии выстреливают довольно редко. Накидал в спринт десятка два тикетов, из них закрыл 15, остальные передвинулись в следующий спринт, и сверх этого вылезло три срочных бага. В таком варианте скрам вполне себе работает.
Здравствуйте, _ABC_, Вы писали:
P>>Т.е. когда тикеты нужно фиксить сразу по мере их появления. _AB>Вообще говоря, если мы говорим о скрам и о проектах, то там "тикетов" нет. _AB>И я не очень понимаю, зачем они нужны именно вам. Что вы под ними понимаете?
Тикет это конкретный баклог айтем.
P>>Здесь нечего пихнуть в спринт — баклог пустой. _AB>Как пустой, если вы "тикетами" занимаетесь? Ничего, что эти "тикеты" — это вполне себе backlog items?
Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
Здравствуйте, Pauel, Вы писали:
P>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
Абсолютно так же, как все заносят возможное падение метеиорита прямо на дата центр.
Здравствуйте, _ABC_, Вы писали:
P>>Почему ресёрч похож на опрационную деятельность — уже показал _AB>Честно говоря, я не убеждён, что ресёрч похож на операционную деятельность.
А вы посмотрите, например, исследование неудовлетворенного спроса. Основная работа у вас будет "ждать отчетов от продавцов и покупателей", на каждый отчет реагируете по инструкции — задокументировать. И так до тех пор, пока не накопится нужное количество сведений, что бы у вас сложился пазл. Далее, обрабатываете резльтаты, выводите закономерности, снова все последовательно, по инструкции, и предоставляете финальный результат.
>Я, конечно, не настоящий сварщик, но в моём понимании исследование имеет цель (причём цель — это получить новое, неизвестное), имеет сроки, имеет бюджет. Другими словами — это проект ну просто тупо и буквально по определению слова "проект".
Путаницы много, проект и исследование это два родственных подхода к организации деятельности. При этом, некоторые части исследования могут быть проектом. Некоторые части проекта могут быть исследованием.
Проект — создать, построить, достичь. Исследование — узнать, изучить, получить сведения. Хитрые менеджеры начинают играть в слова и формулируют исследование как проект "достичь такого, что бы стекло было лучше бумаги", "создать новую формулу в которой бумага будет лучше стекла"
В обычном проекте у вас решение вообще говоря известно заранее. А если это типовой проект, то там чуть не вообще всё будет известно.
В исследовании у вас решение заранее неизвестно, потому планировать от цели, как в проекте, вы не сможете.
А если вы обскрамаете исследование неудовлетворенного спроса, то вы смешаете статистику на основе активности покупателей-продавцов со стастистикой велосити конкретно вашей команды.
Здравствуйте, Pauel, Вы писали:
P>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день.
Так troubleshooting или support? Это совсем не синонимы, хоть и пересекающиеся понятия.
P>Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться. P>Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом.
А какова была цель спринта-то?
P>Следующий спринт вы получаете тож самое — вы запилили прототип клиента, только собираетесь брать очередной тикет из баклога, а тестировщики прибегают и орут "ужос, клиент не работает, валится стабильно после 8ми вечера"(реальный кейс). Вы бросаете всё и ищете проблему, проблема в том, что есть бага, которая пофиксана только для свежей ос, а поддерживать надо всё, на чем будут потенциальные юзера. Ищете фикс, пока ищете — ваш баклог на паузе. Нашли, только собираетесь взять тикет из баклога, снова прибегает QA и говорит, что клиент валится гарантировано в течение 30 минут(реальный кейс). Снова бросаете всё, ищете проблему. Находите. Только собираетесь брать тикет из баклога, QA прибегает и говорит, что работает только на виртуалке(снова реальный кейс). Вы снова бросаете баклог, ищете проблему.
У меня несколько вопросов.
1. А почему вы прототип пытаетесь вылизать до состояния production ready?
2. Чем это всё принципиально отличается от проблем проекта типа "вы пилите, условно, еще одну приложуху из того класса что пишут везде", к которым скрам, по твоим словами, очень даже подходит? Там QA, думаешь, не прибегают вот с весьма похожими проблемами каждый спринт, если работу организовать точно так же?
P>Итого — потрачено куча спринтов, в каждом из которых план ломается прямо на первый-второй день.
Вообще говоря, у спринтов нет планов, чтобы они ломались прямо на первый-второй день. У них есть цель и есть scope. Причем, scope может изменяться в любую сторону, если при этом не ставится под удар цель спринта. Если же у вас куча спринтов подряд спланирована так, что цель становится явно недостижимой на первый-второй день, то, ИМХО, это не проблема скрама, а проблема его применения.
P>В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания.
А если применять канбан, который вообще не отслеживает, двигаетесь ли вы к достижению цели, то вероятность того, что бюджета хватить на ваши изыскания возрастает за счёт чего, прости?
Это если не упоминать того, что канбан может применяться совместно со скрамом?
Здравствуйте, landerhigh, Вы писали:
P>>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
L>Абсолютно так же, как все заносят возможное падение метеиорита прямо на дата центр.
Подробнее. Это та самая операционная деятельность. Как её провести через скрам?
Здравствуйте, _ABC_, Вы писали:
P>>Во втором случае у вас по естественным причинам возникает траблшутинг/суппорт буквально каждый день. _AB>Так troubleshooting или support? Это совсем не синонимы, хоть и пересекающиеся понятия.
Какая разница? И то и другое срочные активности. Траблшутинг — падает стейджинг, нужно исправить. Суппорт — пришел тикет от клиента, нам нужно подобрать воракараунд и после него выдать патч релиз в течение недели. Или так — позвонили клиенты, запросили консультацию по фичам А, Б и Ц.
P>>Например — вы запилили прототип сервера, ушло один день. Далее у вас цепочка непредсказуемых фейлов, и вам нужно это всё побороть. Каждый фейл нужно рассматривать как новый, неизвестный ранее риск для которого нужно понять, как быть — игнорировать, или как то подстраховаться. P>>Поскольку вы ничего про это не знали, ваш спринт накрылся медным тазом. _AB>А какова была цель спринта-то?
А разве это принципиально? Ну вот нужно продемонстрировать фичу X. Цель спринта недостигнута.
_AB>У меня несколько вопросов. _AB>1. А почему вы прототип пытаетесь вылизать до состояния production ready?
production ready это ваша интерпретация. Я описал просто один из этапов когда мы пытались построить новую архитектуру в тот период, когда аналогичных проектов просто не было.
_AB>2. Чем это всё принципиально отличается от проблем проекта типа "вы пилите, условно, еще одну приложуху из того класса что пишут везде", к которым скрам, по твоим словами, очень даже подходит? Там QA, думаешь, не прибегают вот с весьма похожими проблемами каждый спринт, если работу организовать точно так же?
Прибегают гораздо реже. Я взял пример из совсем нетипового проекта.
_AB>Вообще говоря, у спринтов нет планов, чтобы они ломались прямо на первый-второй день. У них есть цель и есть scope.
По моему вы в слова играете, scope и есть тот самый план.
P>>В конце, если задачи решаемые, вы найдете примерную архитектуру приложения, только далеко не факт, что бюджета хватит на ваши изыскания. _AB>А если применять канбан, который вообще не отслеживает, двигаетесь ли вы к достижению цели, то вероятность того, что бюджета хватить на ваши изыскания возрастает за счёт чего, прости?
Если применять канбан, то не надо держаться за план спринта, за его цель, что добавляет гибкости.
_AB>Это если не упоминать того, что канбан может применяться совместно со скрамом?
Я не сильно понимаю, как можно совмещать спринты с их отсутствием.
P>>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог? _AB>Никак. "У юзеров" — это не часть проекта. Это эксплуатация. Решается в рамках операционной деятельности, SLA и т.д. и т.п.
Откуда SLA возьмется на стейджинге?
_AB>Ты же, вроде, говорил о создании того, что никто раньше не делал? Откуда юзеры взялись?
Я процитирую чуть выше, вы говорили про багфикс. Я вам про него и ответил
Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности. Т.е. когда тикеты нужно фиксить сразу по мере их появления. Здесь нечего пихнуть в спринт — баклог пустой. Завтра уже чтото появится, и завтра его снова выкачаем досуха. В понедельник все что знаем, это что будет тикетов от 1 до N.
А если багфикс не срочный, скажем, с выдержкой в пару месяцев, то разницы с фичами особо никакой нет, аномалии выстреливают довольно редко. Накидал в спринт десятка два тикетов, из них закрыл 15, остальные передвинулись в следующий спринт, и сверх этого вылезло три срочных бага. В таком варианте скрам вполне себе работает.
Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
Если у вас только такие срочные активности, то непонятно, что в планирование спринта выносить. И разницы нет, багфикс это, траблшутинг, суппорт или еще чего.
А если не срочно, то можно и траблшутинг отложить на время. Тогда можно и спринты, и снова не важно, что это — багфикс, траблшутинг, суппорт.
То есть, скрамать вы можете в том случае, когда доля срочных задач и прочей операционной деятельности невысока, и цель спринта достижима и это условие не ломается.
Здравствуйте, landerhigh, Вы писали:
L>По итогам этого спринта команда принимает предложение Васи. Его хлопают по плечу, берут автографы, целуют в десна. В проект добавляется новый epic "Вычисления в фоновом режиме".
Это маленькое исследование, оно вполне может быть частью проекта.
L>Вот это — слегка модифицированный (имена изменены) пример прикладного исселедования из жизни. Удалось ли решить задачу "улучшения алгоритма"? Нет. Удалось ли решить эту задачу с точки зрения успеха проекта? Более чем.
Я уже говорил, что исследование может быть частью проекта, а проект — частью исследования. А вы идете дальше, и рассказывает, что исследование == проект.
Попробуйте обскрамать исследование неудовлетворенного спроса, ну или социологического исследования, которое длится не полдня-день, а год-два-три.
Так и вижу — цель спринта, получить часть результатов от продавцов и покупателей,
Тикеты, или, кому непонятно, баклог айтемы "понедельник", "вторник"...
По такой схеме у вас будут одни и те же спринты, с одним и тем же наполнением все год-два-три. На кой ляд они нужны?
Здравствуйте, Pauel, Вы писали:
P>Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
Вот тут умываю руки, подобный бардак никаким скрамом не исправить.
Здравствуйте, landerhigh, Вы писали:
P>>Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
L>Вот тут умываю руки, подобный бардак никаким скрамом не исправить.
Здравствуйте, Pauel, Вы писали:
P>А вы посмотрите, например, исследование неудовлетворенного спроса.
Это который "анализ"?
P>Основная работа у вас будет "ждать отчетов от продавцов и покупателей", на каждый отчет реагируете по инструкции — задокументировать. И так до тех пор, пока не накопится нужное количество сведений, что бы у вас сложился пазл. Далее, обрабатываете резльтаты, выводите закономерности, снова все последовательно, по инструкции, и предоставляете финальный результат.
Ага, точно анализ. Вопрос был про research, а не про analysis.
P>Путаницы много, проект и исследование это два родственных подхода к организации деятельности. При этом, некоторые части исследования могут быть проектом. Некоторые части проекта могут быть исследованием.
Извини, но я не сторонник словоблудия.
P>Проект — создать, построить, достичь.
Нет, не создать, не построить. Именно, что "достичь". Если конкретнее, что достичь чего-то нового в ограниченные сроки и за ограниченные ресурсы.
P>Исследование — узнать, изучить, получить сведения.
1. Ну и как в твои исследования проникают "работает только на виртуалке", и "у юзеров сервер упал"? Я вот это понять не могу для начала.
2. На практике исследования более-менее заметных масштабов (не анализ спроса и им подобные в рамках операционной деятельности) имеют цель, имеют ограничение по срокам и по ресурсам. И перестают чем-либо отличаться от проектов.
P>А если вы обскрамаете исследование неудовлетворенного спроса, то вы смешаете статистику на основе активности покупателей-продавцов со стастистикой велосити конкретно вашей команды.
А что случится, если в ответ на что такое ресёрч тебе приведут пример анализа?
И вообще, как твоё предыдущее определение "Исследования это решение проблемы вида: неизвестно а можно ли сделать, а как вообще стоит сделать, а какие будут требования к этому" укладывается в "ждите отчёта по инструкции, документируйте по инструкции, сложите пазл, следуя инструкции"?
Здравствуйте, _ABC_, Вы писали:
P>>Основная работа у вас будет "ждать отчетов от продавцов и покупателей", на каждый отчет реагируете по инструкции — задокументировать. И так до тех пор, пока не накопится нужное количество сведений, что бы у вас сложился пазл. Далее, обрабатываете резльтаты, выводите закономерности, снова все последовательно, по инструкции, и предоставляете финальный результат. _AB>Ага, точно анализ. Вопрос был про research, а не про analysis.
А вы видели исследование в котором анализа результатов нет? Анализ это обработка данных, интепретация результатов, итд. Это часть исследования.
В исследовании неудовлетворенного спроса вам понадобятся обе части, и анализ будет самой короткой и предсказуемой частью. А вот сбор — в чистом виде операционная деятельность.
P>>Путаницы много, проект и исследование это два родственных подхода к организации деятельности. При этом, некоторые части исследования могут быть проектом. Некоторые части проекта могут быть исследованием. > Извини, но я не сторонник словоблудия.
Здесь нет никакого словоблудия:
1. каждый эксперимент в исследовании может выделяться в конкретный проект со вполне достижимой целью. Например — создать броневую плиту на основе xxx.
2. проект может содержать в себе исследование, например — выяснить оптимальные условия отжига.
P>>Исследование — узнать, изучить, получить сведения. _AB>1. Ну и как в твои исследования проникают "работает только на виртуалке",
Я привел пример нетипового проекта, когда негде было подсмотреть архитектуру, подходы, ограничения и бОльшую часть требований. Здесь было полно ресерча который длился не день-два, а недели и месяцы.
> и "у юзеров сервер упал"? Я вот это понять не могу для начала.
А это пример из r&d
P>>А если вы обскрамаете исследование неудовлетворенного спроса, то вы смешаете статистику на основе активности покупателей-продавцов со стастистикой велосити конкретно вашей команды. _AB>А что случится, если в ответ на что такое ресёрч тебе приведут пример анализа?
Раз вы запутались, я вам помогу:
Research is the process of finding information, while analysis is the process of evaluating and interpreting that information to make informed decisions
Здравствуйте, Pauel, Вы писали:
P>Я уже говорил, что исследование может быть частью проекта, а проект — частью исследования. А вы идете дальше, и рассказывает, что исследование == проект. P>Попробуйте обскрамать исследование неудовлетворенного спроса, ну или социологического исследования, которое длится не полдня-день, а год-два-три. P>Так и вижу — цель спринта, получить часть результатов от продавцов и покупателей, P>Тикеты, или, кому непонятно, баклог айтемы "понедельник", "вторник"... P>По такой схеме у вас будут одни и те же спринты, с одним и тем же наполнением все год-два-три. На кой ляд они нужны?
Мне осталось добавить одно:
People Who Say It Cannot Be Done Should Not Interrupt Those Who Are Doing It
Здравствуйте, Pauel, Вы писали:
L>>Вот тут умываю руки, подобный бардак никаким скрамом не исправить. P> Похоже, вам с самого начала было нечего сказать.
Я единственный в этой теме приводил конкретные примеры из собственной практики.
Здравствуйте, landerhigh, Вы писали:
L>>>Вот тут умываю руки, подобный бардак никаким скрамом не исправить. P>> Похоже, вам с самого начала было нечего сказать.
L>Я единственный в этой теме приводил конкретные примеры из собственной практики. L>Полегче на поворотах.
Вы старательно обходите другие примеры, потому у вас иллюзия, что примеры приводите только вы один.
S>Вы все это описываете общими словами, по которым вроде как все складно выходит, но все больше и больше напоминает сферического коня в вакууме.
Потому что, в отличие от оппонентов, я не столько теоретик, сколько практик: мне довелось поучаствовать во всех этих процессах в разных ролях. Мое мнение, поначалу тоже скептическое "да как это может работать", через "хм, а ведь работает" сменилось на "ага, понятно, почему оно работает, и какие есть ограничения".
S>Причем интересен именно начальный этап, когда у кого-то появляется некая еще не формализованная идея
Но шаги по превращению идеи в реальности все равно будут сделаны. И в большинстве случаев они известны, и зачастую понятны. Их можно отранжировать по ожидаемой сложности. Далее см. мое предыдущее сообщение, а также этот тред
, или любой другой аналогичный, где я уже объяснял, как работают определенные части процесса.
S>А если рождению идей не способствует, то зачем все сопутствующие измерения? Чтобы на 10-ом спринте узнать, что бежим не туда?
Если все сводить к "я хочу чтоб было весело заниматься прикольными штуками, а бизнес пусть мне платит за мое веселье", то скрам не нужен. И даже вреден, т.к. станет ясно, что люди работают не на бизнес, а для саморекламы или фана.
Здравствуйте, SkyDance, Вы писали:
SD>Потому что, в отличие от оппонентов, я не столько теоретик, сколько практик: мне довелось поучаствовать во всех этих процессах в разных ролях. Мое мнение, поначалу тоже скептическое "да как это может работать", через "хм, а ведь работает" сменилось на "ага, понятно, почему оно работает, и какие есть ограничения".
Нет, мой интерес не в том, чтобы выяснить работает ли скрам вообще. Сомнения вызывает именно что применение его для исследовательских проектов.
Но тут, полагаю, проблема в том, что никто не удосужился привести определение понятию "исследовательский проект".
S>>Причем интересен именно начальный этап, когда у кого-то появляется некая еще не формализованная идея
SD>Но шаги по превращению идеи в реальности все равно будут сделаны. И в большинстве случаев они известны, и зачастую понятны.
Да? Ладно, допустим, всегда будут шаги вроде "посмотреть по сторонам и понять, что уже делали" и "определиться откуда и куда будем стартовать". Мне непонятно как в спринты будут запихивать задачи типа "родить способ контроля повисших ссылок". И зачем это делать.
SD>И даже вреден, т.к. станет ясно, что люди работают не на бизнес, а для саморекламы или фана.
Можно нескромный вопрос: вы вели исследовательские проекты за собственный счет?
S>Но тут, полагаю, проблема в том, что никто не удосужился привести определение понятию "исследовательский проект".
Согласен с этим утверждением.
Начинаю думать, что "исследовательский" проект — это когда бесконечный бюджет и время, и вообще не для бизнеса, а чтоб было интересно работать.
В таких проектах скрам не нужен, т.к. только отвлекает от цели (интересной работы), потому что требует планировать, разбивать на отрезки и т.п..
S>Да? Ладно, допустим, всегда будут шаги вроде "посмотреть по сторонам и понять, что уже делали" и "определиться откуда и куда будем стартовать". Мне непонятно как в спринты будут запихивать задачи типа "родить способ контроля повисших ссылок". И зачем это делать.
А что не так с этими задачами? То, что с самого начала непонятно, как подступиться? Так это значит, что задача слишком большая (эпик), и нужно ее разбить на чуть более понятные шаги (те самые "погуглитьт", "составить список идей", "написать приемочные тесты").
S>Можно нескромный вопрос: вы вели исследовательские проекты за собственный счет?
Не совсем понимаю вопрос. Если речь чисто о мне самом, то этот вопрос звучит как "есть ли у вас хобби, за которое вы платите сами".
Если же вопрос стоит как "спонсировали ли вы исследовательские проекты других людей", ответ — нет, такого опыта у меня нет.
Здравствуйте, SkyDance, Вы писали:
SD>Начинаю думать, что "исследовательский" проект — это когда бесконечный бюджет и время, и вообще не для бизнеса, а чтоб было интересно работать.
Нет, давайте попробуем не уходить в сторону "удовлетворения собственных амбиций".
На мой взгляд, исследовательский проект -- это попытка найти базу для какого-то продукта (не обязательно нового, может быть и повторение чего-то имеющегося, но с большей выгодой). Если не брать упомянутые мной выше языки программирования, то в качестве примера могу предложить что-то такое: вот некие люди посмотрели на Google Translate и захотели сделать конкурента. И начали пилить собственное ядро для системы машинного перевода. А потом, когда ядро задышало и появилась надежда, что это ядро будет работать лучше, чем Google Translate, над этим ядром стали делать продукт (пусть это будет, скажем, deepl.com).
Так вот, на мой взгляд, исследовательский проект -- это когда кто-то пилил собственное ядро. И тут запросто могло и не получиться.
А вот когда над ядром уже стали делать сервис deepl.com, вот здесь исследования ушли на другой план. И, собственно, почему бы при разработке продукта deepl.com не использовать тот же скрам? Пусть будет скрам.
Тогда как при пилении ядра скрам... Звучит странно.
S>>Да? Ладно, допустим, всегда будут шаги вроде "посмотреть по сторонам и понять, что уже делали" и "определиться откуда и куда будем стартовать". Мне непонятно как в спринты будут запихивать задачи типа "родить способ контроля повисших ссылок". И зачем это делать.
SD>А что не так с этими задачами?
Это тоже самое что и: "для того, чтобы забеременеть, нужно заниматься сексом". Только вот опыт многих пар, которые не могут завести ребенка, показывает, что задачи "заниматься сексом" не гарантируют получения результата.
SD>нужно ее разбить на чуть более понятные шаги (те самые "погуглитьт", "составить список идей", "написать приемочные тесты").
Фишка в том, что идея borrow checker-а должна кому-то прийти в голову. И, насколько я знаю, еще никто не смог выдумать конечный набор шагов для того, чтобы нужные идеи приходили в голову быстро (верующих в ТРИЗ в рассмотрение не берем). А раз так, то какой смысл вносить в скоуп спринта задачи вроде "Вася будет придумывать borrow checker", а потом Вася каждый день на стендап-митингах будет говорить "я вчера 5 часов пытался придумать borrow checker"
S>>Можно нескромный вопрос: вы вели исследовательские проекты за собственный счет?
SD>Не совсем понимаю вопрос. Если речь чисто о мне самом, то этот вопрос звучит как "есть ли у вас хобби, за которое вы платите сами". SD>Если же вопрос стоит как "спонсировали ли вы исследовательские проекты других людей", ответ — нет, такого опыта у меня нет.
Нет, речь не про хобби. Про бизнес: вкладывали ли вы собственные деньги в построение какого-нибудь софтверного продукта?
Здравствуйте, SkyDance, Вы писали:
SD>Самым сложным было осознание простоты происходящего процесса. Я все где-то искал подвох, старался быть умнее и т.п., а всего-то надо было накопить историю выполнения задач конкретно взятой командой. Ключевое тут именно "команда", если люди постоянно меняются, не факт, что будет хорошо работать.
S>На мой взгляд, исследовательский проект -- это попытка найти базу для какого-то продукта (не обязательно нового, может быть и повторение чего-то имеющегося, но с большей выгодой).
Хорошо, пусть будет так. Но в чем проблема иметь хотя бы минимальное планирование для такого проекта? Все равно же в общих чертах есть какое-никакое понимание, что планируется сделать. Это ж не так чтобы "будем все вместе думать, пока не придумаем, может через час, а может и через год".
S>Если не брать упомянутые мной выше языки программирования
Их точно брать не надо, т.к. как раз там все весьма тривиально, потому что уже есть сотни (или даже тысячи) аналогов.
Лично для меня исследовательский проект — это когда вообще непонятно, с какого бока подступиться. К примеру, если бы мне выдали проект "спроектировать космический корабль, способный достичь Альфа Центавра". Аналогов нет, технологий нет, понимания, с чего начинать, тоже нет.
А проекты типа "сделать такой же, но с перламутровыми пуговицами", какое ж тут исследование.
S>Так вот, на мой взгляд, исследовательский проект -- это когда кто-то пилил собственное ядро. И тут запросто могло и не получиться.
Ну не знаю. Мне такое определение не кажется правильным. Если кто-то уже это сделал, значит, задача решаема, технология существует, надо просто повторить, а потом улучшить.
S>Тогда как при пилении ядра скрам... Звучит странно.
Да ладно. Реверс-инжиниринг ну очень хорошо укладывается в строгие методологии.
S>Фишка в том, что идея borrow checker-а должна кому-то прийти в голову.
О нет, вот как раз идей-то у каждого первого инженера с большим запасом. Сложность не в идеях, а в том, чтобы под эти идеи выбить бюджет. А также убедить своих ничуть не менее амбициозных коллег, что именно эта идея — правильная. Какой бы хорошей идея ни была, если проект — командный (а в других скрам применить невозможно), технические проблемы блекнут в сравнении с "общечеловеческими".
S>Про бизнес: вкладывали ли вы собственные деньги в построение какого-нибудь софтверного продукта?
Смотря что вы под этим имеете в виду. Инвестиции в стартап? Или инвестиции в устоявшуюся компанию? Второе — да, первое — нет, это отдельная, достаточно сложная, область знаний, в которой я недостаточно силен.
Здравствуйте, SkyDance, Вы писали:
S>>Но тут, полагаю, проблема в том, что никто не удосужился привести определение понятию "исследовательский проект".
SD>Согласен с этим утверждением. SD>Начинаю думать, что "исследовательский" проект — это когда бесконечный бюджет и время, и вообще не для бизнеса, а чтоб было интересно работать.
Исследование и проект это два различных рода деятельности, друг от друга никак не зависят. Как говорят "вещи ортогональные". А потому вы можете вести их как вместе, так и порознь.
Проект — способ планирования "от цели". Исследование — поиск нового знания.
Хотите — совмещайте проектное планирование с исследованием, получится исследовательский проект. Не хотите — не используйте, планируйте используя процессный подход. Можете каждый отдельный эксперимент выделять в проект.
Точно так же можно в проекте ответы искать посредством исследования.
Но вот заранее утверждать, что любое исследование можно впихнуть в скрам — это мягко говоря профанация. В норме исследование может содержать чуть не 100% операционной деятельности вида "собираем данные, регистрируем, документируем, обрабатываем месяцы-годы-десятилетия"
Что характерно, вы всё время уходите от вопроса, как в этом случае применять скрам, т.е. для планирования той самой операционной деятельности.
Здравствуйте, Sharov, Вы писали:
P>>>Результат по проекту он аддитивный. L>>Нет. S>Почему нет?
Потому что ошибка в фундаменте сводит на нет любые усилия по возведению стен.
P>>>Даже если вы пишете плохо, то все равно доберётесь до конца. L>>Нет.
Потому что одна критическая ошибка в ядре, неправильный анализ use cases и т.п. могут сделать реализацию проекта невозможным и/или свести его полезность/применимость к нулю.
S>Почему нет? L>>Верхние два утверждения лежат в основе водопада, который, как известно, в разработке ПО не работает.
S>Спорное заявление,
Это не утверждение, а общепризнанный факт.
S>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду.
Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Здравствуйте, landerhigh, Вы писали:
S>>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду.
L>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Со скрамом обычно так — если до релиза не дожил, но всё по методологии, значит не скрам. А если дожил, но не по методологии, то это всё равно скрам
Здравствуйте, Pauel, Вы писали:
L>>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза. P>Со скрамом обычно так — если до релиза не дожил, но всё по методологии, значит не скрам.
Скажем так, правильное применение скрама тут видели человека три, не больше.
Только вот вопрос методологий разработки назрел намного раньше того, как скрам пришел в разработку софта.
P>А если дожил, но не по методологии, то это всё равно скрам
Здравствуйте, SkyDance, Вы писали:
SD>Но в чем проблема иметь хотя бы минимальное планирование для такого проекта?
Мы же не про минимальное планирование говорим, а про скрам. Скрам -- это формализованный метод разработки продуктов с жесткими ритуалами и (емнип) запретом на игнорирование этих самых ритуалов (т.к. тогда уже не скрам получается).
Минимальное планирование может выглядеть как:
"1. Ввязываемся в драку.
2. Разбираемся по обстоятельствам"
и для некоторых это работает. Только вот к скраму это не имеет отношения.
SD>Их точно брать не надо, т.к. как раз там все весьма тривиально, потому что уже есть сотни (или даже тысячи) аналогов.
Даже при наличии этих сотен и тысяч аналогов более-менее заметных попыток сделать "безопасные С/C++" было две: Cyclone и Rust. И обе не такие уж, чтобы вот прям где-то что-то готовое можно было взять.
SD>Лично для меня исследовательский проект — это когда вообще непонятно, с какого бока подступиться. К примеру, если бы мне выдали проект "спроектировать космический корабль, способный достичь Альфа Центавра". Аналогов нет, технологий нет, понимания, с чего начинать, тоже нет.
А если на область разработки софта переложить? Вы же вроде бы упоминали, что скрам для исследовательских проектов использовали, так что это за исследования были?
SD>Если кто-то уже это сделал, значит, задача решаема, технология существует, надо просто повторить, а потом улучшить.
Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение. Вроде того, что 30 лет назад для распознавания речи применяли попытку разбивки на фонемы с последующих их анализом, а затем для этих же целей стали применять нейросети (здесь могу соврать, не копенгаген).
S>>Тогда как при пилении ядра скрам... Звучит странно.
SD>Да ладно. Реверс-инжиниринг ну очень хорошо укладывается в строгие методологии.
Для реверс-инжениринга нужно иметь доступ к чужой системе. Сомневаюсь, что кто-то может просто так скачать себе Google.Translate и заняться его реверс-инженирингом. Разве что-то кто-то REST API сможет расковырять, но не алгоритмы и базы данных, на которых перевод выполняется.
S>>Фишка в том, что идея borrow checker-а должна кому-то прийти в голову.
SD>О нет, вот как раз идей-то у каждого первого инженера с большим запасом.
Вы в какой-то другой вселенной живете, полагаю.
S>>Про бизнес: вкладывали ли вы собственные деньги в построение какого-нибудь софтверного продукта?
SD>Смотря что вы под этим имеете в виду.
Когда вы вложили собственные N килоденег в разработку продукта и каждый месяц, пока продукт находится в разработке, видите, как очередные M килоденег из этой суммы списываются.
SD>Второе — да
Здравствуйте, SkyDance, Вы писали:
SD>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще.
А как и где всю эту статистику смотреть? На ретроспективе собирать фидбэк и записывать с "блокнотик" для дальнейшей оценки/переоценки, подсчёта локов и т.п.?
Здравствуйте, SkyDance, Вы писали:
P>>Необязательно. Траблшутинг, суппорт тоже сюда относятся.
SD>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time.
Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Здравствуйте, Kernan, Вы писали:
SD>>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time. K>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Сторипоинт это скорее единица "массы" фичи, чтото навроде сложность*трудоемкость. Просто сама по себе сложность это качественная характеристика, потому её довольно трудно отделить от трудоемкости, которая количественная.
Трудозатраты получатся в том случае, если мы эту "массу" поделим на велосити команды или отдельного разработчика.
Здравствуйте, landerhigh, Вы писали:
L>Ее вообще не нужно смотреть и записывать. L>Она — для команды. L>См. "self managing teams". L>На практике в джире ее видно в burndown chart, например.
У вас здесь противоречие. Статистика смотрится в той самой джыре, на её основании планируются релизы итд, чем всегда интересуются вышестоящие менеджеры.
Здравствуйте, Pauel, Вы писали:
L>>На практике в джире ее видно в burndown chart, например.
P>У вас здесь противоречие. Статистика смотрится в той самой джыре, на её основании планируются релизы итд, чем всегда интересуются вышестоящие менеджеры.
Еще раз — эта статистика не для планирования релизов.
Здравствуйте, landerhigh, Вы писали:
P>>У вас здесь противоречие. Статистика смотрится в той самой джыре, на её основании планируются релизы итд, чем всегда интересуются вышестоящие менеджеры.
L>Еще раз — эта статистика не для планирования релизов.
И на кой ляд она вообще нужна? Примером можете поделиться?
S>Мы же не про минимальное планирование говорим, а про скрам. Скрам -- это формализованный метод разработки продуктов с жесткими ритуалами и (емнип) запретом на игнорирование этих самых ритуалов (т.к. тогда уже не скрам получается).
Как раз у скрам ритуалов минимум. По факту, один митинг раз в спринт (который обычно длится от 2 до 4 недель). По книжке, митингов может быть вплоть до 3 штук (1 — планирование, 2 — демо, 3 — ретроспектива), но на практике их зачастую объединяют в один, короткое демо (получаса зачастую хватает), ретроспектива (поначалу там теряется много времени, но с набором опыта получается все быстрее и быстрее), и планирование (аналогично, первые спринты — мучительно долго, потом ускоряется).
S>"1. Ввязываемся в драку. S>2. Разбираемся по обстоятельствам"
Это я планированием назвать не могу. Равно как не могу сказать, работает оно, или нет — ведь ни сроков, ни бюджетов нет.
S>Даже при наличии этих сотен и тысяч аналогов более-менее заметных попыток сделать "безопасные С/C++" было две: Cyclone и Rust. И обе не такие уж, чтобы вот прям где-то что-то готовое можно было взять.
Ни тот, ни другой не являются коммерческими продуктами. Есть и куча других, сделанных скорее вопреки, чем благодаря поддержке бизнеса. Равно как и гигантское количество аналогов, которые не взлетели. Не потому, что были хуже. А потому, что не были впихнуты в ту или иную контору, у которой получился удачный коммерческий продукт на основе этого языка или библиотеки. Таких примеров — воз и маленькая тележка. Да одни лишь только RPC уже столько раз переизобрели, и столько раз еще переизобретут
Любые проекты на базе энтузиазма не рассматриваются бизнесом как проект. Энтузиазм и есть энтузиазм. Проект наступает позже: когда энтузиазм уже кончился, фана никакого, надо заниматься самым что ни на есть скучным делом: изготовлением реального продукта. Того, который нужен покупателям. То есть не самого языка, а продуктов на его основе. Вот там-то и наступает пора все этой бизнес-скукотищи: планирования, бюджетирования, релизов, поддержки.
Короче говоря, не путайте туризм с эмиграцией. Работать над прикольными новыми штуками, да в green field, энтузиастов хватает и без бюджетов-скрамов-планов.
S>Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение.
Это те же яйца, вид в профиль. Если задача уже была решена, у вас уже есть очень много информации, которая поможет при достижении новых горизонтов. У вас уже есть baseline, есть тесты, есть много еще чего. Эти исследования вполне себе могут быть спланированы.
S>Для реверс-инжениринга нужно иметь доступ к чужой системе. Сомневаюсь, что кто-то может просто так скачать себе Google.Translate и заняться его реверс-инженирингом. Разве что-то кто-то REST API сможет расковырять, но не алгоритмы и базы данных, на которых перевод выполняется.
Ковырять ничего и не надо, все коммерческие продукты сделаны на основе давно опубликованных whitepapers. Если быть в теме и иметь нужные знакомства, можно просто спросить, как сделано вот это и вот это. Там совершенно никакой rocket science, и вообще, не удивлюсь, если половина сделана intern'ами
SD>>О нет, вот как раз идей-то у каждого первого инженера с большим запасом. S>Вы в какой-то другой вселенной живете, полагаю.
Я работаю с компетентными инженерами. У всех них есть не только вооооот такое эго и воооооот такие амбиции, но также еще и куча идей, интересов и желания состряпать нечто совершенно новое и выдающееся. Так что, повторюсь, все эти идеи давно известны и понятны. Сложность отнюдь не в том, чтобы их реализовать с технической точки зрения. И не в том, чтобы их придумать. А в том, чтобы убедить бизнес эти идеи начать применять. Зачастую чем больше и старее бизнес (и чем сильнее он индус-триализировался), тем сложнее становится внедрить хоть какую угодно новую идею. Но для выживания бизнеса эти идеи очень нужны. Поэтому старые и большие бизнесы, где внутренние идеи убиваются на корню, вливают новую кровь и идеи путем покупки стартапов (с командами и готовыми реализациями идей). Вот такой занятный баланс
S>Т.е. прикупили акции условного Microsoft-а?
Да, подобным я занимался, разве что вкладывался в менее надежные компании, из больших была разве что только AMD (до сих пор жалею, что мало вложил, сейчас мог бы быть куда богаче). И нет, венчурным капиталистом я не был и не стану, ибо это отдельная профессия, в которой я не разбираюсь.
Здравствуйте, Sharov, Вы писали:
P>>Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
S>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы.
Что вы имеете ввиду? Фикс то всё равно нужно сделать, и это срочная работа.
Здравствуйте, SkyDance, Вы писали:
SD>Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться.
Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
Здравствуйте, landerhigh, Вы писали:
L>Если это нужно делать в 2023 году, то лучше всего будет убиться апстену.
Так-так-так, а поясни ка, как это так? А как же оценки делать? Бюджет, команду планировать?
Здравствуйте, Kernan, Вы писали:
L>>Если это нужно делать в 2023 году, то лучше всего будет убиться апстену. K>Так-так-так, а поясни ка, как это так? А как же оценки делать? Бюджет, команду планировать?
Здравствуйте, landerhigh, Вы писали:
P>>У вас здесь противоречие. Статистика смотрится в той самой джыре, на её основании планируются релизы итд, чем всегда интересуются вышестоящие менеджеры.
L>Еще раз — эта статистика не для планирования релизов.
Вот для интересу глянул в мануал, и нашел, что burndown chart нужен для вычисления вероятности завершения работ в установленное время. И этот момент завершения обычно и есть финальный релиз.
Здравствуйте, Pauel, Вы писали:
S>>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы. P>Что вы имеете ввиду? Фикс то всё равно нужно сделать, и это срочная работа.
Безусловно, но оно может месяц работать нормально, потом упасть. И devops поднимает, а разработчик
может пока заниматься текущими задачами, и приоритизировать исследование месячных падений.
Суть в том, что разработчики не бегут сломя голову поднимать систему. Или речь о том, что пока
баг не найден и не исправлен, систему поднимать не стоит? Фикс разный может быть, если падатает
крайне редко и по особым случаям, то жить можно.
Здравствуйте, Sharov, Вы писали:
S>Суть в том, что разработчики не бегут сломя голову поднимать систему. Или речь о том, что пока S>баг не найден и не исправлен, систему поднимать не стоит? Фикс разный может быть, если падатает S>крайне редко и по особым случаям, то жить можно.
Я говорю про срочные фиксы. Понятно, что когда жить можно, то горячки нет.
Здравствуйте, Kernan, Вы писали:
SD>>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. K>А как и где всю эту статистику смотреть? На ретроспективе собирать фидбэк и записывать с "блокнотик" для дальнейшей оценки/переоценки, подсчёта локов и т.п.?
Здравствуйте, Kernan, Вы писали:
S>>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы. K>Это всё херня на самом деле. Когда надо что-тио делать приходится просто садиться и делать вне зависимости то того девопс ты или нет.
Мне кажется, это позволяет лишний раз разработчиков по мелочам не раздергивать. Просто поднять и развернуть
может и devops. А если совсем критический баг, то тогда да. Короче, время и внимание разработчика экономится,
что хорошо для решения бизнес задач.
Здравствуйте, Sharov, Вы писали:
S>>Это в официальном руководстве по SCRUM написано. Звиздун-собеседник, конечно же, мастерски может послать все это вдоль и наговорить массу умных слов в свое оправдание. Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
S>К этому можно относится как к какому-нибудь фреймворку и адаптировать для команды. Т.е. все брать S>не обязательно. Если пуристы будут говорить, что это не настоящий скрам, то их можно посылать нафиг, S>т.к. для комнды и для ее задач это работает. Т.е. тут необходимое vs достаточное.
Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика, но сами по себе "патентованные" методы (вроде того же SCRUM) -- это жесткие и формализованные процессы. Вплоть до того, что стоит из SCRUM выкинуть что-то, что ты считаешь ненужным, как у тебя уже [формально] не SCRUM.
Мотивацию этого подхода тоже можно понять: вот выбросил я, например, Daily Scrum, утратил один из инструментов контроля за происходящим, проект завершился неудачно. Почему бы мне не начать говорить, что SCRUM сработал плохо? А нельзя, т.к. у меня был не SCRUM, и это правда.
Ну а так-то да, под команду можно настроить процесс, понадергав полезного из разных подходов (SCRUM, Kanban, Crystal и пр.). Главное, чтобы работало. Вопрос в том, можно ли к сформированному процессу конкретный ярлык прилепить (по аналогии с тем, что не всякое вино в определенных юрисдикциях может "Шампанским" называться).
Не путайте events с митингами. Митинг, как я уже написал, один, объединяющий в себе вот эти три events:
S>* Sprint Planning S>* Sprint Review S>* Sprint Retrospective
Утренние летучки (daily standup) — это не митинги, а специальное время, когда нужно сказать, где у тебя сейчас грабли. Чтобы грабли лежали не сами по себе, а в контексте, нужно также кратко объяснить, чем именно занимался, и чем планируешь заняться. Почему-то именно эта летучка вызывает наибольшее непонимание среди горе-коучей и бывших менеджеров, которые стремятся превратить полезные вопросы ("как мне обойти эти грабли") в статус репорты. Сдается мне, из-за таких вот Рабиновичей, которые не понимают, что делают, настоящий скрам мало кто видел.
S> Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
Почему нет?
S>Вы еще скажите, что на разработку Rust бюджеты не выделялись.
Я не знаю, как именно велось бюджетирование разработки Rust (и велось ли вообще, до становления на осмысленные рельсы). Но можешь быть уверен, безграничных и безлимитных задач типа "а придумай borrow checker" там не было.
S> Разработку Scala никто не спонсировал, Go/Dart в Google в свободное от работы время и за свой счет пилили и пилят
Из всех этих я могу только про Go. Там вообще никаких исследований и rocket science Просто очередная реализация того же, что уже было реализовано десятки раз до, и будет реализовано десятки раз после. Причем реализация тривиальная. Проще, чем сделано, скажем, во все том же Erlang. Который, кстати, был настоящим исследовательским проектом, и там была research lab, без скрам, без спринтов, но зато с энтузиастами, настоящими энтузиастами своего времени. Им дали время на решение той задачи, которую они сами хотели решить. Коммерческим проект не планировался (и не стал, кстати).
S>А вы не только за "якобы" SCRUM, но еще и за бизнес можете позвиздеть? Ну сильны, чё. S>По итогу: натрындели вы здесь много, но ничего конкретного не сказали: ни своего примера исследовательского проекта не привели, ни описали как же должно выглядеть применение SCRUM для исследовательских задач. Разве что общий звиздежь о том, что "все украдено до нас" и "идей вокруг полно".
Ну вот, вы в итоге скатились в хамство. Ок, ваш выбор. Я уже дал более чем достаточно объяснений и описаний того, что работает.
Здравствуйте, SkyDance, Вы писали:
S>>что в массе своей все это писалось математиками и физиками, а не закончившими курсы. Кмк, уровень был S>>в массе своей выше, выше была дисциплина, меньше всяческих дистракторов и т.п. Поэтому можно было жить
SD>Дело не столько в дисциплине, сколько в мотивации: то, что "писалось математиками и физиками", обычно было на энтузиазме. Которого при разработке типового интернет-магазина (или очередного "революционного подхода к RPC") скорее всего не будет, т.к. людей нанимали работать за деньги.
+100500
Держалось на энтузиазме и/или авторитете.
При этом масштаб все же был меньше.
И эпичные факапы абсолютно так же случались, и более чем дофига.
А я вообще говорил о ритуалах, от которых в SCRUM нельзя отказаться:
Скрам -- это формализованный метод разработки продуктов с жесткими ритуалами и (емнип) запретом на игнорирование этих самых ритуалов (т.к. тогда уже не скрам получается)
А речи о том, что их много или мало не шло вообще, это вы начали апеллировать к их количеству.
SD>Митинг, как я уже написал, один, объединяющий в себе вот эти три events:
S>>* Sprint Planning S>>* Sprint Review S>>* Sprint Retrospective
Что означает, что если вы все это впихиваете в небольшие эпизодические митинги, то делаете это ради сохранения самих ритуалов. Т.е. налицо вырождение и выхолащивание процесса, но раз ритуалы в самом процессе описаны, значит им нужно следовать.
О чем я и говорил.
А раз так, что вопрос о полезности SCRUM-а для исследовательских проектов все еще остается нераскрытым.
S>> Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
SD>Почему нет?
Потому что при выбрасывании чего либо из SCRUM-а процесс перестает быть скрамом.
S>>Вы еще скажите, что на разработку Rust бюджеты не выделялись.
SD>Я не знаю, как именно велось бюджетирование разработки Rust (и велось ли вообще, до становления на осмысленные рельсы).
Велось. Например, в 2013-ом году, даже Samsung выделял своих инженеров для работы над проектом Rust:
Eich said that Samsung has committed around 20 people to the Rust project. Samsung, for its part, is known for having its fingers in as many different pies as possible
Надеюсь, вы не предполагаете, что они забесплатно работали.
SD>Но можешь быть уверен, безграничных и безлимитных задач типа "а придумай borrow checker" там не было.
Вы же не знаете, как разработка Rust-а велась, особенно когда Mozilla начала поддерживать одиночные усилия Грейдона Хоара.
S>> Разработку Scala никто не спонсировал, Go/Dart в Google в свободное от работы время и за свой счет пилили и пилят
SD>Из всех этих я могу только про Go.
Так поинтересуйтесь. Откроете для себя много нового.
SD>Там вообще никаких исследований и rocket science Просто очередная реализация того же, что уже было реализовано десятки раз до, и будет реализовано десятки раз после. Причем реализация тривиальная.
А кто сказал, что попытка сделать новую уникальную компиляцию не может быть исследовательским проектом? По факту у них получился уникальный результат, успех которого не был предрешен от слова совсем. И да, хоть там не было rocket science, у них вышел уникальный результат скрещивания жабы и гадюки.
SD>Который, кстати, был настоящим исследовательским проектом, и там была research lab
Ну да, и Армстронг не повергся влиянию ни Prolog-а, ни Smalltalk-а. Возможно, он даже проигнорировал работы Хьюитта, которые вышли лет за 12-13 до того.
SD>но зато с энтузиастами, настоящими энтузиастами своего времени.
У вас "энтузиаст" -- это фетиш, что ли? Ведь эти энтузиасты не забесплатно работали и не как им вздумается, их работа оплачивалась, результаты исследований оценивались. Т.е. все это было полноценным проектом.
Подобные проекты возможны и сейчас. Надеюсь, вы в этом не сомневаетесь. А раз проводятся, то вопрос, который в данным обсуждении пытаются поднять, -- это насколько выгодно применять для подобных проектов SCRUM.
SD>Им дали время на решение той задачи, которую они сами хотели решить. Коммерческим проект не планировался (и не стал, кстати).
А при чем здесь упоминание "коммерции"? Типа, если нет "коммерческого проекта", то SCRUM отдыхает?
SD>Я уже дал более чем достаточно объяснений и описаний того, что работает.
Нет. Причем я подключился к разговору когда из вас уже долго пытались что-то внятное вытащить. И я попробовал сделать несколько попыток. Но пространный евангелизм (т.е. трындеж) есть, а конкретики нет.
Здравствуйте, SkyDance, Вы писали:
SD>Не путайте events с митингами. Митинг, как я уже написал, один, объединяющий в себе вот эти три events:
S>>* Sprint Planning S>>* Sprint Review S>>* Sprint Retrospective
Когда у нас были такие митинги, до середины мало кто доживал.
Здравствуйте, so5team, Вы писали:
S>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика
То есть, когда у нас есть некоторая свобода в требованиях, они меняются, но реализацию можно или растянуть во времени, или переформулировать требования.
То есть, минимальная неопределенность. Максимум, что мы себе можем позволить — нагуглить либу, написать poc на фичу, посчитать вычислительную сложность итд. Вроде бы тоже ресёрч, но ооочень маленький.
S>Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика,
Не для этого нужна гибкость. Точнее, хотелки тоже меняются, но гибкость в разработке ПО необходима в первую очередь потому, что планы меняются в процессе разработки. Таски, выполненные в текущем спринте, могут убрать необходимость в тасках, работать над которыми планировалось потом, или заменить их другими.
Это то, где погорает стандартный вотерфол.
Здравствуйте, Pauel, Вы писали:
P>А вы видели исследование в котором анализа результатов нет? Анализ это обработка данных, интепретация результатов, итд. Это часть исследования.
Вот именно. Часть исследования. Ты же говорил об исследовании в целом. Причем, в разрезе того, что, в отличие от разработки софта, исследования не содержат ничего определённого, а сам на вопрос, что же такое исследование (research) привёл пример донельзя регламентированного и известного вдоль и поперёк анализа.
Вот эти вот противоречия в твоих собственных словах и заставляют меня сомневаться.
P>Здесь нет никакого словоблудия: P>1. каждый эксперимент в исследовании может выделяться в конкретный проект со вполне достижимой целью. Например — создать броневую плиту на основе xxx. P>2. проект может содержать в себе исследование, например — выяснить оптимальные условия отжига.
Это именно, что словоблудие, которое ведёт к полнейшему бардаку в голове и, как следствие, в организации в целом. И в итоге у тебя пытаются прототип заставить работать как релизную версию, а пользователи начинают работать с системой с первого спринта.
Проекты точно так же могут разбиваться над подпроекты и в практически любом проекте есть что-то, что требует прояснения для дальнейших корректировок планов. Обычно это называется общим словом "риски". Ты не привёл никаких отличий исследований от других типов проектов.
_AB>>А что случится, если в ответ на что такое ресёрч тебе приведут пример анализа? P>Раз вы запутались, я вам помогу: P>Research is the process of finding information, while analysis is the process of evaluating and interpreting that information to make informed decisions
Извини, но это не я в ответ на что такое ресёрч привел пример анализа, так что запутался не я, а ты.
Здравствуйте, so5team, Вы писали:
S>Мы же не про минимальное планирование говорим, а про скрам. Скрам -- это формализованный метод разработки продуктов с жесткими ритуалами и (емнип) запретом на игнорирование этих самых ритуалов (т.к. тогда уже не скрам получается).
Скрам — это точно не формализованный метод разработки продуктов.
Скрам, скорее, это, прежде всего, идеология командной работы над достижением какой-либо цели. На основе этой идеологии выстроена методология (причём, слабоформализованная), описывающая минимально необходимый (с точки зрения авторов ) набор методов (а не жёстких ритуалов), необходимых для достижения этих целей.
Что касается оговорки про то, что выкинете что-нибудь — это будет не скрам, то во-первых, не надо забывать, что скрам — это ещё и коммерческий продукт над ним в виде сертификаций и прочего, что требует хотя бы минимальной стандартизации. А во-вторых, это взгляд авторов методологии на минимально необходимый набор инструментов. Если выкинуть что-то из минимально необходимого, то цели достичь задуманным авторами путём не получится и это будет не их методология с этой точки зрения.
Что касается жёсткости "ритуалов", то из всей "жесткости" там лишь список минимально необходимых событий и артефактов, у которых есть ограничения по длительности и которые должны преследовать определённые цели, согласно заложенной идеологии. С этой точки зрения (с точки зрения идеологии), методологию можно назвать очень жёсткой, но ирония в том, что именно про все эти цели и забывает примерно этак 80%+ всех, применяющих скрам, что и приводит к ритуализации и формализации практической реализации этого фреймворка.
Немного в сторону, но, ИМХО, авторы скрама сами себе в ногу выстрелили, когда в первых версиях применяли околорелигиозные термины типа "ритуалов" и прочего и навязывали больше ограничений, не делая достаточного акцента на том, зачем это делается. Текущая версия куда более приближена к реальному миру и куда более работоспособная, с моей точки зрения.
S>Минимальное планирование может выглядеть как: S>"1. Ввязываемся в драку. S>2. Разбираемся по обстоятельствам"
ИМХО, это не планирование. Минимальное планирование определяет хотя бы цель ввязывания в драку и общие намётки того, в какую сторону будут пытаться эту драку двигать.
S>и для некоторых это работает.
Только, если все участники понимают цель и общий замысел, даже если формально его не озвучили.
S>Только вот к скраму это не имеет отношения.
Это и к планированию отношения не имеет.
S>Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение.
Я могу ошибаться, но такими поисками занимаются одиночки, а не команды. И только когда одиночка нашёл что-то перспективное, вот тогда на основе имеющихся результатов может быть создана команда для практического применения найденного. Да, одиночки не работают в вакууме, получают данные извне и используют ранее открытое, но я не назову вот так навскидку чего-то фундаментального, открытого командой из нескольких людей, которым поставили цель это фундаментальное открыть. ЕМНИП, всегда был сначала один, нашедший идею, а дальше её могли развивать уже и командой. А одиночки не имеют отношения ни к проектной ни к операционной деятельности и им ни канбан, ни скрам, ни водопад не нужны.
Мы же ведём разговор именно о работе в команде, не так-ли?
Здравствуйте, _ABC_, Вы писали:
_AB>Что касается оговорки про то, что выкинете что-нибудь — это будет не скрам, то во-первых, не надо забывать, что скрам — это ещё и коммерческий продукт над ним в виде сертификаций и прочего, что требует хотя бы минимальной стандартизации. А во-вторых, это взгляд авторов методологии на минимально необходимый набор инструментов. Если выкинуть что-то из минимально необходимого, то цели достичь задуманным авторами путём не получится и это будет не их методология с этой точки зрения.
Не вижу противоречий с тем, что я говорил ранее.
S>>Минимальное планирование может выглядеть как: S>>"1. Ввязываемся в драку. S>>2. Разбираемся по обстоятельствам" _AB>ИМХО, это не планирование.
Тем не менее, это именно оно и именно в таком виде оно наблюдалось в прошлом (не только мной, достаточно вспомнить сделку между Microsoft и IBM в начале 1980-х).
Кроме того, это именно те планы, над которыми боженька смеется не так часто и не так сильно
_AB>Минимальное планирование определяет хотя бы цель ввязывания в драку
Я наивно полагал, что планирование -- это следующая стадия после целеполагания. Т.е. сперва определяет цель, потом уже начинается планирование по ее достижению. Например, кто-то хочет стать поставщиком решений для крупной компании (типа Сбера или Газпрома). Это цель. И минимальный план для ее достижения: ввязываемся в ближайший тендер, а там разберемся.
_AB>общие намётки того, в какую сторону будут пытаться эту драку двигать.
А это уже по ходу уточняется. В планировании тоже итерационный подход работает
S>>Нет, речь идет не про улучшении существующей технологии, а про поиск другого подхода к решению той же задачи, чтобы получить качественно другое решение. _AB>Я могу ошибаться, но такими поисками занимаются одиночки, а не команды.
Возможности одиночки сильно ограничены. Если такое и происходит, то либо на маленьких проектах, либо на самых ранних стадиях, когда какой-нибудь условный Грейдон Хоар в свободное от работы время вынашивает идею Rust-а (или условный Герб Саттер вынашивает идею Cppfront).
Но история того же Go показывает, что там с самого начала была командная работа, т.к. даже список требований к новому языку Роб Пайк не в одиночку составлял. Да и когда Грейдон Хоар получил поддержку от Mozilla для своих разработок, то там образовалась команда из, емнип, четырех человек, которая и занималась Rust-ом в течении нескольких лет (+ помощь от сочувствующих с разных концов света).
Так что более правильно было бы говорить о небольших командах (3-5 человек). И это еще один фактор, почему какой-нибудь условный SCRUM (как "патентованный" процесс) не столь актуален: в таких небольших командах координация и кооперация намного проще и эффективнее самоорганизуется без необходимости в жестких ритуальных действиях.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы. K>Это всё херня на самом деле. Когда надо что-тио делать приходится просто садиться и делать вне зависимости то того девопс ты или нет.
Здравствуйте, _ABC_, Вы писали:
P>>А вы видели исследование в котором анализа результатов нет? Анализ это обработка данных, интепретация результатов, итд. Это часть исследования. _AB>Вот именно. Часть исследования. Ты же говорил об исследовании в целом. Причем, в разрезе того, что, в отличие от разработки софта, исследования не содержат ничего определённого, а сам на вопрос, что же такое исследование (research) привёл пример донельзя регламентированного и известного вдоль и поперёк анализа.
Вы пытаетесь играть в слова. Исследование неопределенного спроса на 90% состоит из сбора сведений. Вы же почему то видите здесь исключительно 10% анализа.
P>>2. проект может содержать в себе исследование, например — выяснить оптимальные условия отжига. _AB>Это именно, что словоблудие, которое ведёт к полнейшему бардаку в голове и, как следствие, в организации в целом.
Похоже, вам ктото запретил посмотреть разницу между проектом и исследованием.
_AB>Проекты точно так же могут разбиваться над подпроекты и в практически любом проекте есть что-то, что требует прояснения для дальнейших корректировок планов. Обычно это называется общим словом "риски". Ты не привёл никаких отличий исследований от других типов проектов.
Наоборот, привел то самое ключевое — исследование дает нам качественный результат в виде нового знания, и планируется в основном последовательно. Например, пока вы сведения не собрали, вам нечего анализировать. Более того — у вас все шаги могут быть известы заранее.
И этот самый сбор сведений в чистом виде операционная деятельность — вы тупо сидите и регистрируете поступающие детали.
_AB>Извини, но это не я в ответ на что такое ресёрч привел пример анализа, так что запутался не я, а ты.
Пока вы сведения не соберете(1), вам нечего анализировать(2). Исследование это сначала 1, потом 2. Вы попутали арбуз и косточку от арбуза.
Здравствуйте, so5team, Вы писали:
S>Мотивацию этого подхода тоже можно понять: вот выбросил я, например, Daily Scrum, утратил один из инструментов контроля за происходящим, проект завершился неудачно. Почему бы мне не начать говорить, что SCRUM сработал плохо? А нельзя, т.к. у меня был не SCRUM, и это правда.
Что значит правда? Все хотят получить какую-то универсальную инструкцию -- делай раз, делай два и думают, что она
приведет их к успеху. Поэтому сам факт был ли скрам или не было особого смысла не имеет. Это равносильно
тому, чтобы все делать по инструкции, которой, к слову, просто не существует. Точнее она, инструкция, для каждого
случая индивидуальна. Ну может для какие-то задач и проектов действительно лучше подходит, например,
классический скрам, а для других -- уже нет.
S>Ну а так-то да, под команду можно настроить процесс, понадергав полезного из разных подходов (SCRUM, Kanban, Crystal и пр.). Главное, чтобы работало. Вопрос в том, можно ли к сформированному процессу конкретный ярлык прилепить (по аналогии с тем, что не всякое вино в определенных юрисдикциях может "Шампанским" называться).
А так ли нужен этот ярлык? Ну работает это ассабляж, так пусть работает. Можно просто говорить "работаем
по agile" и это будет правдой.
Здравствуйте, Kernan, Вы писали:
SD>>Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться. K>Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
) остальное еще хуже.
лишний день потратил и нет результатов — всё, вперед с докладом к начальству. твоя не решаемая задача может быть ключевой для команды. чем быстрее все узнают, что задача не решаема, тем быстрее поменяют планы, сохранят время и деньги
настрочил им тасков с критериями принятия и только знай себе их код ревьювить 
