Здравствуйте, SkyDance, Вы писали:
SD>Теоретически, через какое-то время можно будет прикинуть и перевод этой единицы в некие "трудозатраты", но на практике это бессмысленное мероприятие, т.к. от спринта к спринту velocity меняется, причем порой весьма заметно. Да и команда может меняться, расти или уменьшаться.
Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
Здравствуйте, landerhigh, Вы писали:
L>Если это нужно делать в 2023 году, то лучше всего будет убиться апстену.
Так-так-так, а поясни ка, как это так? А как же оценки делать? Бюджет, команду планировать?
Здравствуйте, Sharov, Вы писали:
S>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы.
Это всё херня на самом деле. Когда надо что-тио делать приходится просто садиться и делать вне зависимости то того девопс ты или нет.
Здравствуйте, Kernan, Вы писали:
L>>Если это нужно делать в 2023 году, то лучше всего будет убиться апстену. K>Так-так-так, а поясни ка, как это так? А как же оценки делать? Бюджет, команду планировать?
Здравствуйте, landerhigh, Вы писали:
P>>У вас здесь противоречие. Статистика смотрится в той самой джыре, на её основании планируются релизы итд, чем всегда интересуются вышестоящие менеджеры.
L>Еще раз — эта статистика не для планирования релизов.
Вот для интересу глянул в мануал, и нашел, что burndown chart нужен для вычисления вероятности завершения работ в установленное время. И этот момент завершения обычно и есть финальный релиз.
Здравствуйте, Pauel, Вы писали:
S>>Кажется, что для этого devops придумали. Чтобы остальные быле не заблокированы. P>Что вы имеете ввиду? Фикс то всё равно нужно сделать, и это срочная работа.
Безусловно, но оно может месяц работать нормально, потом упасть. И devops поднимает, а разработчик
может пока заниматься текущими задачами, и приоритизировать исследование месячных падений.
Суть в том, что разработчики не бегут сломя голову поднимать систему. Или речь о том, что пока
баг не найден и не исправлен, систему поднимать не стоит? Фикс разный может быть, если падатает
крайне редко и по особым случаям, то жить можно.
Здравствуйте, Sharov, Вы писали:
S>Суть в том, что разработчики не бегут сломя голову поднимать систему. Или речь о том, что пока S>баг не найден и не исправлен, систему поднимать не стоит? Фикс разный может быть, если падатает S>крайне редко и по особым случаям, то жить можно.
Я говорю про срочные фиксы. Понятно, что когда жить можно, то горячки нет.
Здравствуйте, landerhigh, Вы писали:
S>>учитывая что и до скрама писался большой и нетривиальный софт. В том числе и по водопаду. L>Тут надо брать экскурс в историю разработки ПО, выводить определение нетривиального софта и т.п. Потому что куча проектов даже не доживала до релиза.
Писались же крупные системы типа ОС или бд, под 1млн. строк кода. Без всякого скрама. Др. вопрос,
что в массе своей все это писалось математиками и физиками, а не закончившими курсы. Кмк, уровень был
в массе своей выше, выше была дисциплина, меньше всяческих дистракторов и т.п. Поэтому можно было жить
и без скрама. Т.е. когда все зависило от исполнительского мастерства, тогда особых проблем не было.
Как отрасль стала массовой, решили тащить с помощью менеджерских практик. Так вижу.
Здравствуйте, Kernan, Вы писали:
SD>>Спринты позволяют В СРЕДНЕМ понять, сколько у вас уходит на проверку гипотезы, сколько на саппорт, сколько на что-то еще. K>А как и где всю эту статистику смотреть? На ретроспективе собирать фидбэк и записывать с "блокнотик" для дальнейшей оценки/переоценки, подсчёта локов и т.п.?
Здравствуйте, 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 достаточное.
Здравствуйте, 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 для исследовательских задач. Разве что общий звиздежь о том, что "все украдено до нас" и "идей вокруг полно".
Ну вот, вы в итоге скатились в хамство. Ок, ваш выбор. Я уже дал более чем достаточно объяснений и описаний того, что работает.
K>Погоди, но как же оценки по проекту? Что делать если надо нарисовать диаграмму Ганта, расставить майлстоуны? Без оценок по времени это не получится сделать.
Этому скрам не обучен. Он работает в обратном направлении: к проекту есть требования (по реализации тех или иных фич), лежащие в том самом бэклоге. Который не статичен: в него добавляются все новые и новые задачи (в некоторых случаях могут и удаляться, но как-то в моей практике это было совсем редким событием).
С течением времени, на основании накопленной статистики (team velocity в первую очередь) при неизменном бэклоге можно делать некие приблизительные (с точностью до пары спринтов) оценки завершения проекта. Но, во-первых, мне еще ни разу не попадался статичный бэклог, а во-вторых, диаграмму Ганта из бэклога сделать не получится (хотя зависимости между тасками в бэклоге могут быть видны).
S>что в массе своей все это писалось математиками и физиками, а не закончившими курсы. Кмк, уровень был S>в массе своей выше, выше была дисциплина, меньше всяческих дистракторов и т.п. Поэтому можно было жить
Дело не столько в дисциплине, сколько в мотивации: то, что "писалось математиками и физиками", обычно было на энтузиазме. Которого при разработке типового интернет-магазина (или очередного "революционного подхода к RPC") скорее всего не будет, т.к. людей нанимали работать за деньги.
Здравствуйте, 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
Когда у нас были такие митинги, до середины мало кто доживал.
Просто очередная реализация того же, что уже было реализовано десятки раз до, и будет реализовано десятки раз после. Причем реализация тривиальная. Проще, чем сделано, скажем, во все том же Erlang. Который, кстати, был настоящим исследовательским проектом, и там была research lab, без скрам, без спринтов, но зато с энтузиастами, настоящими энтузиастами своего времени. Им дали время на решение той задачи, которую они сами хотели решить. Коммерческим проект не планировался (и не стал, кстати).
