Когда команда впервые опробовала новые практики, она все еще не осознает, как они будут соотноситься с хорошо знакомыми ей методами. Понимание придет тогда, когда будет накоплен опыт работы с методологией. Такой способ работает, потому что Agile представляет собой комплексную систему, включающую успешно взаимодействующие практики, которую команды используют, чтобы стать продуктивнее. Внедрение полного набора практик поможет команде получить основу для изучения этих взаимодействий.
Но внедрение целой методологии – более сложный процесс, чем выбор практик, которые вписываются в текущий способ работы команды. Если команде удастся внедрить всю методологию сразу, то она будет иметь больше шансов получить максимальную отдачу от agile-усилий. Отчасти это связано с тем, что помимо уже знакомых методов каждый внедряет идеи, которые не представляются необходимыми в первую очередь.
Как вы помните, команда разработчиков музыкального автомата столкнулась с проблемами, потому что Брюс, Дэн, Джоанна и Том подошли к agile-практикам независимо друг от друга. Чтобы получить наибольшую отдачу от Agile, они должны были прежде всего обсудить каждый из этих методов с точки зрения их необходимости для проекта в целом и членов команды в частности. Но дело в том, что они не знают, как начать такое обсуждение. Как и многие команды, они сталкиваются с дилеммой: если они уже знают, как именно использовать agile-практики для проекта и как работать вместе, то незачем это обсуждать. Но поскольку они этого еще не знают, то проводить такого рода дискуссии на ранних стадиях трудно.
Решение проблемы – в 12 принципах, которые тесно связаны с ценностями Agile-манифеста. Вы узнаете о них в главе 3.
Команда, которая фокусируется только на отдельных практиках, может упустить из виду более глобальные цели, такие как улучшение коммуникации и реагирование на изменения.
Agile-методологии – это набор практик в сочетании с идеями, советами и опытом сообщества специалистов-практиков.
Такие agile-методологии, как Scrum, XP и Lean, включают в себя большой набор практик, но они также акцентируют внимание на идеях, которые помогают удерживать внимание команды на достижении этих целей.
Agile-коучи часто используют метафоры в качестве инструмента, чтобы помочь своим командам учиться.
Если в Agile-манифесте утверждается, что исчерпывающая документация не нужна, означает ли это, что мы не должны ничего документировать?
Это очень распространенный вопрос. Прочтите еще раз то, что написано в этом пункте манифеста:
Мы ценим ‹…› работающий программный продукт выше исчерпывающей документации.
Это не значит, что мы как практики agile-методологий не ценим исчерпывающую документацию. И мы, конечно, не думаем, что вы не должны писать никаких документов! Существует много полезной документации, которая не является исчерпывающей.
Это означает, что передача рабочего ПО в руки пользователей – это лучший способ узнать, насколько хорошо мы как команда добиваемся улучшений.
Но в наших проектах есть место и для записей. Мы будем документировать наш код, используя комментарии к коду (например, чтобы объяснить, почему мы приняли такое решение, или не пишем код другим способом, или используем иной алгоритм). Далее вы узнаете о документе под названием «пользовательская история». Он обычно написан на карточке и помогает вам, команде, пользователям и другим заинтересованным сторонам работать вместе, чтобы выяснить, что именно вы будете строить. Есть много других видов документации, в чем-то более подробных, чем те, которыми пользуются agile-команды.
Вы уверены? Я точно знаю, что Agile – это значит ничего не писать и не планировать, а сразу переходить к программированию. Разве это не эффективнее?
Один из самых распространенных мифов о гибкой разработке программного обеспечения заключается в том, что agile-команды ничего не планируют. Но на самом деле они проводят гораздо более тщательную работу по планированию, чем многие традиционные проектные команды. Однако разработчикам, пришедшим в Agile недавно, может показаться, что планирования практически нет, потому что в нем участвует вся команда – и никто не стонет (а ведь жалобы – это типичная реакция программистов в ответ на приглашение принять участие в планерке).