Скрамуниздили

[verych]

На своем опыте прочувствовал, что скрам порождает, как следствие, анти-паттерн «Аналитики-паралитики».
Все начинают много говорить… как те цыгане на базаре.

«Не люблю, б@я, цыган!»
«Большой куш»

[locutus]

Давно заметил, что

«эволюционный дизайн, обзоры кода, разработка через тестирование, рефакторинг, непрерывная интеграция, шаблоны проектирования, парное программирование и прочие многочисленные технические методики»

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

[dm_wrike]

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

Конечно вы правы, Scrum это решение не только для разработки и он не содержит конкретных технических
рекомендаций, в отличии от XP. Scrum позволяет выявить проблемы, но найти решение — ответственность команды.
Будь то ревью кода, непрерывная интеграция или что то еще.

В целом вы делаете акцент на оптимизации разработки как таковой, это безусловно важно, но не достаточно.

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

Scrum предназначен не только для того что бы научиться «копать быстро»,
но и для того что бы понять «в каком направлении копать».

И второе в целом важнее первого, хоть и не отрицает его значимости.

[Cromathaar]

Сложно поспорить с тем, что это ответственность команды, ведь кроме команды в Скраме как бы третьих лиц нет :) Или вы имеете ввиду только девелоперскую команду в отрыве от скрам-мастера и продакт оунера?

Про успех, опять же, нельзя не согласиться, но успех — понятие относительное. Кент Бек выделяет четыре составляющие разработки: бюджет, время, качество и объем работ. Теоретически, завалив любую из них, команда заваливает и проект. Но на практике все гораздо сложнее и очень сильно зависит от уровня взаимоотношений с бизнесом. Собственно, превращение процесса разработки в игру с ненулевой суммой — это, на мой взгляд, один из главных посылов гибких методологий.

Ну и, если несложно, поясните свою метафору про направление раскопок, а то пока не очень понятно.

[dm_wrike]

«Копать быстро» — это motorola, выпустившая в 2007 примерно 10 моделей телефонов.

«Копать в правильную сторону» — это Apple, выпустившая в том же году iPhone.

[Cromathaar]

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

[nicholas_k]

Scrum сам по себе вообще не о качестве кода и решении технических проблем.
Scrum обращает внимание на технические проблемы тогда, когда они становятся проблемой бизнеса. Например когда добавление новых фич занимает слишком много времени, когда количество багов чрезмерно отталкивает пользователя и т.д.

Scrum — это средство погрузить разработчика в бизнес, а бизнес в разработку.

[Shamov]

Когда я впервые увидел презентацию по Скраму, наиболее интересным мне показался заключительный раздел. Там речь шла о некоторых модификациях Скрама, которые обобщённо назывались ScrumBut:

• Скрам, но без ежедневных митингов;
• Скрам, но без ретроспектив;
• Скрам, но со спринтом, удлинённым до шести недель.

Я тогда сразу подумал, что вот она, идеальная методология — СкрамБат. Ну, точнее, почти идеальная. Полностью идеальной она была бы в том случае, если бы спринт вообще не имел никакой фиксированной длины.

А по существу я со статьёй полностью согласен. Если применять Скрам не как метод управления разработкой, а как метод мониторинга, то будет гораздо лучше. В том смысле, что вреда от него будет меньше.