Здравствуйте, Sharov, Вы писали:

S>>Это в официальном руководстве по SCRUM написано. Звиздун-собеседник, конечно же, мастерски может послать все это вдоль и наговорить массу умных слов в свое оправдание. Только вот вряд ли получившийся процесс с одним митингом раз в спринт будет считаться SCRUM-ом.

S>К этому можно относится как к какому-нибудь фреймворку и адаптировать для команды. Т.е. все брать
S>не обязательно. Если пуристы будут говорить, что это не настоящий скрам, то их можно посылать нафиг,
S>т.к. для комнды и для ее задач это работает. Т.е. тут необходимое vs достаточное.

Я несколько лет назад потратил время на то, чтобы разобраться с тем, что дает Agile подход, когда он выгоден, когда нет. И в процессе погружения в предмет выяснилась такая штука: Agile методы (вроде того же SCRUM) они про гибкость адаптации к требованиям и хотелкам заказчика, но сами по себе "патентованные" методы (вроде того же SCRUM) -- это жесткие и формализованные процессы. Вплоть до того, что стоит из SCRUM выкинуть что-то, что ты считаешь ненужным, как у тебя уже [формально] не SCRUM.

Мотивацию этого подхода тоже можно понять: вот выбросил я, например, Daily Scrum, утратил один из инструментов контроля за происходящим, проект завершился неудачно. Почему бы мне не начать говорить, что SCRUM сработал плохо? А нельзя, т.к. у меня был не SCRUM, и это правда.

Ну а так-то да, под команду можно настроить процесс, понадергав полезного из разных подходов (SCRUM, Kanban, Crystal и пр.). Главное, чтобы работало. Вопрос в том, можно ли к сформированному процессу конкретный ярлык прилепить (по аналогии с тем, что не всякое вино в определенных юрисдикциях может "Шампанским" называться).