Здравствуйте, SkyDance, Вы писали:
S>>Но тут, полагаю, проблема в том, что никто не удосужился привести определение понятию "исследовательский проект".
SD>Согласен с этим утверждением. SD>Начинаю думать, что "исследовательский" проект — это когда бесконечный бюджет и время, и вообще не для бизнеса, а чтоб было интересно работать.
Исследование и проект это два различных рода деятельности, друг от друга никак не зависят. Как говорят "вещи ортогональные". А потому вы можете вести их как вместе, так и порознь.
Проект — способ планирования "от цели". Исследование — поиск нового знания.
Хотите — совмещайте проектное планирование с исследованием, получится исследовательский проект. Не хотите — не используйте, планируйте используя процессный подход. Можете каждый отдельный эксперимент выделять в проект.
Точно так же можно в проекте ответы искать посредством исследования.
Но вот заранее утверждать, что любое исследование можно впихнуть в скрам — это мягко говоря профанация. В норме исследование может содержать чуть не 100% операционной деятельности вида "собираем данные, регистрируем, документируем, обрабатываем месяцы-годы-десятилетия"
Что характерно, вы всё время уходите от вопроса, как в этом случае применять скрам, т.е. для планирования той самой операционной деятельности.
Здравствуйте, Sharov, Вы писали:
P>>>Результат по проекту он аддитивный. L>>Нет. S>Почему нет?
Потому что ошибка в фундаменте сводит на нет любые усилия по возведению стен.
P>>>Даже если вы пишете плохо, то все равно доберётесь до конца. L>>Нет.
Потому что одна критическая ошибка в ядре, неправильный анализ use cases и т.п. могут сделать реализацию проекта невозможным и/или свести его полезность/применимость к нулю.
S>Почему нет? L>>Верхние два утверждения лежат в основе водопада, который, как известно, в разработке ПО не работает.
S>Спорное заявление,
Это не утверждение, а общепризнанный факт.
S>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду.
Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Здравствуйте, landerhigh, Вы писали:
S>>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду.
L>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Со скрамом обычно так — если до релиза не дожил, но всё по методологии, значит не скрам. А если дожил, но не по методологии, то это всё равно скрам
Здравствуйте, Pauel, Вы писали:
L>>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза. P>Со скрамом обычно так — если до релиза не дожил, но всё по методологии, значит не скрам.
Скажем так, правильное применение скрама тут видели человека три, не больше.
Только вот вопрос методологий разработки назрел намного раньше того, как скрам пришел в разработку софта.
P>А если дожил, но не по методологии, то это всё равно скрам
P>Исследование и проект это два различных рода деятельности, друг от друга никак не зависят. Как говорят "вещи ортогональные".
Спрошу еще раз: дайте определение термину "исследование". Желательно с позиций бизнеса, а не со стороны желающего эти исследования проводить.
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>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Это просто попугаи. Хрестоматийно — после разбиения проблемы на сторис (таски) полагается отранжировать таски по предполагаемым затратам (effort) для их реализации. А затем, самой легкой назначается 1 поинт или два, самой сложной — 10 (20, 40, 100500, неважно) и затем полагается играть в эстимейшен покер, используя эти таски как точки отсчета.
Задача не столько в том, чтобы оценить сложность каждой стори. А в том, чтобы создать конструктивную дискуссию. К пример, разногласие в оценке приводит к разговору, который по идее поможет команде увидеть, что стори, которая казалась довольно простой, на деле потребует намного больше усилий на реализацию.
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, SkyDance, Вы писали:
SD>>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. K>А как и где всю эту статистику смотреть? На ретроспективе собирать фидбэк и записывать с "блокнотик" для дальнейшей оценки/переоценки, подсчёта локов и т.п.?
Ее вообще не нужно смотреть и записывать.
Она — для команды.
См. "self managing teams".
На практике в джире ее видно в burndown chart, например.
Здравствуйте, Kernan, Вы писали:
SD>>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time. K>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Сторипоинт это скорее единица "массы" фичи, чтото навроде сложность*трудоемкость. Просто сама по себе сложность это качественная характеристика, потому её довольно трудно отделить от трудоемкости, которая количественная.
Трудозатраты получатся в том случае, если мы эту "массу" поделим на велосити команды или отдельного разработчика.
Здравствуйте, landerhigh, Вы писали:
SD>>>... и в скрам это все рассматривается и поддерживается. Вы вообще когда-нибудь работали по скрам? Там действительно учитывается "available time". Плюс задачи оцениваются не в "неделях" или "днях", а в "story points", которые позволяют отделить "сложность" от "времени". Чтобы потом, по мере накопления статистики, вычислить эту самую velocity, суть отношение story points/time. K>>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
L>Это просто попугаи.
У этих попугаев есть простой физический аналог навроде массы или работы, которую нужно затратить на перемещение массы на конкретное расстояние.
Здравствуйте, 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 (до сих пор жалею, что мало вложил, сейчас мог бы быть куда богаче). И нет, венчурным капиталистом я не был и не стану, ибо это отдельная профессия, в которой я не разбираюсь.
K>Сторипоинт это средневзвешенное значение трудозатрат в рамках спринта?
Нет. Выше landerhigh уже правильно объяснил — стори поинт — это "самая маленькая законченная фича в проекте".
Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться.
Это в официальном руководстве по SCRUM написано. Звиздун-собеседник, конечно же, мастерски может послать все это вдоль и наговорить массу умных слов в свое оправдание. Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.
SD>Ни тот, ни другой не являются коммерческими продуктами.
Вы еще скажите, что на разработку Rust бюджеты не выделялись. Разработку Scala никто не спонсировал, Go/Dart в Google в свободное от работы время и за свой счет пилили и пилят, равно как Kotlin в JetBrains, да RedHat ничего своим сотрудникам не платил за Ceylon. Сплошной энтузиазм, ага
SD>Любые проекты на базе энтузиазма не рассматриваются бизнесом как проект.
А вы не только за "якобы" SCRUM, но еще и за бизнес можете позвиздеть? Ну сильны, чё.
По итогу: натрындели вы здесь много, но ничего конкретного не сказали: ни своего примера исследовательского проекта не привели, ни описали как же должно выглядеть применение SCRUM для исследовательских задач. Разве что общий звиздежь о том, что "все украдено до нас" и "идей вокруг полно".
Здравствуйте, Sharov, Вы писали:
P>>Упал стейджинг — срочная активность, т.к. и девелоперы, и тестировщики, и даже кучка юзеров в превью — все заблокированы.
S>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы.
Что вы имеете ввиду? Фикс то всё равно нужно сделать, и это срочная работа.
