Меня никогда не удивляло, что схватка имеет немного противоречивую репутацию. В то время как некоторые хвалят за эффективный и простой подход к разработке программного обеспечения, есть профессиональные разработчики программного обеспечения, которые ставят свою репутацию, утверждая, что такие подходы, как scrum, в лучшем случае бессмысленны , а в худшем случае наносят ущерб эффективной работе по разработке программного обеспечения.
Скрам, возможно, спровоцировал такие жаркие дебаты не из-за чего-то присущего самой схватке, а скорее из-за неправильных представлений и неправильного применения терминологии и технологий, которые выросли вокруг схватки. И если ваша команда работает над веб-проектами и проектами по разработке мобильных приложений, scrum может быть лучшим решением для управления вашими проектами.
Так что такое Scrum?
Scrum — это один из семейства подходов к организации программных проектов, которые подпадают под гибкий подход. Другие гибкие методы включают канбан и экстремальное программирование. Все эти подходы основаны на нескольких общих принципах о том, как люди должны работать вместе при разработке программного обеспечения и как оптимизировать этот процесс, таких как:
- Восхищение клиента
- Поставка рабочего программного обеспечения часто
- Деловые люди и разработчики работают вместе
- Измерение реальных результатов на основе выполненной работы
- Разрешение командам самоорганизоваться
- Регулярно размышляя о том, что работает, а что нет
В частности, Scrum оптимизирован для групп, работающих над проектами, которые можно разбить на полные фрагменты функциональности, которые можно доставить в течение фиксированного и регулярного периода времени, обычно равного одной или двум устойчивым рабочим неделям, известным как спринты в Scrum. Скрам использует термин «истории» для описания этих частей функциональности и стремится улучшить способность команды оценивать, сколько усилий потребуется для завершения истории.
В отличие от традиционных подходов к разработке программного обеспечения, которые часто сводятся воедино под ярлыком « водопад» , scrum не включает в себя длинные и подробные документы с требованиями, полные спецификаций, разработанных менеджерами продукта, которые должны быть изложены до того, как команда сможет начать работу.
Scrum достаточно гибок, чтобы позволить команде начать, основываясь на достаточном количестве историй, чтобы они были заняты в течение нескольких недель. В то время, если появятся новые отзывы пользователей, изменения на рынке, новая информация поступит извне или внутри компании, или технология, лежащая в основе изменения продукта, можно будет представить и проработать новые истории в течение следующих нескольких недель.
Scrum также поддерживает регулярное общение лицом к лицу по подробным спецификациям. Обычно этому помогает то, что каждый член команды ежедневно встает в группу и сообщает о том, что он сделал в предыдущий день, что он планирует сделать в этот день, и есть ли у него какие-либо блокировщики. Scrum также рекомендует другие регулярные личные встречи, называемые ритуалами, для планирования, демонстрации и проведения ретроспективы каждого спринта.
В то время как перспектива ежедневной встречи может показаться неприятной для многих разработчиков, важно помнить, что все эти тонко настроенные ритуалы схватки проводятся под руководством мастера схватки, с фиксированными сроками и четкими повестками дня. Например, ежедневный прием никогда не должен занимать более 15 минут.
Роли, такие как мастер схватки и владелец продукта, также определены в схватке. И вы, возможно, заметили, что словарь схватки звучит немного странно для профессиональной технической среды. Это своего рода точка. Scrum определяет роли, ритуалы и артефакты таким образом, что их нельзя легко спутать с другими подходами.
Почему Scrum является спорным?
Обещание схватки заманчиво. Команды принимают разборки, потому что эксперты говорят, что это улучшит способность команды оценивать объем работы, которую они могут выполнять, обеспечит гибкость при изменении требований рынка, улучшит прозрачность процесса и создаст среду, в которой всем предлагается учиться большему и постоянно совершенствоваться, одновременно приложить устойчивое количество усилий. Как с этим можно спорить?
Ну, легко спорить с тем, что звучит слишком хорошо, чтобы быть правдой. И на самом деле, чем больше обещаний по поводу разборки, тем сложнее их выполнять. Но я думаю, что разборки и гибкие процессы в целом пострадали от фундаментального недопонимания того, где они вписываются в организацию и как они отличаются от иерархии бизнеса.
Scrum предоставляет способ наилучшим образом использовать имеющиеся у вас ресурсы, оставаясь адаптируемым к постоянно меняющемуся рынку. Это не волшебная формула, которую вы можете излить на свою команду и вдруг получить результаты, о которых вы всегда мечтали. Во всяком случае, схватка разоблачит такие проблемы, как технический долг, нехватка ресурсов или быстрое накопление информации, вынеся их на поверхность, вместо того, чтобы позволить им прятаться за должностями и самоограничивающимися традициями. И, как следствие, в первую очередь за эти проблемы могут быть обвинены схватки.
Но я не хочу показаться здесь бойким. Я полагаю, что одной из причин, по которой Scrum обвиняют в проблемах на рабочем месте, может быть искушение сделать вид, что вы используете Scrum, когда все, что вы на самом деле делаете, — это использование терминологии или инструментов. Как и в любом культурном учреждении, ритуалы и словарь схваток могут быть неправильно применены или даже злоупотреблены, если каждый не желает изучать реальные намерения и защищать первоначальные намерения, стоящие за практикой.
Короче говоря, если Scrum не работает для вас, вернитесь к определениям и убедитесь, что то, что вы делаете, на самом деле Scrum. Если вы выбираете scrum, потому что вы думаете, что что-то не так с людьми в вашей команде, у вас недостаточно финансируемая организация или вы думаете, что у вас могут быть проблемы с соответствием рынку продуктов, вам может потребоваться решить более фундаментальные проблемы, прежде чем вы сможете понять Преимущества схватки.
Почему Scrum для веб и мобильной разработки?
Скрам появился в 1980-х годах и начал серьезно восприниматься в 1990-х годах. Это примерно в то же время, когда разработка программного обеспечения начала отходить от монолитных термоусадочных приложений, выпускаемых на ежегодной основе, к более мелким, более целенаправленным приложениям, постоянно предоставляемым с помощью веб-технологий и мобильных технологий. Я не думаю, что это случайность.
Когда срок поставки может составлять год или более, может иметь смысл более традиционный шаблон, включающий подробные спецификации, заранее определенные и работающие в течение многих месяцев. Но веб и мобильные технологии меняются очень часто. Ожидания пользователей могут отличаться от недели к следующей, поскольку на рынок выходят новые браузеры, обновленные мобильные операционные системы и неожиданные конкуренты.
Акцент Scrums на гибкости, прозрачности, устойчивости, рефлексии и способности оценивать ресурсы полностью соответствует ожиданиям, что компании с продуктами в Интернете и мобильном пространстве могут выжить, только если они, конечно, гибки.
Делать ход Scrum
В то время как основы схватки просты, реализация схватки эффективно требует обучения, практики и готовности. Это одна из причин, по которой я написал Scrum: новичок ниндзя . Цель этой книги состоит в том, чтобы помочь познакомить Scrum с людьми, работающими в области веб- и мобильных разработок, которые могут быть не знакомы с Scrum, и предложить командам, испытывающим затруднения при внедрении Scrum, возможность подумать о том, как они применяют эти методы. Я надеюсь, что вы проверите это, и дайте мне знать, что вы думаете.