Здравствуйте, 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 лучше?
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%).
Здравствуйте, 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, остальные передвинулись в следующий спринт, и сверх этого вылезло три срочных бага. В таком варианте скрам вполне себе работает.
Здравствуйте, Sharov, Вы писали:
S>Не силен в обоих, но правильно ли я понимаю, что scrum для проектной деятельности подходит, а kanban -- для операционной?
Хм... Как бы свою кашу в голове изложить понятно...
Канбан — он немного перпендикулярен управлению проектами. Канбан — он про выстраивание процессов. Поэтому он подходит очень хорошо для операционной деятельности, которая по определению представляет из себя совокупность повторяемых и регламентированных процессов. Однако, внутри проекта тоже есть свои процессы, причём повторяемые и даже регламентированные, поэтому для их выстраивания канбан тоже применим.
При этом канбан (в том виде, что знаю его я) — он не про управление проектом в том плане, что он не даёт инструментов для оценки того, приближаетесь ли вы к цели проекта, с какой скоростью, и когда у вас кончится бюджет, и/или сроки выполнения проекта. Про это и многое другое, необходимое для реализации проекта рассказывают водопады, скрамы и прочие методологии управления проектами.
S>Т.е. когда только реализуем систему, т.е. проектная деятельность, то scrum лучше, после релиза, поддержка S>жизненного цикла, т.е. операционная деятельность, kanban лучше?
Я бы выразился более обще. Во время разработки системы, во время проектной деятельности, лучше придерживаться хоть какой-нибудь методологии управления проектами (например, скрам), а после релиза проект закрывается, поэтому эти методологии не могут быть применены и подойдёт что-то, что помогает выстраивать процессы операционной деятельности (например, канбан).
Здравствуйте, Pauel, Вы писали:
P>Вы наверное не в курсе, но скрам не применяют в операционной деятельности навроде траблшута или суппорта. Вам тупо нечего планировать, вне зависимости от попугаев P>Почему ресёрч похож на опрационную деятельность — уже показал
Честно говоря, я не убеждён, что ресёрч похож на операционную деятельность. Я, конечно, не настоящий сварщик, но в моём понимании исследование имеет цель (причём цель — это получить новое, неизвестное), имеет сроки, имеет бюджет. Другими словами — это проект ну просто тупо и буквально по определению слова "проект".
Понятно, что в рамках реализации проекта или исследования, часть работы — это текучка. Но отслеживать, что проект движется в правильном направлении (и что это направление при текущих ограничениях вообще достижимо), что бюджет ещё есть, что сроки ещё не завалены, всё равно надо. И agile методологии управления проектами здесь лучше других именно из-за того, что они куда лучше справляются с размытыми требованиями и неизвестными путями решения задачи. Канбан же не является метдологией управления проектом и поэтому не может в принципе подходить лучше или хуже того же скрама. ИМХО.
Здравствуйте, Pauel, Вы писали:
P>Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности.
Кхм. И?
P>Т.е. когда тикеты нужно фиксить сразу по мере их появления.
Вообще говоря, если мы говорим о скрам и о проектах, то там "тикетов" нет.
И я не очень понимаю, зачем они нужны именно вам. Что вы под ними понимаете?
Помимо непосредственно исследования, у вас есть существующие продукты в промышленной эксплуатации, на которые вам необходимо тратить ненормированное количество времени?
Ты же не это имеешь в виду, если судить по тому, что ты дальше пишешь?
P>Здесь нечего пихнуть в спринт — баклог пустой.
Как пустой, если вы "тикетами" занимаетесь? Ничего, что эти "тикеты" — это вполне себе backlog items?
P>В таком варианте скрам вполне себе работает.
Скрам работает в разных вариантах, но у меня складывается впечатление, что о скраме тебе Рабинович напел...
Здравствуйте, _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>Абсолютно так же, как все заносят возможное падение метеиорита прямо на дата центр.
Подробнее. Это та самая операционная деятельность. Как её провести через скрам?
Здравствуйте, Pauel, Вы писали:
P>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог?
Никак. "У юзеров" — это не часть проекта. Это эксплуатация. Решается в рамках операционной деятельности, SLA и т.д. и т.п.
Ты же, вроде, говорил о создании того, что никто раньше не делал? Откуда юзеры взялись?
Т.е., получается, всё-таки, у вас есть что-то в эксплуатации и вместо работы над исследованием (проектом), вы должны ненормированное количество времени тратить на поддержку существующего?
Здравствуйте, _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>Это если не упоминать того, что канбан может применяться совместно со скрамом?
Я не сильно понимаю, как можно совмещать спринты с их отсутствием.
Здравствуйте, _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 "Вычисления в фоновом режиме".
Вот это — слегка модифицированный (имена изменены) пример прикладного исселедования из жизни. Удалось ли решить задачу "улучшения алгоритма"? Нет. Удалось ли решить эту задачу с точки зрения успеха проекта? Более чем.
P>>Подробнее. Вот завтра, скажем, у юзеров нашего апи упадёт стейджинг. А может не завтра, а в четверг. А может и не упадёт. Вопрос — как мне это занести в баклог? _AB>Никак. "У юзеров" — это не часть проекта. Это эксплуатация. Решается в рамках операционной деятельности, SLA и т.д. и т.п.
Откуда SLA возьмется на стейджинге?
_AB>Ты же, вроде, говорил о создании того, что никто раньше не делал? Откуда юзеры взялись?
Я процитирую чуть выше, вы говорили про багфикс. Я вам про него и ответил
Не столько сам багфикс, а разновидности суппорта, траблшутинга, и прочие всевозможные срочные активности. Т.е. когда тикеты нужно фиксить сразу по мере их появления. Здесь нечего пихнуть в спринт — баклог пустой. Завтра уже чтото появится, и завтра его снова выкачаем досуха. В понедельник все что знаем, это что будет тикетов от 1 до N.
А если багфикс не срочный, скажем, с выдержкой в пару месяцев, то разницы с фичами особо никакой нет, аномалии выстреливают довольно редко. Накидал в спринт десятка два тикетов, из них закрыл 15, остальные передвинулись в следующий спринт, и сверх этого вылезло три срочных бага. В таком варианте скрам вполне себе работает.
Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
Если у вас только такие срочные активности, то непонятно, что в планирование спринта выносить. И разницы нет, багфикс это, траблшутинг, суппорт или еще чего.
А если не срочно, то можно и траблшутинг отложить на время. Тогда можно и спринты, и снова не важно, что это — багфикс, траблшутинг, суппорт.
То есть, скрамать вы можете в том случае, когда доля срочных задач и прочей операционной деятельности невысока, и цель спринта достижима и это условие не ломается.
Здравствуйте, landerhigh, Вы писали:
L>По итогам этого спринта команда принимает предложение Васи. Его хлопают по плечу, берут автографы, целуют в десна. В проект добавляется новый epic "Вычисления в фоновом режиме".
Это маленькое исследование, оно вполне может быть частью проекта.
L>Вот это — слегка модифицированный (имена изменены) пример прикладного исселедования из жизни. Удалось ли решить задачу "улучшения алгоритма"? Нет. Удалось ли решить эту задачу с точки зрения успеха проекта? Более чем.
Я уже говорил, что исследование может быть частью проекта, а проект — частью исследования. А вы идете дальше, и рассказывает, что исследование == проект.
Попробуйте обскрамать исследование неудовлетворенного спроса, ну или социологического исследования, которое длится не полдня-день, а год-два-три.
Так и вижу — цель спринта, получить часть результатов от продавцов и покупателей,
Тикеты, или, кому непонятно, баклог айтемы "понедельник", "вторник"...
По такой схеме у вас будут одни и те же спринты, с одним и тем же наполнением все год-два-три. На кой ляд они нужны?
Собственно, это классика скрам — иметь задачу, которая называется "понять, как работает ХХХ, и на основе этого выработать стратегию решения проблемы ЧЧЧ".
