С одной стороны- agile подходит не всем. С другой- без процесса нальзя. Т.е. должны быть процессы, которые лучше agile'овских и применимые для банка, к примеру. Вот мне и нетренесно- какие? Водопаду место в музее, RUP вроде слишком ужасен, что ещё?
PS: разрабатывал для банка по смеси scrum'а и cunban'а, кстати. Вроде все группы использовали только agile, хотя не до конца уверен.
Да, продлевали этап. Только багиприлетали ещё из продакшна, и чинились они, естественно, "вчера", в отдельной ветке (ага, это ж год назад выпустили). Классический водопад быстро срубили (сначала были даже отдельные проектировщики, которые код не писали, а только думали архитектуру), но на полный agile так и не перешли. А оотдельный ответственнй (зиц-председатель) это забавно, но что толку-то?
Я видел и водопад и "вчера". Это разные вещи. Но кроме agile, водопада и "вчера" я больше реально процессов разработки не видел. Даже когда писал софт для встроенных систем для меня это был agile - просто заказчиком выступал создатель железа, а заливал я на стенд иногда по 20 раз в день.
Вот и интересно- а чтоесть _лучше agile? Водопад и "вчера" точно хуже.
Это прекрасно работает для RTB-рекламных серверов с DMP и прочей доставкой контента. Пока только инфраструктура напрягает- то фрагмент сети отвалится у провайдера, то диск улетит в мир иной. Отдела тестирования в той команде нет вообще. Только автотесты. На UI да, бывают баги, но деньги платят не за это.
Про то, что agile имеет ограниченное примерение Асхат, например, говорит минимум с 2008 года (точне я от него это слышал тогда). Причём разные технологии подходят для разных целей. Никто для встроенных систем его не предлагает. Плюс agile даже из названя следует- надо применять вдумчиво, меняя под себя.
Самое же ценное в этой статьи- упоминание того факта, что agile терубет высококвалифицированных работников. Да, это факт- если нанимаете г..кодеров- то не ходите в скрам.
С другой стороны- альтернативай скраму/канбану чаще является бардак и подход "а!!!!! вчера надо сделать, багов дофига, а то, что вы уже отдали заказчику- нифига не то, что надо".
Вообще интересно послушать про поставленные не-agile процессы. Водопад видел, но это вообще трындец- сроки срываются, абгов дофигища, зарезультат не отвечает вообще никто (я только кодил, а что всёразвалилось- не я виноват).
Ещё раз повторю вопрос- а какая альтернатива?
Водопад? RUP? Без процесса?
С одной стороны- agile подходит не всем.
С другой- без процесса нальзя.
Т.е. должны быть процессы, которые лучше agile'овских и применимые для банка, к примеру. Вот мне и нетренесно- какие?
Водопаду место в музее, RUP вроде слишком ужасен, что ещё?
PS: разрабатывал для банка по смеси scrum'а и cunban'а, кстати. Вроде все группы использовали только agile, хотя не до конца уверен.
Да, продлевали этап. Только багиприлетали ещё из продакшна, и чинились они, естественно, "вчера", в отдельной ветке (ага, это ж год назад выпустили).
Классический водопад быстро срубили (сначала были даже отдельные проектировщики, которые код не писали, а только думали архитектуру), но на полный agile так и не перешли.
А оотдельный ответственнй (зиц-председатель) это забавно, но что толку-то?
Я видел и водопад и "вчера". Это разные вещи.
Но кроме agile, водопада и "вчера" я больше реально процессов разработки не видел.
Даже когда писал софт для встроенных систем для меня это был agile - просто заказчиком выступал создатель железа, а заливал я на стенд иногда по 20 раз в день.
Вот и интересно- а чтоесть _лучше agile? Водопад и "вчера" точно хуже.
Это прекрасно работает для RTB-рекламных серверов с DMP и прочей доставкой контента.
Пока только инфраструктура напрягает- то фрагмент сети отвалится у провайдера, то диск улетит в мир иной.
Отдела тестирования в той команде нет вообще. Только автотесты. На UI да, бывают баги, но деньги платят не за это.
Про то, что agile имеет ограниченное примерение Асхат, например, говорит минимум с 2008 года (точне я от него это слышал тогда). Причём разные технологии подходят для разных целей. Никто для встроенных систем его не предлагает. Плюс agile даже из названя следует- надо применять вдумчиво, меняя под себя.
Самое же ценное в этой статьи- упоминание того факта, что agile терубет высококвалифицированных работников. Да, это факт- если нанимаете г..кодеров- то не ходите в скрам.
С другой стороны- альтернативай скраму/канбану чаще является бардак и подход "а!!!!! вчера надо сделать, багов дофига, а то, что вы уже отдали заказчику- нифига не то, что надо".
Вообще интересно послушать про поставленные не-agile процессы. Водопад видел, но это вообще трындец- сроки срываются, абгов дофигища, зарезультат не отвечает вообще никто (я только кодил, а что всёразвалилось- не я виноват).