У вас, похоже, опыт в разработке ограничен пользовательскими приложениями
Скорее наоборот, мой опыт ничем не ограничен, от участия в разработке Java до каких нибудь процессов на Pega PRPC, включая как ни странно и низкоуровневую ботву временами.
Та-же история, только лет побольше. И примеры к сожалению есть.
1. Разработка внутреннего инструмента для компании разрабатывающей процессинговый софт, работал там два раза, во второй был скрам: ПМ, команда только из меня одного — кончилось быстро и плохо, свалил оттуда.
2. Крупная банка — разработка бизнесс процессов на Pega PRPC, половину команды фактически уволили по решению самой команды. Обучил сменщика и свалил.
3. Мелкий стартап, куча безумных людей со стеклянными глазами делающими вид, что они работают по скраму, ушел на испытательном сроке.
Вчера друг уволился из лавки, проработав 1 месяц, послал в задницу скраммастера приглашенного в лавку для выстраивания процессов, поговорил с СТО и уволился текущим днем, пользуясь тем, что еще испытательный срок.
Было и пару положительных опытов, например сейчас, когда мы пилим софт, в котором есть работающий код 1998 года, правда скрам у нас очень относительный.
Антон, Вы пытаетесь мыслить логически, но в частном случае, когда скрам работает. Я-же писал, что его используют везде, где можно и нельзя, надо и не надо. И упорно продолжают жрать кактус в надежде на светлое будущее.
Скрам это не то что написано в СкрамГАйде, а то что из него делают отмороженные люди со стеклянными глазами. Никогда не работали в таких компаниях? Я работал к сожалению, хорошо, что есть испытательный срок, когда можно просто сказать «до свидания нам не по пути».
На самом деле было интересно пообщаться с разумными людьми (в этой теме), которые могут аргументировать свою точку зрения на разработку, почему-то в жизни мне попадается другой вариант.
Ну вот Вы все говорите одно и тоже, если почитать то видно следующее «Мы по скраму тут не софт делаем, а зарабатываем деньги» все остальное либо проблемы заказчика, либо не проблемы скрама. Вы зачем вообще в профессию пришли? Чтобы писать нормальный софт или чтобы объяснять всем вокруг кто в чем виноват?
Ну тоже подход, вместо реальной пользы убедить пользователя что он пользу получил таки. Обычно правда, я например, стараюсь убедить, что пользователь хочет не того о чем говорит, а совсем другого.
Да просто обратил внимание, что в заголовке указано Scrum Framework, но по факту в заметке про что угодно, кроме скрама.
Да нет, в заметке как раз именно про то, во что имплементирует ScrumFramework большинство команд. По незнанию ли, по злому умыслу, но народ массово сваливается во все эти игры, и фреймворк повинен тут в том, что описывает удобный и легкий путь сделать это.
ОЦЕНКА ЗАДАЧ
В скрам гайде нет ни слова про оценку задач. Он про другое.
На самом деле конечно есть, возможно не декларативно, но косвенно. Sprint capacity например это именно про возможности команды взять N задач оцененных в попугаях.
ОЦЕНКА СРОКОВ
В скрам гайде нет ни слова про оценку сроков. Он про другое.
Дык я про это и написал-же. Он вообще про другое, он про процесс разработки а не про результат.
КАЧЕСТВО РЕЗУЛЬТАТА
1. Процитируйте точную фразу, с чем вы спорите. Продукт один и тот же, даже если инкрементов несколько.
Я ни с чем не спорю, а говорю как есть. Представьте продукт в момент Х содержащий N фичь. После пары итераций, в момент X+2 спринта команда утопила часть фичь и добавила часть новых. Превнеся и новые баги и новый функционал.
Так что продукт формально будет другим.
По поводу Архитектуры и Качества кода мы с Вами пишем примерно одно и то-же, но разными словами.
С Вашей версией решения тоже согласен.
Я привел в начале выдержку из СкрамГайда, и перевод, понять его не правильно невозможно. Или я в переводе ошибся?
По срокам даже смешно, как раз скрам позволяет их соблюдать, более того, вы можете навесить командный kpi на факт закрытия спринтов, типо спринт закрыли — получили определенный процентик премии.
Основываясь на определении, как раз таки нет, не позволяет, скорее это способ растянуть проект.
А по поводу командного kpi, даже слов нет, но попробую покорректнее: во первых это и есть то самое уравнивание всех, а во вторых умная команда всегда будет строить спринт так чтобы получить премию. Всегда. Исключений нет. Делать при этом может даже меньше, но премию получит.
Ну и судя по всему, работаете Вы не по скраму, а по некому процессу который Вам подходит — ну и норм, можно только поаплодировать.
Мне чаще попадалась более странная ситуация, клиент и команда работают в одной лавке и почему-то это не спасает положение. Но это в Альфабанке было, сейчас все норм у нас скрам напоказ, а как только остаемся одни директор по разработке громко орет «а теперь waterfall» или «даешь pair programming» и все идут работать.
Согласен со всеми постулатами кроме первого, у Эджайла тоже есть своя библия «манифест» где буквально сразу говориться: «люди важнее процессов», в скраме наоборот, процесс важнее людей, можно потерять полкоманды, но это ОК если процесс улучшится а те люди мешали бежать спринты.
Меня просто удивляют люди которые отрицают ограниченность любой методологии включая скрам.
Скорее наоборот, мой опыт ничем не ограничен, от участия в разработке Java до каких нибудь процессов на Pega PRPC, включая как ни странно и низкоуровневую ботву временами.
1. Разработка внутреннего инструмента для компании разрабатывающей процессинговый софт, работал там два раза, во второй был скрам: ПМ, команда только из меня одного — кончилось быстро и плохо, свалил оттуда.
2. Крупная банка — разработка бизнесс процессов на Pega PRPC, половину команды фактически уволили по решению самой команды. Обучил сменщика и свалил.
3. Мелкий стартап, куча безумных людей со стеклянными глазами делающими вид, что они работают по скраму, ушел на испытательном сроке.
Вчера друг уволился из лавки, проработав 1 месяц, послал в задницу скраммастера приглашенного в лавку для выстраивания процессов, поговорил с СТО и уволился текущим днем, пользуясь тем, что еще испытательный срок.
Было и пару положительных опытов, например сейчас, когда мы пилим софт, в котором есть работающий код 1998 года, правда скрам у нас очень относительный.
Скрам это не то что написано в СкрамГАйде, а то что из него делают отмороженные люди со стеклянными глазами. Никогда не работали в таких компаниях? Я работал к сожалению, хорошо, что есть испытательный срок, когда можно просто сказать «до свидания нам не по пути».
На самом деле было интересно пообщаться с разумными людьми (в этой теме), которые могут аргументировать свою точку зрения на разработку, почему-то в жизни мне попадается другой вариант.
Да нет, в заметке как раз именно про то, во что имплементирует ScrumFramework большинство команд. По незнанию ли, по злому умыслу, но народ массово сваливается во все эти игры, и фреймворк повинен тут в том, что описывает удобный и легкий путь сделать это.
На самом деле конечно есть, возможно не декларативно, но косвенно. Sprint capacity например это именно про возможности команды взять N задач оцененных в попугаях.
Дык я про это и написал-же. Он вообще про другое, он про процесс разработки а не про результат.
Я ни с чем не спорю, а говорю как есть. Представьте продукт в момент Х содержащий N фичь. После пары итераций, в момент X+2 спринта команда утопила часть фичь и добавила часть новых. Превнеся и новые баги и новый функционал.
Так что продукт формально будет другим.
По поводу Архитектуры и Качества кода мы с Вами пишем примерно одно и то-же, но разными словами.
С Вашей версией решения тоже согласен.
Я привел в начале выдержку из СкрамГайда, и перевод, понять его не правильно невозможно. Или я в переводе ошибся?
Основываясь на определении, как раз таки нет, не позволяет, скорее это способ растянуть проект.
А по поводу командного kpi, даже слов нет, но попробую покорректнее: во первых это и есть то самое уравнивание всех, а во вторых умная команда всегда будет строить спринт так чтобы получить премию. Всегда. Исключений нет. Делать при этом может даже меньше, но премию получит.
Ну и судя по всему, работаете Вы не по скраму, а по некому процессу который Вам подходит — ну и норм, можно только поаплодировать.
Меня просто удивляют люди которые отрицают ограниченность любой методологии включая скрам.