Каждая компания, специализирующаяся на разработке программного обеспечения, в определённый момент принимает во внимание важность наличия простого эффективного подхода к планированию и реализации проектов. Опробовав различные методы планирования, реализации и поддержки наших проектов в рамках Agile-подхода, мы остановили свой выбор на такой популярной гибкой структуре, как Скрам. Сегодня мы задействуем его в большинстве наших проектов, считая метод настолько мощным и полезным, что без него невозможно представить повседневную деятельность. При этом мы по-прежнему каждодневно находим возможности улучшений, с целью использовать данный метод ещё эффективнее.
Когда начинать?
В нашем случае всё пришло само собой. Было несколько причин, чтобы начать использовать Скрам. Кстати, его реализация – это своего рода непрерывная пошаговая работа.
Требования. Во-первых, в большинстве наших проектов в качестве входных данных мы получаем от заказчика только самые общие требования. При реализации наших проектов в соответствии с подходом Waterfall, нам всегда приходилось убеждать клиентов начинать со спецификации требований и архитектурного проектирования. Не подлежит сомнению, что определять требования имеет смысл как можно раньше. Но столь ли эффективен такой подход в большинстве случаев? Вовсе нет. Ведь при сборе различных требований к программному обеспечению требуются значительные усилия для опроса всех целевых пользователей и заинтересованных сторон. Даже если вам удастся создать сотни страниц документации с диаграммами участников, диаграммами последовательностей и обширными перечнями вариантов использования, то вам, скорее всего, впоследствии придётся её пересмотреть и, в конечном итоге, кардинально изменить на этапе реализации. Учитывая время и деньги, никто не стремится к большим тратам. Обычно стараются воплотить систему в соответствии только с теми требованиями, которые были собраны на предыдущем этапе проекта.
Обратная связь. Вне сомнения, на этапе реализации с использованием классического Waterfall у вас, конечно, тоже есть контрольные точки и промежуточные поставки. Но снова и снова наш опыт показывает, что в большинстве случаев представители заказчика зачастую довольствуются отчётами о проделанной работе, поскольку считают, что все идёт хорошо благодаря тщательно и заблаговременно проработанной спецификации требований к программному обеспечению. В результате рассмотрение продукта откладывается на другой день, ближе к завершению проекта. Запросы на изменения часто поступают в последнюю минуту, а на их реализацию не хватает времени и денег. Причина тому вовсе не в отсутствии навыков, нехватке персонала или мотивации. Вовсе нет! Все старались изо всех сил создать мощное современное программное обеспечение, но не уложились в срок именно из-за выбранного метода монолитной разработки Waterfall.
Как начать?
В настоящее время мы всё больше отдаём предпочтение методологии Agile и, в частности, Скраму. В прошлом, когда мы только начинали использовать Скрам, мы ещё не знали, как лучше всего двигаться дальше. Привлечение сторонних консультантов по Скраму на долгосрочной основе весьма затратно и, во многих случаях, не очень эффективно. Команде следует пройти этот путь самостоятельно, внедряя передовой опыт в повседневную работу. В итоге мы решили брать консультации время от времени, по мере надобности, задействуя в своих проектах избранные практики. Говоря о практике, мы поддерживаем участников нашей команды, кто наиболее заинтересован в Скраме, предоставляя профессиональные курсы с целью связать знания с нашей повседневной работой над проектами. То есть эти участники регулярно готовят и проводят внутренние тренинги по различным аспектам Скрама с практическими упражнениями и параллелями с нашими существующими проектами. Они также выступают в качестве профессиональных Скрам-мастеров, обучая всех игроков как на своей стороне, так и на стороне заказчика, как правильно и в полной мере использовать принципы данного метода разработки.
Опыт – личное дело каждого. Тем не менее, мы твёрдо верим, что учиться у других это естественно и очень эффективно. То есть мы будем рады поделиться опытом нашей компании GRSE в работе по Скраму. Материал будет представлен в нескольких публикациях, начиная с таких важных тем как формирование бэклога проекта и оценка усилий. Мы надеемся, что вам понравится, и метод найдёт практическое применение в вашей организации.
