R>обычно тебе нужны два QA с команды А по проекту А, нужны аналитик с команды Б, и допустим, какие-то работы по В и Г из таких-же команд.

То есть зависимости (dependencies). Пока зависимости не удовлетворены, ваша команда попросту не может брать конкретную user story в работу. В этом плане ничего не меняется — ровно так же и в "бардак-процессе", пока подрядчики не залили фундамент, стены строить негде.

Дело заметно упрощается, если подрядчики тоже работают по осмысленной методологии. И вы видите, когда будет готово то-то и то-то, хотя бы приблизительно (по их бэклогу, ибо он всем открыт). Но если у них "бардак-процесс", нет вообще никаких инструментов оценки, когда же нужные вам смежные технологии будут готовы.

R> И по старинке все также "Когда ресурс Васи даст нам, то о чем мы договорились? — До пятницы обещает дать"

Забавная перепрыжка. Обвинять скрам в том, что у вас там "ресурс Вася не дает", довольно странное занятие.
Тем более что скрам описывает работу команды, а не каких-то там "ресурсов". Более того, смысл скрам именно в том, что если "ресурс Вася" сломал руку-ногу-голову, в вашей же команде найдется Петя, который путь и не ресурс, но с помощью Саши и Маши осилит сделать нужную работу. На то она и команда. Прямо противоположно "silo development", где какой-то отдельный Вася что-то где-то свое пилит, и никто не может в запиленном разобраться и исправить.

R>что изменится в команде, если просто отказаться от SPs и банально перейти на время в днях

То, что день станет ненормированным. Начальством оценка в "два дня" воспринимается очень буквально — ожиданием, что через 2 дня все будет готово. Но реальность такова, что оно может быть готово и раньше, и позже. Поэтому оценочный "день" является плавающей величиной. Чтобы не смущать неокрепшие мозги менеджеров и заказчиков, такими вот "резиновыми" днями лучше не оперировать. Иначе получится занятное вычисление типа "наш оценочный день нынче равен 2,71 реальных, и это заметное улучшение с прошлого года, когда оценочный день был равен 3,14 реальных".

PS: а вообще Джефф писал немало статей с ответом на этот вопрос. Причем с данными наперевес. А это таки серьезно.

Во, вот это еще лучше. Вероятно, там и видео есть к презентации, но мне на глаза оно не попадалось.

Здравствуйте, r0nd, Вы писали:

R>Как вы, наверное, догадались я собрался говорить о Story Points (SPs) в скраме. Пару хороших слов об очередной "серебряной пули" в создании ПО

От SP уже даже их создатель отрекся, так что смысла в использовании точно нет.

На самом деле сама оценка задач до создания полного техдизайна — бесполезна в лучшем случае, а чаще — вредна. Да и вообще оценка в разработке почти никогда не имеет смысла (кроме очень примерной, до порядка, оценки эпика, используемой продактом для оценки приоритета).
Любовь скрам-мастеров что-то там оценивать и рисовать графики — просто свидетельство их некомпетентности, не более того.

Здравствуйте, r0nd, Вы писали:

R>Как вы, наверное, догадались я собрался говорить о Story Points (SPs) в скраме. Пару хороших слов об очередной "серебряной пули" в создании ПО (этому меня научили, ибо нельзя в говне находить одно только говно, надо "взвешенно и тщательно" отыскать и положительные моменты).

Мне вот так интересно.

Сейчас считается, что без всех этих срамов, code review, итераций и прочих новомодных штук разрабатывать софтварий (1) невозможно (2) не профессионально.

Все эти штуки родились на моих глазах. 20 лет назад о них даже никто и не слышал.

При этом любой современный проект процентов на 80 состоит из чужого кода, взатого из Интернета, процентов на 15 из клея, и, может, процентов 5 оригинального кода понапишут.

Весь этот опенсорс, из которого процентов на 80 состоит любой современный проект, в среднем пишется без всех этих срамов, code review и тестовых покрытий. И никого совсем это не смущает. Берут, как миленькие. А вот свои 15 процентов клея почему-то обязательно надо писать с соблюдением всех этих нелепых ритуалов.

Я не то, чтобы против code review, тестового покрытия и прочего срама. Они могут быть полезными, я не спорю. Они даже нередко бывают полезными. Удивляет совершенно религиозная вера, что без них никак. Особенно на фоне того, что большая часть кодовой базы любого проекта написана с соблюдением совершенно других процессов.

Это вещь появилась не как изначальная часть SDLC, она абсолютная искусственная и в тоже ничего не означает. Это поразительно. Она с одной стороны обязательно (чуть ли не на уровне стандарта) и призвана решать одну проблему, а с другой стороны — создает кучу других.

Как вы, наверное, догадались я собрался говорить о Story Points (SPs) в скраме. Пару хороших слов об очередной "серебряной пули" в создании ПО (этому меня научили, ибо нельзя в говне находить одно только говно, надо "взвешенно и тщательно" отыскать и положительные моменты).

pros

Самый жирный плюс. Проблемы вашей команды закончились, теперь никто не дергает вас "давайте перейдем, давайте перейдем на SPs". Все окончено, вы повержены и днище пробито, и вы уже перешли. Теперь только PROFIT.

Никто не будет отрицать, что если команда использовала SPs, то Scrum Master будут козырять графиками в Jira, показывать как член velocity команды растет квартал к кварталу. Итак, зафиксировали — красивые графики от Jira (будем честными с часами таких не выйдет).

Третья вещь — теперь можно занять команду игрой в карты в конференсе (это если офис открыт и нет COVID-а с заменой электронной подделкой неповторимого оригинала).

cons

Зачастую, никто в команде не понимает, какая "та самая маленькая задача", которую стоит оценивать как "минимум". Даже если ты задокументируешь в виде wiki-страницы с четким описанием и изъятиями, что это типовая(-вые) задача(-и) на 1 это (допустим) SQL-процедура с базовым SQL, в сопровождении и поставкой как минимум на тестовые стенды. Или какой-то базовый "фиксик" ETL-ки. В нее не входит то-то и то-то. Так вот, проблема в том, что понятие минимальной задачи меняется со временем (потому что команда растет, продукты развиваются, процессы усовершенствуются итд). И этот факт вносит такую корреляцию между фактом и ожиданием, что даже ведущие инженеры охреневают. Но терпят, чтоб только отьестали. И главное — все понимают это ничего не решает.

Второе, зачастую только какие-то примитивные команды работают сами с собой. Да есть какие-то проекты, которые завязаны только во внутрь (типа работы по техдолгу или внутренние проекты). Но, обычно тебе нужны два QA с команды А по проекту А, нужны аналитик с команды Б, и допустим, какие-то работы по В и Г из таких-же команд. И вот вторая проблема — SPs не всеобъемлющая процедура. То есть можем применять только внутри команды и то только с ограниченным списком ролей (ниже напишу). И по старинке все также "Когда ресурс Васи даст нам, то о чем мы договорились? — До пятницы обещает дать"

Третье (и пожалуй закончу, ибо выходит много текста). А вы никогда не замечали что эта хрень индифферентна для дизайнеров, аналитиков, аниматоров, devOps, QA-ев итд. Не, когда это было в часах всех все устраивало, но со SPs .

---

Задайте вопрос — что изменится в команде, если просто отказаться от SPs и банально перейти на время в днях (нравится покер — нет проблем каждая карта в днях) без этой наносной дичи типа маечки, трусики, "фибоначчи" (Какой еще фибоначчи? Половина твоей команды вайтишники и вышку для них учить в западло. какой еще "фибоначчи"?) Ничего не изменится, ведь художников, иллюстраторов, аниматоров, итд вы не занимаете этой х..й фибоначчи? Правда ж?

Здравствуйте, r0nd, Вы писали:

А почему одна то? Там весь скрам такой

R>Задайте вопрос — что изменится в команде, если просто отказаться от SPs и банально перейти на время в днях

В скраме горизонт планирования — одна неделя. На такой дистанции сроки можно и на глаз прикинуть. См. NoEstimates.

Здравствуйте, SkyDance, Вы писали:


SD>Пока зависимости не удовлетворены, ваша команда попросту не может брать конкретную user story в работу. В этом плане ничего не меняется — ровно так же и в "бардак-процессе", пока подрядчики не залили фундамент, стены строить негде.

	Off-topic
	Аналогии со строительством дома были актуальны примерно на рубеже 90-х. Современный процесс разработки ПО позволяет вам, не то что стены без фундамента построить, но и крышу без стен построить. Потом на следующих итерациях прорубить окна в дом, и в какие-то из комнат заселить жильцов, а в дальнейшем — вообще клонировать этот дом вместе с жильцами.

Насчет user story не совсем понял, у каждой команды свой user story. Как влияют user story одной команды на user story другой команды?

Как бы то ни было, мой пример он из практики, никто не говорит "Иван будет готов приступить к тестированию ваших задач, когда окончит нашу задачу на 3/5/7 попугаев", но зато все говорят "Ивану осталось еще 1 день". То есть на планировании, например, считают в попугаях, а в реале — "завтра закончу, еще два дня, сегодня готов брать новую". Разве не слышали таких ответов?

Про это ж и разговор, что показатель в SP неконвертируемый, непредсказуем, искусственный и что еще хуже — подвержен волатильностью.

SD>если подрядчики тоже работают по осмысленной методологии.

Как вас касается методология разработки, удовлетворяющая нужды другой команды? Я не совсем понимаю, что означает "осмысленной методологии"? Предложите список, какие методологии могут быть "осмысленной методологии"? Все, которым учат в PMI (по PMBOK)?

R>> И по старинке все также "Когда ресурс Васи даст нам, то о чем мы договорились? — До пятницы обещает дать"

SD>Обвинять скрам в том, что у вас там "ресурс Вася не дает", довольно странное занятие.

Я обвиняю Scrum? Это сильно. Удобная позиция, ты не высказался ни против использования SP в скраме, ни за использование SP в скраме.

SD>Тем более что скрам описывает работу команды.

Остановись, мы говорим про роль Story Points в скраме, а не про скрам в целом.

R>>что изменится в команде, если просто отказаться от SPs и банально перейти на время в днях

SD>То, что день станет ненормированным.

Ненормированный рабочий день – это форма организации рабочего времени, при которой сотрудники имеют гибкий график работы, который не строго привязан к определенным началу и концу рабочего дня.

У тебя нормированный день?

SD>PS: а вообще Джефф писал немало статей с ответом на этот вопрос. Причем с данными наперевес. А это таки серьезно.

Джефф — бенефициар. То есть "он бабло с базара имеет". Нужно мнение незаинтересованного лица, который на протяжении 5-10 лет работал в командах где был скрам с SP. И знает плюсы и минусы. А не шедевры типа:

The way we do story point estimation is better than hourly estimates as it is more accurate and has less variation. A CMMI Level 5 company determined that story point estimation cuts estimation time by 80%, allowing teams to do more estimation and tracking than a typical waterfall team. A telecom company noticed that estimated story points with Planning Poker was 48 times faster than waterfall estimation practices in the company and gave as good or better estimates.

Здравствуйте, Дельгядо Филипп, Вы писали:


ДФ>От SP уже даже их создатель отрекся, так что смысла в использовании точно нет.

Не совсем понял о ком идет речь и о каком высказывании/статьи?

ДФ>Любовь скрам-мастеров что-то там оценивать и рисовать графики — просто свидетельство их некомпетентности, не более того.

Видимо я не ясно выразился, конечно у скрам-местаров любовь не к графикам как к объекту искусства, а к баблу от этих графиков. Поскольку процесс персональной оценки мастеров с KPI/OKR почти всегда опирается на "рисунок" таких графиков.

Pzz>Все эти штуки родились на моих глазах. 20 лет назад о них даже никто и не слышал.

20 лет назад скрам уже вовсю был. Может и раньше был (под другим соусом), но тогда я еще не был в индустрии.

Pzz>Весь этот опенсорс, из которого процентов на 80 состоит любой современный проект, в среднем пишется без всех этих срамов, code review и тестовых покрытий. И никого совсем это не смущает.

Во-первых, смущает. Записывается в графу "риски".
Во-вторых, разработка хобби-опен-сорс — совсем не то же, что и бизнес-проект для заказчика.

Pzz> Удивляет совершенно религиозная вера, что без них никак.

Нет ее, ни религиозной, ни какой-то еще веры. Есть просто один из вариантов упорядочивания происходящего. Других вариантов — пруд пруди. Pick your poison, что называется.

R>Аналогии со строительством дома были актуальны примерно на рубеже 90-х. Современный процесс разработки ПО позволяет вам, не то что стены без фундамента построить, но и крышу без стен построить.

Ровно так же и со строительством дома. Аналогия более чем уместная. Включая последующий ценник на "интеграцию" такой крыши без стен.

R>Насчет user story не совсем понял, у каждой команды свой user story. Как влияют user story одной команды на user story другой команды?

Так это вы начали про dependent tasks, когда невозможно предсказать (из-за бардак-процесса?), когда та или иная зависимость будет удовлетворена.

R>Как бы то ни было, мой пример он из практики, никто не говорит "Иван будет готов приступить к тестированию ваших задач, когда окончит нашу задачу на 3/5/7 попугаев", но зато все говорят "Ивану осталось еще 1 день". То есть на планировании, например, считают в попугаях, а в реале — "завтра закончу, еще два дня, сегодня готов брать новую". Разве не слышали таких ответов?

Такие ответы имеют смысл только если пресловутый Иван прямо сейчас работает над этой задачей. Потому что иначе ответ "нужен еще один день" не дает ровным счетом ничего — завтра все так же будет "нужно еще один день". А может и не один, а то может и не день, а неделю. Иными словами, нужно какое-то время, и неизвестно, когда конкретно это время будет. Поэтому можно честно сказать "эта задача — 1 story point, но мы в этот спринт ее не берем, а значит, ближайшие 2 недели (или сколько у вас там длина спринта) ваша зависимость не будет удовлетворена". Планировать становится проще, чем с непонятными "завтра закончу", которое реально оказывается месяцем.

R>Про это ж и разговор, что показатель в SP неконвертируемый, непредсказуем, искусственный и что еще хуже — подвержен волатильностью.

Так в этом и смысл SP — получить статистику по этой конвертации. На длительных отрезках проектов становится более-менее понятна средняя скорость движения. Если хотите, вы можете свои story point'ы обзывать "рабочими днями", и конвертировать уже по новому курсу.

R>Как вас касается методология разработки, удовлетворяющая нужды другой команды?

Так если мы зависим от другой команды, как еще мне знать, когда эти зависимости будут удовлетворены?

R>Я обвиняю Scrum?

Да, это даже в заголовке выражено.

R>Джефф — бенефициар. То есть "он бабло с базара имеет". Нужно мнение незаинтересованного лица, который на протяжении 5-10 лет работал в командах где был скрам с SP. И знает плюсы и минусы. А не шедевры типа:

Видишь ли, Джеф понимает, о чем пишет, потому что видел, как это работает. И знает, почему. Я тоже видел. И тоже сначала не верил, но потом, по мере осмысления происходящего, понял, что работает, как, и почему. И какие есть региональные особенности.

Здравствуйте, SkyDance, Вы писали:

Pzz>>Все эти штуки родились на моих глазах. 20 лет назад о них даже никто и не слышал.

SD>20 лет назад скрам уже вовсю был.

Ну "вовсю," пожалуй, очень ту мач сказано В начале 2000х отцы скрамов только начинали "манефестить" эти методологии.

Здравствуйте, r0nd, Вы писали:

R>Как вы, наверное, догадались
Не угадал

Здравствуйте, Pzz, Вы писали:

Pzz>Весь этот опенсорс, из которого процентов на 80 состоит любой современный проект, в среднем пишется без всех этих срамов, code review и тестовых покрытий. И никого совсем это не смущает. Берут, как миленькие. А вот свои 15 процентов клея почему-то обязательно надо писать с соблюдением всех этих нелепых ритуалов.

Откуда известно про "в среднем"? Весь этот опенсор пишется конкретными людьми, которые предоставляют
консалтинговые и проч. услуги будучи зачастаю организованны в фирмы. И вот эти фирмы вполне могут работать
по скраму внутри. Т.е. коммиты на gh могут иметь какой-нибудь тикет во внутренней джире.

Здравствуйте, r0nd, Вы писали:

R>Это вещь появилась не как изначальная часть SDLC, она абсолютная искусственная и в тоже ничего не означает. Это поразительно. Она с одной стороны обязательно (чуть ли не на уровне стандарта) и призвана решать одну проблему, а с другой стороны — создает кучу других.

Скрам это банальный лохоразвод, который пиарили с каждого утюга, безусловно в нем много полезных практик: DoD, дельта продукта, пересмотр, только целостно он никакой, его стоит изучить, но не применять целиком.
В скраме никогда не говорят про применимость, т.е. где находится та граница, где он будет эффективен, а где нет. Почему по итогу оценка в SP должна сходиться? Никто SP факторами не занимается, в одну оценку факторы компенсируют друг друга, в другую оценку усиливют. Почему авторы фреймворка не начинают с успешных продктов, а постулируют об успешных процессах бездоказательно. Что успешного сделал автор скрама — непонятно.
Чему у него точно можно научиться, так это продавать и весь американский рынок он про это, успех продукта — это его востребованность.

Если хочется понять/скорректировать процесс, то надо исследовать опыт успешных продуктов, эти продукты доказывают, что их процесс жизнеспособен в текущих реалиях.
Например ядро линукса, хром и т.д. Процесс разработки в ядре линукса вообще должен быть изучен мегадетально и описан в деталях. Продукт, который работает без стори поинтов на миллионах устройств с высочайшей сложностью и легаси.
Либо какой-то успешный стартап, который действительно был сделан быстро и в короткие сроки.