Успешных - это каких? не разогнали команду? продукт приносит бабло?

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

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

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

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

это понятно. я и не говорю, что горизонтальная команда не может быть успешной в 100% случаев. вопрос был в другом - успешность продукта достигалась личными усилиями людей или же эффективно организованным процессом разработки и контроля качества? потому как груминги это конечно здорово, но стандартный разработчик не должен думать, все ли юз кейсы описаны в требованиях - если он это делает, это его личный и никем не оплачиваемый труд. эффективно организованный процесс разработки же предполагает, что на каждом этапе фича проходит через разных людей и каждый из них сосредоточен в определенный момент времени только на одной задаче, например разрабу - писать код, бизнес-аналитику - собрать всю необходимую бизнес-инфу, тестеру - описать все необходимые тест-кейсы. поэтому я и писал, что аджайл-команда должна быть шкурно заинтересована в успехе продукта - у них есть реальный профит и "оплата" их дополнительных усилий. если они все это делают и при этом получают оклад - это риск. может ли быть успешным проект при таком раскладе? Да, конечно. Эффективен ли он с точки зрения процесса доставки ПО на прод в желаемом качестве? Нет, слишком много усилий от каждого члена команды в областях, в которых у них нет экспертизы

Какое то черно белое распределение между вертикалкой и тимой

А вот это я запомню. Вдруг спросят за метрики... "Да ты не видишь! Деплойменты без даунтаймов". Извини. Не злобы для, просто как то наивно звучит

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

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

>успешность продукта достигалась личными усилиями людей или же эффективно организованным процессом разработки и контроля качества В горизонтальной команде это взаимосвязано, по-моему. Без усилий каждого члена не будет эффективного процесса. >если он это делает, это его личный и никем не оплачиваемый труд Если он делает это с 8 до 17 часов, то это оплачиваемое время) >эффективно организованный процесс разработки же предполагает, что на каждом этапе фича проходит через разных людей и каждый из них сосредоточен в определенный момент времени только на одной задаче Это признаки какого-нибудь RUP и остальных waterfall-like процессов, а не эффективного процесса в целом. В аджайле/скраме значение ролей меньше и границы между ролями сильно стёрты. Соответственно, критерии для исполнителей под каждый процесс отличаются. В скраме люди должны быть более мотивированными и иметь T-shaped скиллы, в рупе можно уметь делать только что-то одно и без особого рвения. Как итог - в рупе за качество будет отвечать куа лид, а в скраме - вся команда, включая девелоперов и аналитиков, а не конкретный тестер Вася. >аджайл-команда должна быть шкурно заинтересована в успехе продукта Работал в нескольких проектах на аутстаффе - часть команды была со стороны заказчика, часть с моей галеры. У аутстафферов не было акций компании заказчика или ещё какой-то финансовой мотивации, но они работали как для себя (и иногда по выходным), потому что была хорошая командная атмосфера и для мотивированного инженера главный интерес - сделать круто и правильно, а не “насрать, и так сойдёт”. И наоборот - был проект в продуктовой конторе, где продукт овнер хотел любую фичу ещё вчера, девелоперы писали спагетти код, у тестеров не было времени прогнать регрессию и в итоге получали факап на факапе. Так что шкурный интерес может подавляться общей некомпетентностью команды >если они все это делают и при этом получают оклад Если ты имеешь в виду стартапы, где люди работают забесплатно за будущие опционы, то для них скорость релиза MVP намного важнее качества и тестировщиков на этой стадии обычно вообще нет >Эффективен ли он с точки зрения процесса доставки ПО на прод в желаемом качестве? Нет Есть какие-нибудь пруфы со сравнение эфективности между скрамом и твоим идеальным процессом?

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

"сосредоточенность каждого на одной задаче" совершенно неявно предполагает, хе-хе, всезнание: - разработчик точно ВСЁ знает что нужно, что может заимпактить, как это будет тестироваться. - аналитик точно знает как ВСЁ это работает и какие флоу будет прогонять тестировщик, - тестировщик точно ВСЁ знает "что под капотом", и чего больше хотят. На практике периодически случалось что каждый держит "свой конец слона", и разработчик-тестировщик-аналитик потратят меньше времени если обо всём договорятся, рассказав друг другу и сведя друг с другом информацию про ту часть слона которую они держат и будут делать. Если друг с другом НЕ общаться, потом получается: - Аналитик или кто на его месте написал спеку, получил 40-30 вопросов и замечаний, потому что "это так не работает, то так не называется и тоже так не работает, а вот так мы будем делать пол-года, но можно вот этак и месяц" - Разработчик честно делал задачу но почему-то решил сам сделать графику растровым вариантом А, а надо было векторным вариантом Б. Главный дизайнер говорит что так релизить никак нельзя, поехали переделывать. - Разработчик честно делал задачу, но зааффектил другую фичу которая в требования к задаче не попала, а вообще она есть и используется. Поехали переделывать ещё спринт. - Разработчик рассказывает тестировщику что будет под капотом, тестировщик уменьшает эстимейты на тестирование. - Тестировщик показывает как по этой фиче сделать "даже меньше пейрвайза", команда соглашается что "ну давайте так попробуем". - Аналитик и разработчик выкатывают вариант, UX дизайнер говорит что это не сойдётся с оптимальным для человека дизайном и наглядно показывает как сделать лучше. - Тестировщик сразу начинает задавать вопросы "а может по-нормальному сделаем?", потом после трёх недель разработки за три дня (допустим) "убивает" фичу, находя пример когда фича как она реализована по требованиям репортит полную лажу. Принимается решение всё-таки делать по-нормальному. Практическая польза от встреч всех участников-стейкхолдеров определённо была, что наглядно демонстрировало что будет лучше если участники процесса будут между собой немного больше общаться, а не "просто каждый на своём месте". (+) И, как всегда, не понимаю почему люди думают что если они говорят слово "процесс", сразу начинает работать какая-то особая магия.

Ну, есть разные школы и убеждения. Школа которая думает что без метрик никуда вообще во всём. Люди которые задают вопросы в духе (утрируя) "ну а как без метрик карать нерадивых рабов?" Школа которая ищет слабое или критическое звено (по заветам Голдратта) Школа которая предупреждает про опасностях метрик, и что метрики должны быть поводом для вопросов, а не для карания {известные в тестировании Канер, Болтон, Бах} Школа которая говорит о том как через метрики показывать заказчику что вы что-то улучшили {известный в кругах Антон Семенченко про это не раз говорил} С одной стороны я знаю пример когда один менеджер планировал ввести метрики, но был настолько плохим человеком что от него поразбегались — из команды, из компании, — и были проблемы с заполнением позиций в "его" командах. С другой стороны, я верю Семенченко который обосновывает что некоторые соображения-аргументы могут быть очень убедительны для заказчика, я верю обоснованиям Голдратта, и у Болтона есть пост что метрики могут применяться как индикаторы и поводы для улучшений, а не как карательный инструмент.

Раз в год и палка стреляет) если 10 лет непрерывно считать метрики, то может случиться так, что один раз из них удастся получить инсайт. Но кпд этого процесса выглядит очень низким (за 10 лет работы не видел ни одного такого случая) Поэтому я и хочу послушать истории успеха, когда в некризисном процессе кто-то посмотрел на какую-то метрику и его осенило, что там можно что-то улучшить и это сработало (метрики по покрытию кода и трейсабилити не в счёт) >через метрики показывать заказчику что вы что-то улучшили Против этого ничего не имею, но обычно сначала формулируют задачу по улучшению, а потом считают конкретные метрики до/после, а не наоборот. Но Сергей тут предлагал метрики считать превентивно и без конкретных целей

данный текст описывает ситуацию, когда, действительно, условные аналитик, разраб и тестер не знают своего продукта. т.е. аналитик не знает бизнесчасть или системную часть, разраб не имеет маппинга по своим фичам или хоть каких-либо описаний того, что же он, собственно, пилит, а тестер "уменьшает оценку на тестирование" после слов разработчика" <-- вот от этого я прям ржанул бы, если б не было так грустно. честно сказать, вышеописанное лично встречал как раз в скрам-командах. на водопадах настолько дикое пренебрежение наличием знаний предметной области не встречал - на одном проекте, например, менеджеры, которые работали с заказчиком и одновременно являлись экспертам по предметной области, специально расписывали и словами объясняли на примерах, что нужно сделать разработчику, потому как знали, что этот разраб щас уйдет в свободный кодинг на две недели. факап с тем, что запилили "не то", на этом проекте был один раз - один раз на 30 разрабов и 2.5 года моего с ними сотрудничества. сколько таких факапов было в каждой скрам-команде - пальцев рук и ног десяти человек не хватит сосчитать

+ Такой же опыт