Счас вы всю правду выболтаете. Не понятно станет, какой стек технологий проверять в резюме. :)

Думаю важно техническое образование. Практики - дело наживное.

Плюсую. Тоже интересно

Здравствуйте, лично для меня как РО качество инкремента - это то, что нет критических багов (а про некритические я просто не знаю 😊 ) и то что фичи, которые успели сделать работают на обзоре так, как "интуитивно" предполагали на планировании. А если команда подумала и сама в ходе спринта дополнила фичу вишенкой на торте 🍰 и эта вишенка имеет бизнес-выгоду и работает, то это супер качество

поддерживаю!

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

"Как-то раз заказывает 2 командам заказчик бетонный самолет 🛩  В срок сдачи приходит заказчик к китайской команде, смотрит, на полосе стоит бетонный самолет, выполнен идеально, заходят в кабину пилота, спрашивают: "А дальность полета какая?" - "Дальность?!! Это же бетонный! В ТЗ про то, что он летать должен ни слова!"

Ладно, пошли ко второй российской команде: "Где самолет?" Полоса пустая. Команда говорит "Поехали, покажем". Приезжают на вокзал, команда говорит - "Мы вот подумали, нафига вам бетонный самолет, он же летать не сможет, а вам же передвигаться нужно, вот мы и решили за те же деньги сделать вам настоящий паровоз 🚂!"

Кто более качественно отработал задачу?

Это точно про Agile?

Agile прежде всего про взаимодействие людей с людьми, чтобы понять боль и сделать именно то, что нужно и вовремя. Вопрос выше был про качество разработки в ходе спринта. Инкрементом может быть качественно сделанный бетонный самолет, либо понятая боль заказчика и паровоз

Выглядит как косяк аналитика, который в обоих случаях видимо не задавал вопросы

Всех вопросов задать невозможно, да и заказчик (или РО) не знает ответов на все вопросы. А потом никто не отменял закон Чизхолма

Простите, а не решается ли этот кейс через вопрос о предназначении продукта?
Бетонный самолёт - это ответ. Задали ли мы вопрос? (например «для чего вам самолет и почему именно из бетона»)

Ответом может быть «освоить бюджетные деньги» - тогда вообще оба варианта подходят)

Простите, но ЩТО

Докину.

"Качество — степень соответствия совокупности присущих характеристик объекта требованиям"

Эти требования - потребности, а они могут быть явными и неявными.

Поэтому качественно то, что в большей степени по совокупности свойств отвечает вашим хотелкам стейкхолдеров (тех кого затронет продукт или услуга и кто имеет на него влияние)

В этой призме притча про паровоз выглядит странно

В связи с тем, что я «болен» статистическим управлением качествами, то поделюсь своим мнением и знаниями на данную тему.
Можно выделить качества технические. Они заданы идеальными размерами и допусками – интервалами, в которых возможно отклонение от идеального размера. Эти допуска принято обозначать 3 Сигма. Изделие, выполненное с такими допусками считается качественным.
В Lean когда позволяет ситуация работают над тем, чтобы снизить уровень неопределенности отклонений размеров. Ставится инженерам и исполнителям задача подтягивать 3 Сигма максимально близко к идеальному размеру, то есть стремятся превратить 3 Сигма в 2 Сигма, а затем в 1 Сигма.
Это приводит к тому, что износ деталей при их работе снижается и у потребителя повышается срок использования продукции. Плюс происходит улучшение технологий и процессов производства, что зачастую открывает перед компанией новые возможности и в других направлениях.
Можно выделить качества организационные. Здесь можно выделить организацию надежной повторяемости изготовляемой продукции или услуг – это обеспечивается процессом производства продуктов и услуг. Здесь же можно выделить организацию проектных работ для производства новых продуктов и услуг. Здесь же можно выделить организацию гибкой перестройки процессов в случае изменений внешней или внутренней среды.
Можно выделить качества психологические – это когда проявляется уважение к сотрудникам, партнерам и клиентам (бирюзовость).
Можно выделить качества организационно – психологические – это когда для снижения рисков, условно обозначаемых теми же 3 Сигма проводятся проектные работы(в том числе технические) по облегчению и улучшению работы сотрудников, партнеров или клиентов. Проектные работы превращают в процессы, чтобы масштабировать и распространить передовой опыт.
Можно выделить качества – риски. К ним относят политические, экономические, финансовые, логистические, техногенные, природные и т.п. Актуальные для компании риски стремятся наблюдать и исследовать статистически. Им также присваивается индекс 3 Сигма. Организационно стремятся найти подходящие решения, чтобы снизить эти риски. Какие то решения становятся процессными и они прописаны например в ИСО 9001, а какие то подходящие решения принимают непосредственно исходя из ситуации.
Подходящими решениями как правило являются те, что закрывают уже имеющуюся на рынке потребность. Потребность может быть сформированной и выражена конкретной продукцией, находящийся в дефиците или доступной не широкому кругу лиц. Потребность может быть на какую то деятельность, которую с успехом могут закрыть новые, еще не существующие на рынке продукты или услуги. В этих направлениях в основном производят организационное, техническое, кадровое и партнерское развитие. В связи с тем, что потребность чаще всего носит циклический спрос, то предпочитают развивать организационную гибкость и бережные отношения к сотрудникам и партнерам.

А вы точно не путаете scp и 6сигм, а также поле допуска с собственно допуском?

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

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

Не совсем понял причем тут 9001, вроде в версии 2015 года про принятие решений ничего не было.

Про самолет это анекдот вообще-то. Приведу пример, в одном из наших проектов заказчик указал в требованиях "нужно в системе документооборота сделать конструктор отчетов, любых" и все менеджеры подписали, хотя специалисты-разработчики говорили, что такого в принципе нет в природе ни в одной российской платформе, но у них не было выхода с этой информацией наверх. В итоге когда ТЗ дойдет до разработчиков - им что делать? Сделают паровоз

9001 - это например. Про 6 сигм я ничего не говорил. Я высказался про качества в том виде как я их понимаю и специально привел риски как примеры качеств. Как в ИТ, так и в традиционных компаниях легко запутаться в многозадачности, особенно если разбирать теорию, а не брать задачу из реалий жизни. В реальной жизни всегда можно найти одно самое узкое место и принять решение по нему. Разумеется организовав групповое обсуждение с теми людьми где находится это узкое место, чтобы именно для них это решение оказалось уместным и подходящим.

Здравствуйте, IMHO здесь как раз лучше собирательный образ не делать, т.к. Agile-коуч - это далеко не всегда ступень развития SM. И если SM для нормального ежедневного общения с командой нужно хотя бы в общем разбираться в процессе разработки, то коучу совсем необязательно.

Задача коуча - повысить осознанность и внимательность к элементам поведения человека. 80% полагаемся на собственные ресурсы человека, и 20% - это подталкивание человека если он застрял. "Ученик" коуча обучается на основании своих знаний и техник коучинга.

И даже SM нужно времени выше крыши для изучения техник в своей зоне.  SM просто некогда погружаться детально в ХР, TDD и т.п., если только он не подменяет тестировщиков/аналитиков или совмещает эти роли.

Артём, даже из дискуссий выше видно, что понятие качества неоднозначно. Стало быть, когда мы собираемся что-то-там обеспечивать, контролировать, сохранять или улучшать, то самого по себе термина 'качество' недостаточно.

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