Файл: Инфрам.pdf

112
Scrum фокусируется на определении приоритетных задач, основыва- ясь на бизнес целях, что увеличивает полезность и доходность проекта на его ранних стадиях. Так как при инициации проекта его доходность определить почти невозможно, Scrum предлагает концентрироваться на качестве разработки и к концу каждой итерации иметь промежуточный продукт, который можно использовать, даже пусть с минимальными возможностями. Например, результатом итерации может быть каркас сайта, который можно показать на презентации.
Методология Scrum ориентирована на то, чтобы оперативно приспо- сабливаться к изменениям в требованиях, что позволяет команде быстро адаптировать продукт к нуждам заказчика. Такая адаптация достигается за счет получения обратной связи по результатам итерации: имея после каждой итерации продукт, который уже можно использовать, показы- вать и обсуждать, легче собирать информацию и делать правильные корректировки и изменять приоритеты требований. Например, если каркас сайта показать потенциальным пользователям, то появится мно- го вопросов, на основании которых можно скорректировать то, что уже написано или еще не реализовано, понять что более важно пользовате- лю.
Девиз Scrum: анализируй то, что получил, адаптируй то, что есть, к реальной ситуации, а потом анализируй снова. Чем меньше форма- лизма, тем более гибко и эффективно можно работать – это основной принцип данной методологии. Но это не означает, что формальных про- цессов не должно быть совсем, их должно быть достаточно для органи- зации эффективного взаимодействия и управления проектом. Формаль- ная часть Scrum состоит из трех ролей, трех практик и трех основных документов.
К ролям относятся (лучше сказать роли выполняют): владелец про- дукта, Scrum-мастер и Scrum-команда.
Владелец продукта – человек, поставляющий требования програм- мистам. От того, как четко написаны требования, зависит, насколько часто команде придется переключаться с задачи на задачу в связи с отсутствием нужной информации, как много нужно задавать вопро- сов, на которые уходит дополнительное время, как сильно придется из- менять уже написанную функциональность от итерации к итерации и, соответственно, эффективность разработки в целом. Обычно владе- лец продукта является представителем или доверенным лицом заказчи- ка, а для компаний, выпускающих коробочные продукты, он представ- ляет рынок, на котором реализуется продукт.
Владелец продукта должен составить бизнес план, показывающий ожидаемую доходность и план развития с требованиями, отсортирован- ными по коэффициенту окупаемости инвестиций. Исходя из имеющейся информации, владелец продукта подготавливает список требований, отсортированный по значимости. Чем лучше владелец продукта описы- вает требования, управляет приоритетами и чем быстрее выдает инфор- мацию, тем больший финансовый эффект получит компания от методо- логии. В обязанности этого сотрудника входит своевременное предос-

113 тавление требований к продукту, определение дат и содержания рели- зов, эффективное управление приоритетами и корректировка требова- ний для достижения максимальной окупаемости инвестиций в продукт.
От человека, исполняющего роль Scrum-мастера, во многом зависит самостоятельность, инициативность программистов, удовлетворенность сделанной работой, атмосфера в команде и результат всей работы. Этот человек должен быть одним из членов команды разработки и участвовать в проекте как разработчик. Он отвечает за своевременное решение текущих проблем, от ремонта сломанного стула до обеспече- ния необходимой информацией членов команды для продолжения их работы и загруженности, за поддержание нужных технических практик, используемых на проекте. В обязанности Scrum-мастера входит обеспе- чение максимальной работоспособности и продуктивности команды, четкого взаимодействия между всеми участниками проекта, своевре- менное решение всех проблем, тормозящих или останавливающих ра- боту любого члена команды, ограждение команды от всех воздействий извне во время итерации и обеспечение следования процессу всех уча- стников проекта.
Scrum-команда – это группа, состоящая из пяти-девяти самостоя- тельных, инициативных программистов. Первая задача этой команды – поставить реально достижимую, прогнозируемую, интересную и значимую цель для итерации. Вторая задача – сделать все для того, чтобы эта цель была достигнута в отведенные сроки и с заявленным качеством. Цель итерации считается достигнутой только в том случае, если все поставленные задачи реализованы, весь код написан по опре- деленным проектом «стандартам кодирования», программа протестиро- вана полностью, а все найденные дефекты устранены.
Программисты этой команды должны уметь оценивать и планировать свою работу, работать в команде, постоянно анализиро- вать и улучшать качество взаимодействия и работы. В обязанности всех членов Scrum-команды входит участие в выборе цели итерации и определение результата работы. Они должны делать все возможное и невозможное для достижения цели итерации в рамках, определенных проектом, эффективно взаимодействовать со всеми участниками коман- ды, самостоятельно организовывать свою работу, предоставлять вла- дельцу рабочий продукт в конце каждого цикла.
В начале проекта владелец продукта готовит журнал продукта – список требований, отсортированный по значимости, а Scrum-команда дополняет этот журнал оценками стоимости реализации требований.
Список должен включать функциональные и технические требования, необходимые для реализации продукта. Самые приоритетные из них должны быть достаточно детально прописаны, чтобы их можно было оценить и протестировать. О своевременной детализации требований должен заботиться владелец продукта и предоставлять необходимый объем в нужное время. В этом смысле программисты являются заказчи- ками требований для владельца продукта. И отношение владельца про- дукта должно быть соответствующее – каковы требования, такова и их

114 реализация. В дальнейшем остальные требования должны постепенно уточняться и детализироваться до такого же уровня. Главное, чтобы у команды всегда был достаточный объем подготовленных к реализации требований.
После того как команда во время сессии планирования выбрала и обязалась реализовать набор требований из журнала продукта, эти требования разбиваются на более мелкие задачи, составляющие детали- зированный список требований – журнал спринта. Разбивка на задачи должна быть сделана таким образом, чтобы выполнение одной задачи занимало не больше двух дней.
Разбивка на задачи поможет так спланировать итерацию, чтобы в конце не осталось ни одной невыполненной задачи и, соответственно, достичь ее цели. После завершения детализации оценка журнала сприн- та сравнивается с первичной оценкой в журнале продукта. Если сущест- вует значительное расхождение, команда договаривается с владельцем продукта об объеме работ, который должен быть выполнен в течение итерации, и о том, какой объем будет перенесен на следующую. Менее важные и мало влияющие на цель итерации задачи выносятся из журна- ла спринта.
Подготовка к первой итерации, называемой спринт (Sprint), начина- ется после того, как владелец продукта разработал план проекта, опре- делил требования и отсортировал их в количестве, достаточном для на- полнения одной итерации. Такой список требований называется журна- лом продукта (Product Backlog). При планировании итерации происхо- дит детальная разработка сессий планирования спринта (Sprint Planning
Meeting), который начинается с того, что владелец продукта, Scrum- команда и Scrum-мастер проверяют план развития продукта, план рели- зов и список требований. Scrum-команда проверяет оценки требований, убеждается, что они достаточно точны, чтобы начать работать, решает, какой объем работы она может успешно выполнить за спринт, основы- ваясь на размере команды, доступном времени и производительности.
Важно, чтобы Scrum-команда выбирала первые по приоритету тре- бования из журнала продукта. После того как Scrum-команда обязуется реализовать выбранные требования, Scrum-мастер начинает планирова- ние спринта. Scrum-команда разбивает выбранные требования на зада- чи, необходимые для его реализации. Эта активность в идеале не долж- на занимать больше четырех часов, и ее результатом служит список требований, разбитый на задачи, – журнал спринта (Sprint Backlog). Не- обходимо, чтобы все участники команды приняли на себя обязательство по реализации выбранной цели.
После окончания планирования начинается итерация. Каждый день
Scrum-мастер проводит «скрам» (Daily Scrum Meeting) – пятнадцатими- нутное совещание, цель которого – достичь понимания того, что про- изошло со времени предыдущего совещания, скорректировать рабочий план к реалиям сегодняшнего дня и обозначить пути решения сущест- вующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущего скрама, что меня тормо-

115 зит или останавливает в работе, что я буду делать до следующего скра- ма? В этом совещании может принимать участие любое заинтересован- ное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реали- зовать цель итерации, и только это дает уверенность в том, что она бу- дет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников ко- манды.
В конце каждого спринта проводится демонстрационную презента- цию (Sprint Review Meeting), продолжительностью не более четырех часов. Сначала Scrum-команда демонстрирует владельцу продукта сде- ланную в течение спринта работу, а тот затем продолжает презентацию и может пригласить к участию всех заинтересованных заказчиков. Вла- делец продукта определяет, какие требования из журнала спринта были выполнены, и обсуждает с командой и заказчиками, как лучше расста- вить приоритеты в журнале продукта для следующей итерации.
Во второй части презентации производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда ищет использо- ванные в последнем спринте положительные и отрицательные способы совместной работы, анализирует их, делает выводы и принимает важ- ные для дальнейшей работы решения. Scrum-команда также определяет программы, которые могут работать лучше, и ищет пути для увеличения эффективности дальнейшей работы. Затем цикл замыкается, и начинается планирование следующего спринта (рис. 3.12).
График спринта (Burndown Chart) показывает ежедневное изменение общего объема работ, оставшегося до окончания итерации. Это график позволяет команде разработчиков делать анализ текущей ситуации и своевременно реагировать на отклонения. График спринта позволяет также владельцу продукта наблюдать за ходом итерации – если общий объем работ не уменьшается каждый день, значит, что-то идет не так.
Во время сессии планирования команда находит и оценивает задачи, которые надо выполнить для успешного завершения итерации.
Рис. 3.12. Структура спринта

116
Сумма оценок всех задач в журнале спринта является общим объе- мом работы, который надо выполнить за итерацию. После завершения каждой задачи Scrum-мастер пересчитывает объем оставшейся работы и отмечает это на графике спринта. Только в том случае, если объем работ по окончании итерации закончился (в журнале спринта не оста- лось незавершенных задач), итерация считается успешной. График спринта используется как вспомогательный инструмент, позволяющий корректировать работу для завершения итерации вовремя, с работающим кодом и требуемым качеством.
Время между итерациями – это время принятия основополагающих решений, влияющих на ход всего проекта. Во время итерации никакие изменения извне не могут быть сделаны. После того как команда дала обязательство реализовать журнал спринта, он фиксируется, и изменения в нем могут быть сделаны только по следующим причи- нам:
Scrum-команда в течение итерации получила лучшее представление о требованиях и нуждается в дополнительных задачах для успешно- го завершения итерации; найдены дефекты, которые нужно обязательно исправить для ус- пешного завершения итерации;
Scrum-мастер и Scrum-команда могут решить, что небольшие изме- нения, не влияющие на общий объем работ, могут быть реализованы в связи с возникшей у владельца продукта необходимостью.
Исходя из того что журнал спринта не может быть изменен извне во время итерации, нужно выбирать ее длину, основываясь на стабильно- сти требований. Если требования стабильны, меняются или дополняют- ся редко, то можно выбрать шестинедельный цикл. В этом случае эко- номится время на переключение команды с активной разработки на планирование и демонстрационные митинги. Если требования часто меняются и дополняются, нужно отталкиваться от двухнедельного цик- ла, в любом случае длина итерации — это величина экспериментальная.
1.7.8.
Agile-методологии
Гибкие методологии построены таким образом, что изменения приветствуются, а неопределенность признается. Существует несколько отличительных признаков всех гибких методологий [27]: разработка ведется короткими итерациями. Чем короче итерация, тем чаще можно демонстрировать продукт заказчику и изменять на- правление развития продукта. Заказчик сможет руководить разра- боткой продукта вместо того, чтобы, дождавшись окончания разра- ботки, понять, что получилось совсем не то, что он хотел; инкрементальная разработка. За каждую итерацию продукт дополня- ется новыми функциями, оставаясь при этом полностью функцио- нальным и готовым к передаче заказчику; самоорганизующаяся команда. Как показывает практика, только са- моорганизующиеся команды способны гибко реагировать на изме-

117 нения. Дело в том, что короткие итерации и часто меняющиеся тре- бования приводят к тому, что поддерживать документацию по про- екту в полном объеме технически невозможно. В этом случае коман- да тратила бы на работу с требованиями больше времени, чем на разработку кода. А раз документации мало, членам команды прихо- дится чаще общаться лицом к лицу, решая повседневные проектные задачи. Следовательно, команда должна быть самоорганизующейся, чтобы справиться с потоком проблем; адаптирующийся процесс. В традиционном подходе к разработке процесс определяется на уровне организации, а на уровне проекта происходит его подгонка. На практике, как правило, это означает, что менеджер проекта принимает решения, какие из стандартных регламентных требований организации неприменимы к проекту, и формулирует свое решение в соответствующем документе. В Agile- методологиях процесс определяется по ходу проекта самой проект- ной командой.
Одной из самых ранних работ, повлекших за собой появление со- временных методов итеративной разработки, является опубликованная в 1985 году статья «Спиральная модель разработки программного обес- печения» Б. Боэма.
В начале 90-х годов Джефф Сазерленд и Кен Швабер изобрели и на- чали использовать в компании Easel Corp. методологию, которую они назвали Scrum (см. предыдущий раздел). Метод был основан на подхо- де, который применялся в таких несофтверных компаниях, как Honda,
Canon и Fujitsu. Для Scrum характерны 30-дневные итерации, называе- мые спринтами, а также то, что повышенное внимание должно уделять- ся практикам по самоорганизации команд. Первая работа по Scrum была опубликована в 1999 году [27].
В середине 90-х годов компания Rational начала разработку методо- логии Rational Unified Process (унифицированный процесс Rational), в основу которой были положены итеративность и инкрементность разра- ботки (см. раздел 3.7.6). Процесс основан на применении прецедентов использования (Use Cases) и включает набор некоторых «лучших прак- тик» софтверной разработки на все случаи жизни.
В 1994-м группа людей, использовавших Rapid Application
Development, собралась, чтобы обсудить описание стандартного итера- тивного процесса. Через некоторое время это описание трансформиро- валось в методологию DSDM (Dynamic Systems Development Method), которая в наши дни особенно популярна на ее родине, в Великобрита- нии.
В 1996 году к проекту Chrysler C3, который к тому времени уже был практически провален, присоединился Кент Бек. Он вместе с Роном
Джеффрисом использовал все известные ему на тот момент практики и пришел к выводу, что их совместное применение намного превышает эффект, получаемый от каждой по отдельности. Методология, назван- ная Extreme Programming (XP – экстремальное программирование), бы- стро получила широкую известность благодаря ориентации на простоту,