Шпаргалка по Scrum-Agile framework для разработки программного обеспечения. Подходит ли вам этот метод?
На прошлой неделе в DigitalCrafts мы имели удовольствие встретиться с Рафаэлем де ла Торре, старшим инженером-программистом в Odyssey Space Research и адъюнкт-профессором математики и физики в Хьюстонском университете Клир-Лейк. Рафаэль также является скрам-мастером в Odyssey и познакомил нас с концепцией разработки программного обеспечения Scrum-Agile.
Если вы еще не знакомы с ним, Agile — это набор принципов, созданных для лучшей разработки программного обеспечения. Ознакомьтесь с их манифестом.
Scrum является ответвлением Agile и создает структуру, которая включает ценности манифеста Agile в руководящие принципы управления проектами и создания программного обеспечения.
Сначала я был настроен скептически. Кого волнует, что кто-то другой думает, что мы должны разрабатывать программное обеспечение? Пока мы каким-то образом доходим до завершения проекта, разве этого не должно быть достаточно? Но опять же, у меня еще не было опыта создания ПО в составе большой команды. И есть загвоздка. Когда Рафаэль представил нам методологию Scrum-Agile, я понял, что преимущество заключается не в самоуправлении, а в управлении командой.
Структура Scrum-Agile позволяет командам развивать:
Подотчетность
Коммуникация
Компетенция
Пунктуальность
Работать в команде непросто. Это требует от вас уверенности в том, что ваши товарищи по команде выполнят свою справедливую долю работы, а если они не смогут этого сделать, они открыто сообщат об этом всем остальным в команде. Любой, кто когда-либо работал в команде, скорее всего, знает, что это не всегда так. Бывают моменты, когда кто-то расслабляется, и все остальные должны компенсировать это. Так как же Scrum это меняет?
Метод Scrum требует проведения ежедневных собраний Scrum, на которых каждый член команды рассказывает, что он сделал накануне, что планирует сделать сегодня и есть ли что-то, что мешает ему выполнить поставленную задачу.
Эти встречи являются обязательными и обычно носят краткий характер. Делая эти встречи обязательным требованием, товарищи по команде должны иметь открытые каналы связи и создают между ними ответственность. Знание того, что вам придется объяснять для себя, если вы не добьетесь прогресса в своей задаче, создает мотивацию не расслабляться. Это также создает стимул обратиться за помощью в задаче, на которой вы можете застрять раньше, чем позже. При работе в команде следует отказаться от гордости, поскольку у всей команды одна цель: завершение проекта.
Вам может быть интересно, а КАЖДОМУ члену команды дается всего 15 минут на участие в обсуждении? Как?! Ну… обычно в scrum-команде всего 4–8 человек. Обычно несколько scrum-команд работают над разными частями проекта. Эта схваточная команда склеивается для того, что называется спринтами. Спринт – это показатель разработки по методологии Scrum-Agile, который обычно длится 2–4 недели. Целью этих спринтов является проектирование, кодирование и тестирование определенной части программного обеспечения, которое они создают. Именно это позволяет Scrum-Agile создавать грамотное программное обеспечение. Вместо того, чтобы проектировать, создавать и тестировать всю систему одновременно, Scrum стремится создавать фрагменты программного обеспечения за раз с помощью спринтов.
Каждый спринт требует планирования спринта в самом начале спринта, когда для этого конкретного спринта создается список невыполненных задач. Этот список обычно перекрывается с большим объемом невыполненных задач, необходимых для выпуска или всей сборки, но является более подробным.
Таким образом, несколько команд Scrum работают над несколькими спринтами одновременно. Затем несколько спринтов объединяются для создания релиза. Релиз — это демонстрация программного обеспечения в его текущей форме Владельцу продукта и/или покупателю. Любая критика или предложения учитываются при планировании следующего релиза. Разбивая разработку программного обеспечения на части, называемые релизами, Scrum-Agile также устанавливает ответственность и связь с заказчиком.
Затем процесс начинается заново. Существует планирование выпуска, которое имеет место для создания журнала невыполненных выпусков. Затем формируются Scrum-команды. Начинается планирование Scrum, и каждая команда претендует на часть невыполненной работы по релизу для создания журнала невыполненной работы в спринте. А затем происходит несколько спринтов до следующего релиза. Возникает цикл разработки и развертывания программного обеспечения, который занимает центральное место в циклическом и ритмичном характере Scrum-Agile.
Смущенный? Я знаю, что был. Вот шпаргалка:
Предположим, ваша крупная компания по разработке программного обеспечения только что подписала контракт с новым клиентом и новым проектом:
Первая задача для руководителей компании — обсудить с заказчиком (владельцем продукта), какую функциональность они хотят иметь в программном обеспечении. Этот большой список дел известен как Журнал невыполненных работ.
Затем начнется планирование первого выпуска. Владелец продукта вместе с руководителями команд возьмет часть бэклога продукта и расширит его. Этот новый список дел будет называться Журнал невыполненных релизов.
Затем формируются Scrum-команды из 4–8 человек. Эта команда останется неизменной на протяжении всего Спринта. Планирование спринта будет иметь место, когда мастер Scrum и остальная часть команды возьмут часть невыполненной работы по выпуску и расширит ее. Этот новый список дел будет называться Журнал спринта. В течение следующих 2–4 недель каждая Scrum-команда будет посвящена выполнению задач в своих невыполненных работах. Каждый день члены Scrum-команды будут встречаться на Daily Scrum, чтобы поддерживать открытое общение и создавать подотчетность друг перед другом. В конце каждого спринта будет проводиться ретроспектива спринта, на которой команда будет отмечать свои достижения и размышлять о своих спринтах.
Затем будут сформированы новые команды или одна и та же команда соберется вместе, чтобы повторить процесс Спринта. Время от времени также будет проходить Scrum of Scrums, где все Scrum-мастера будут встречаться друг с другом, с владельцем продукта и/или с клиентом, чтобы обсудить прогресс. Спринты будут выполняться до тех пор, пока не будут выполнены все задачи в журнале невыполненных работ. Релиз будет протестирован, продемонстрирован и развернут.
Затем начнется следующий процесс Релиза… Будет проведено больше спринтов… Больше ежедневных собраний Scrum… Больше Scrum of Scrums… И так далее. Как только все задачи в бэклоге Продукта отмечены, Продукт готов. Но поскольку для продукта всегда создаются новые функции и задачи, лучшим показателем завершения является выпуск релизов.
И это, ребята, фреймворк Scrum-Agile для разработки программного обеспечения. Основное внимание уделяется созданию подотчетности и коммуникации внутри команды и с заказчиком при создании компетентного программного обеспечения по частям для своевременных выпусков. Конечно, эта методология лучше подходит для больших команд, работающих над сложным программным обеспечением, а не для обычного внештатного разработчика, но элементы этой схемы можно использовать для управления любой командой или проектом. Таким образом, Scrum не обязательно является концом всего управления программными проектами, но для некоторых компаний он может быть полезным методом для принятия.
