(да, я хорошо умею доводить ситуацию до абсурда) :)

да хрен там

продаем телефон в россию

проходим все ростесты

их невозможно не пройти

К Игорю приходит ФСБ и спрашивает "чойта ты, мил человек, весь такой инновационный, КОМПОНЕНТЫ ЯДЕРНОГО ОРУЖИЯ ПРОДАЕШЬ?".

Добро пожаловать в Черный Дельфин. Твоя компания теперь пренадлежит полковнику Чепиге и он продает твои телефоны по цене х100 самому ФСБ :)

К Игорю приходит ФСБ и спрашивает "чойта ты, мил человек, весь такой инновационный, КОМПОНЕНТЫ ЯДЕРНОГО ОРУЖИЯ ПРОДАЕШЬ?".

ой да камон ФСБ пофигу на это :D им главное людей контроллировать. я скажу что только благодаря этим компонентам - можно будет слушать что люди в этом телефоне говорят 24/7

А всего можно ыло бы избежать, если бы ты заложил compliance в DoD

и никогда его не выключать

вообще убрать возможность его выключть и следить за всеми.

ФСБ будут только рады

еще и денег из бюджета дадут

А всего можно ыло бы избежать, если бы ты заложил compliance в DoD

но зачем? у нас же инновации

меняем мир. внедряем ториевые батарейки в телефоны.

а так мы бы выпустили очередной говнотелефон который разряжался бы через 2 часа использования.

а если бы внедрили ненужные сертификации в DoD - отрезали бы себе путь к инновациям.

https://www.scrum.org/forum/scrum-forum/7314/non-functional-requirements

Вот заодно дискуссия на scrum.org

не иметь доступа к данным пользователей? это не функциональное требование?

https://www.scaledagileframework.com/nonfunctional-requirements/

ну и тут, если вас SAFe не пугает :)

не иметь доступа к данным пользователей? это не функциональное требование?

Почитай статью с SAFe - там хорошо и кратко про то, что такое NFRы и какие они бывают.

там заодно список литературы полезный внизу :)

Не сейфовской литературы :)

[4] Larman, Craig and Bas Vodde. Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley, 2010. Вот это мне особенно понравилось :) @gospodchikovs заценит :)

я вот читаю и понимаю что NFR являются частью беклога

типо как стори только NFR

И под частью бэклога ты имеешь ввиду PBI?:)

Нет, это не как сторя. Это свойство системы целиком.

Ну вот как у тебя usability может быть PBI? Или security?

У тебя могут быть PBI улучшающие определенынй аспект NFR предлагая какую-то функцию.

Как делать "железный" продукт не противореча гайду?:)

FPGA

FPGA

?

Не, если интересно, я могу описать, как делать железо скрамом на практике.

Это уже специализированный разговор, давай в личке продолжу =)

Не, если интересно, я могу описать, как делать железо скрамом на практике.

Но это поясни, конечно

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

Игорь, в целом, правильно написал - прототипы.

Другое дело, что каждое реение, прежде чем попасть даже в прототип, проверяется на способность пройти аудит. Либо считается результатом спайка, созданногос угубо для проверки нужд клиента.

У тебя могут быть PBI улучшающие определенынй аспект NFR предлагая какую-то функцию.

ну могут и в чем проблема? мы делаем прототип системы - зачем нам шифровать данные людей, если людей там нет.

Я fpga тоже не просто так упомянул. Для многих продуктов это может и в финальном решении остаться, не переходя в asic

https://us.getac.com/solutions/video/video.html

Вот это вот все, что тут красиво рекламируется - делалось scrum командами :)

ну могут и в чем проблема? мы делаем прототип системы - зачем нам шифровать данные людей, если людей там нет.

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

Про шифрование и то, к чему приводит забивание на него до последнего "для упрощения отладки" я много могу рассказать.

Только матом и непублично :)

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

так мы этого не узнаем. ибо вообще можем не знать как наша система будет использоваться пользователями :D

так мы этого не узнаем. ибо вообще можем не знать как наша система будет использоваться пользователями :D

Игорь, ну мы же имеем некоторые предположения о том, как система будет работать?:)

ну это пальцем в небо на самом деле :D можем угадать конечно а можем и нет. важно не шифрование а чем продукт поможет пользователю. остальное это все хрень.

А то покажешь ты красивый интерфейс пользователям, они радостно похлопают в ладошки, а потом ты добавишь шифровку, а тебе скажут "неее, медленно" :)

ну это пальцем в небо на самом деле :D можем угадать конечно а можем и нет. важно не шифрование а чем продукт поможет пользователю. остальное это все хрень.

Игорь, анализ потребностей немного сложней угадывания и далеко не всегда требует разработки :)

А то покажешь ты красивый интерфейс пользователям, они радостно похлопают в ладошки, а потом ты добавишь шифровку, а тебе скажут "неее, медленно" :)

пусть купят тогда будет шифрование :D

я пока не вижу проблемы которая была бы прям нерешаемая

Игорь, все решаемо. Зачем создавать проблемы на пустом месте?:)

так если пользователи не похлопают в ладоши - то шифрование никому не нужно будет :D

так если пользователи не похлопают в ладоши - то шифрование никому не нужно будет :D

А если без шифрования не купят или если из-за замедления работы после шифрования не купят - тоже плохо будет :)

Игорь, про такие вещи можно про модель Кано почитать.

да почему медленно то? будем развивать систему.

Ну или MoSKoW

Всякий комплаенс очень часто оказывается в Must

они же "must-be qualities"

слона надо по кусочкам есть

слона надо по кусочкам есть

Серьезно, почитай про кано :)

То, что ты говоришь - правильно, но ИМХО оно для стадий, предшествующих тем, где скрам имеет смысл применять

То, что ты говоришь - правильно, но ИМХО оно для стадий, предшествующих тем, где скрам имеет смысл применять

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

Когда ты исследование ведешь, тебе надо сужать скоуп исследования, делать каждый аспект отдельно - зачем тебе вообще инкремент в такой ситуации?

Делай быстро по одной фиче для проверки

инкремент нужен для того чтобы понять в правильном ли направлении я двигаюсь

Если ты про продукт ничего не знаешь, про пользователей ничего не знаешь - ты и команду собрать не можешь.

я могу знать про продукт "что то"

Не будет она у тебя всеми необходимыми скиллами владеть :)

так бизнес модель может переделываться со временем

и в команду будут добираться люди.

или переучиваться текущие

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

Игорь, если ты делаешь pivot под команду, а не под новые требования рынка - ты делаешь pivot неправильно :)

Игорь, если ты делаешь pivot под команду, а не под новые требования рынка - ты делаешь pivot неправильно :)

так команда переучивается под новые требования

а не форсирует эти требования

Ну и в целом, pivot вообще в новом направлении, без учета существующего проукта и знаний - это таки редкость.