Comments 8
На своем опыте прочувствовал, что скрам порождает, как следствие, анти-паттерн «Аналитики-паралитики».
Все начинают много говорить… как те цыгане на базаре.
«Не люблю, б@я, цыган!»
«Большой куш»
Все начинают много говорить… как те цыгане на базаре.
«Не люблю, б@я, цыган!»
«Большой куш»
Давно заметил, что
«эволюционный дизайн, обзоры кода, разработка через тестирование, рефакторинг, непрерывная интеграция, шаблоны проектирования, парное программирование и прочие многочисленные технические методики»
должны быть при любой применяемой методологии разработки, и дело вовсе не в Agile.
«эволюционный дизайн, обзоры кода, разработка через тестирование, рефакторинг, непрерывная интеграция, шаблоны проектирования, парное программирование и прочие многочисленные технические методики»
должны быть при любой применяемой методологии разработки, и дело вовсе не в Agile.
Скрам же, являясь фреймворком, предоставляет организационный инструмент, позволяющий, подобно лакмусовой бумаге, максимально быстро выявлять проблемы в этих двух областях и оперативно на них реагировать.
Конечно вы правы, Scrum это решение не только для разработки и он не содержит конкретных технических
рекомендаций, в отличии от XP. Scrum позволяет выявить проблемы, но найти решение — ответственность команды.
Будь то ревью кода, непрерывная интеграция или что то еще.
В целом вы делаете акцент на оптимизации разработки как таковой, это безусловно важно, но не достаточно.
Плохая разработка может провалить любой продукт, но и хорошая разработка не гарантирует успех.
Scrum предназначен не только для того что бы научиться «копать быстро»,
но и для того что бы понять «в каком направлении копать».
И второе в целом важнее первого, хоть и не отрицает его значимости.
Сложно поспорить с тем, что это ответственность команды, ведь кроме команды в Скраме как бы третьих лиц нет :) Или вы имеете ввиду только девелоперскую команду в отрыве от скрам-мастера и продакт оунера?
Про успех, опять же, нельзя не согласиться, но успех — понятие относительное. Кент Бек выделяет четыре составляющие разработки: бюджет, время, качество и объем работ. Теоретически, завалив любую из них, команда заваливает и проект. Но на практике все гораздо сложнее и очень сильно зависит от уровня взаимоотношений с бизнесом. Собственно, превращение процесса разработки в игру с ненулевой суммой — это, на мой взгляд, один из главных посылов гибких методологий.
Ну и, если несложно, поясните свою метафору про направление раскопок, а то пока не очень понятно.
Про успех, опять же, нельзя не согласиться, но успех — понятие относительное. Кент Бек выделяет четыре составляющие разработки: бюджет, время, качество и объем работ. Теоретически, завалив любую из них, команда заваливает и проект. Но на практике все гораздо сложнее и очень сильно зависит от уровня взаимоотношений с бизнесом. Собственно, превращение процесса разработки в игру с ненулевой суммой — это, на мой взгляд, один из главных посылов гибких методологий.
Ну и, если несложно, поясните свою метафору про направление раскопок, а то пока не очень понятно.
«Копать быстро» — это motorola, выпустившая в 2007 примерно 10 моделей телефонов.
«Копать в правильную сторону» — это Apple, выпустившая в том же году iPhone.
«Копать в правильную сторону» — это Apple, выпустившая в том же году iPhone.
Scrum сам по себе вообще не о качестве кода и решении технических проблем.
Scrum обращает внимание на технические проблемы тогда, когда они становятся проблемой бизнеса. Например когда добавление новых фич занимает слишком много времени, когда количество багов чрезмерно отталкивает пользователя и т.д.
Scrum — это средство погрузить разработчика в бизнес, а бизнес в разработку.
Scrum обращает внимание на технические проблемы тогда, когда они становятся проблемой бизнеса. Например когда добавление новых фич занимает слишком много времени, когда количество багов чрезмерно отталкивает пользователя и т.д.
Scrum — это средство погрузить разработчика в бизнес, а бизнес в разработку.
Когда я впервые увидел презентацию по Скраму, наиболее интересным мне показался заключительный раздел. Там речь шла о некоторых модификациях Скрама, которые обобщённо назывались ScrumBut:
- Скрам, но без ежедневных митингов;
- Скрам, но без ретроспектив;
- Скрам, но со спринтом, удлинённым до шести недель.
Я тогда сразу подумал, что вот она, идеальная методология — СкрамБат. Ну, точнее, почти идеальная. Полностью идеальной она была бы в том случае, если бы спринт вообще не имел никакой фиксированной длины.
А по существу я со статьёй полностью согласен. Если применять Скрам не как метод управления разработкой, а как метод мониторинга, то будет гораздо лучше. В том смысле, что вреда от него будет меньше.
Sign up to leave a comment.
Скрамуниздили