ssw_spb

Сейчас вот покатал по поверочной плите, все ровно.

на spb.leroymerlin.ru пока еще есть

На здоровье

У вас, похоже, опыт в разработке ограничен пользовательскими приложениями

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

Та-же история, только лет побольше. И примеры к сожалению есть.
1. Разработка внутреннего инструмента для компании разрабатывающей процессинговый софт, работал там два раза, во второй был скрам: ПМ, команда только из меня одного — кончилось быстро и плохо, свалил оттуда.
2. Крупная банка — разработка бизнесс процессов на Pega PRPC, половину команды фактически уволили по решению самой команды. Обучил сменщика и свалил.
3. Мелкий стартап, куча безумных людей со стеклянными глазами делающими вид, что они работают по скраму, ушел на испытательном сроке.
Вчера друг уволился из лавки, проработав 1 месяц, послал в задницу скраммастера приглашенного в лавку для выстраивания процессов, поговорил с СТО и уволился текущим днем, пользуясь тем, что еще испытательный срок.
Было и пару положительных опытов, например сейчас, когда мы пилим софт, в котором есть работающий код 1998 года, правда скрам у нас очень относительный.

Антон, Вы пытаетесь мыслить логически, но в частном случае, когда скрам работает. Я-же писал, что его используют везде, где можно и нельзя, надо и не надо. И упорно продолжают жрать кактус в надежде на светлое будущее.
Скрам это не то что написано в СкрамГАйде, а то что из него делают отмороженные люди со стеклянными глазами. Никогда не работали в таких компаниях? Я работал к сожалению, хорошо, что есть испытательный срок, когда можно просто сказать «до свидания нам не по пути».
На самом деле было интересно пообщаться с разумными людьми (в этой теме), которые могут аргументировать свою точку зрения на разработку, почему-то в жизни мне попадается другой вариант.

Да нет, как раз вполне относительно, скрам предполагает подсовывание недоделанного функционала и постоянно его улучшение. Разве нет?

Ну вот Вы все говорите одно и тоже, если почитать то видно следующее «Мы по скраму тут не софт делаем, а зарабатываем деньги» все остальное либо проблемы заказчика, либо не проблемы скрама. Вы зачем вообще в профессию пришли? Чтобы писать нормальный софт или чтобы объяснять всем вокруг кто в чем виноват?

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

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

Ну ОК, т.е. Вы знаете как обойти все грабли фреймворка. Рад за Вас.

Ну если X больше либо равно 10 то еще как-то прокатит… если суметь показать на демо так, чтобы это было видно. И если раньше скорость была проблемой.

Если медтехника расширенная до стоматологов — однозначно да. Весьма зачетные там фрезы и абразивы.

Я готов поверить, что в некоторых случаях все устаканивается через разумное время.

Да просто обратил внимание, что в заголовке указано Scrum Framework, но по факту в заметке про что угодно, кроме скрама.

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

На мой вкус графит поинтереснее золота выглядит. Поздравляю с окончанием!

ОЦЕНКА ЗАДАЧ
В скрам гайде нет ни слова про оценку задач. Он про другое.

На самом деле конечно есть, возможно не декларативно, но косвенно. Sprint capacity например это именно про возможности команды взять N задач оцененных в попугаях.

ОЦЕНКА СРОКОВ
В скрам гайде нет ни слова про оценку сроков. Он про другое.

Дык я про это и написал-же. Он вообще про другое, он про процесс разработки а не про результат.

КАЧЕСТВО РЕЗУЛЬТАТА
1. Процитируйте точную фразу, с чем вы спорите. Продукт один и тот же, даже если инкрементов несколько.

Я ни с чем не спорю, а говорю как есть. Представьте продукт в момент Х содержащий N фичь. После пары итераций, в момент X+2 спринта команда утопила часть фичь и добавила часть новых. Превнеся и новые баги и новый функционал.
Так что продукт формально будет другим.
По поводу Архитектуры и Качества кода мы с Вами пишем примерно одно и то-же, но разными словами.
С Вашей версией решения тоже согласен.

Спасибо за аргументы, давайте по пунктам:

Вы видимо не совсем правильно понимаете скрам.

Я привел в начале выдержку из СкрамГайда, и перевод, понять его не правильно невозможно. Или я в переводе ошибся?

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

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

Мне чаще попадалась более странная ситуация, клиент и команда работают в одной лавке и почему-то это не спасает положение. Но это в Альфабанке было, сейчас все норм у нас скрам напоказ, а как только остаемся одни директор по разработке громко орет «а теперь waterfall» или «даешь pair programming» и все идут работать.

Согласен со всеми постулатами кроме первого, у Эджайла тоже есть своя библия «манифест» где буквально сразу говориться: «люди важнее процессов», в скраме наоборот, процесс важнее людей, можно потерять полкоманды, но это ОК если процесс улучшится а те люди мешали бежать спринты.
Меня просто удивляют люди которые отрицают ограниченность любой методологии включая скрам.