Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным

Тут можно читать онлайн Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным - бесплатно ознакомительный отрывок. Жанр: Деловая литература, издательство Литагент МИФ без БК, год 2017. Здесь Вы можете читать ознакомительный отрывок из книги онлайн без регистрации и SMS на сайте лучшей интернет библиотеки ЛибКинг или прочесть краткое содержание (суть), предисловие и аннотацию. Так же сможете купить и скачать торрент в электронном формате fb2, найти и слушать аудиокнигу на русском языке или узнать сколько частей в серии и всего страниц в публикации. Читателям доступно смотреть обложку, картинки, описание и отзывы (комментарии) о произведении.
  • Название:
    Софт за 30 дней. Как Scrum делает невозможное возможным
  • Автор:
  • Жанр:
  • Издательство:
    Литагент МИФ без БК
  • Год:
    2017
  • Город:
    Москва
  • ISBN:
    978-5-00100-768-5
  • Рейтинг:
    4/5. Голосов: 11
  • Избранное:
    Добавить в избранное
  • Отзывы:
  • Ваша оценка:
    • 80
    • 1
    • 2
    • 3
    • 4
    • 5

Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным краткое содержание

Софт за 30 дней. Как Scrum делает невозможное возможным - описание и краткое содержание, автор Джефф Сазерленд, читайте бесплатно онлайн на сайте электронной библиотеки LibKing.Ru
Прочитав эту книгу, вы познакомитесь с методикой Scrum и узнаете, как этот нестандартный подход работает и как начать применять его в своем бизнесе на примере процесса разработки программного обеспечения. Гибкие технологии Agile и Scrum позволят вам осуществить то, что раньше казалось абсолютно невозможным, – создать полноценный работающий программный продукт всего за 30 дней.
Эта книга поможет руководителям и менеджерам компаний, которые хотят покончить с дорогим и медленным циклом разработки ПО.
На русском языке публикуется впервые.

Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн бесплатно ознакомительный отрывок

Софт за 30 дней. Как Scrum делает невозможное возможным - читать книгу онлайн бесплатно (ознакомительный отрывок), автор Джефф Сазерленд
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать

Масштабирование Scrum для больших приложений (как показано на рис. А3.2) оставляет этот ключевой принцип на месте.

.

Рис А32 Система создаваемая тремя Scrumкомандами в течение трех спринтов - фото 36

Рис. А3.2. Система, создаваемая тремя Scrum-командами в течение трех спринтов

Таким образом, масштабирование для приложения с участием 300 человек включает в себя организацию около 30 Scrum-команд. Как обсуждалось ранее, комплектация команды должна быть полной, чтобы она могла разрабатывать потенциально готовые к выпуску элементы функциональности после каждого спринта. В большинстве случаев это требует реорганизации команд вокруг отдельных свойств продукта, сервисов, компонентов и подсистем, а не по индивидуальной роли (например, команда разработчиков, команда тестирования и тому подобное). Мы обсуждали эти организационные препятствия и ранее, и, как видим, они усугубляются по мере увеличения размера нашего проекта.

Организация следует за архитектурой

Кроме того, мы не можем легко формировать Scrum-команды без понимания того, как каждая индивидуальная команда может относительно целостно предоставить функциональные возможности для конечного пользователя. В свою очередь, это предусматривает, что мы раскладываем архитектуру приложения на компоненты и подсистемы, которые имеют концептуальную целостность и могут представлять бизнес-ценность сами по себе [19]. Scrum подготавливает эту архитектурно-производственную деятельность на фазе подготовки спринта и первых спринтах, с помощью первых Scrum-команд. Этот метод особенно хорошо работает в период распространения Scrum в организации и развертывания для большого проекта. Здесь первые команды создают контрольные точки потребительской ценности и в то же время закладывают архитектуру приложения, способную принять дополнительные команды, обучение которых происходит примерно в это же время. По мере того как формируется новая команда, ее роль в большой системе становится ясной и появляется общая картина, как на рис. А3.2.

1.6.2. Координирование Scrum-команд из Scrum-команд

Конечно, наличие большого количества команд чревато значительными проблемами в координации и коммуникации между группами. Кроме того, это предполагает, что, скорее всего, возникнет некоторое количество проблем на системном уровне, которые потребуют такой же ежедневной и ежемесячной инспекционной деятельности, которая применяется на уровне локальной команды.

Опыт работы с масштабированием Scrum для больших команд привел к созданию набора полезных практических методов для координации различных команд и решения более сложных задач по планированию спринта, даты релиза системы, отслеживанию интеграции компонентов и деятельности по тестированию.

Ежедневное общение: Scrum над Scrum

Таким же образом, как Scrum обеспечивает ежедневное общение на мероприятии – ежедневный Scrum-митинг, более крупные и распределенные команды, как правило, координируют свою деятельность на мероприятии ежедневный Scrum над Scrum. На этом совещании лидеры от каждой команды используют тот же самый формат, что и на ежедневном совещании отдельной команды:

1) что вчера сделала моя команда для достижения целей спринта?

2) что моя команда будет делать сегодня?

3) какие препятствия могут помешать моей команде достичь целей спринта?

В идеальном случае это мероприятие должно проводиться непосредственно после ежедневного Scrum-митинга индивидуальных команд. Когда команды рассредоточены, это совещание часто проводится по телефону, время дня выбирается для обеспечения максимального привлечения всех участников Scrum над Scrum.

Планирование релиза на уровне системы и отслеживание. Рисунок А3.2ошибочно дает понять, что вопрос по разделению организации на команды по работе над отдельными функциями продукта, сервисами и подсистемами довольно простой: команды сделают свою работу, и интегрированная система получится естественным образом. Опыт показывает, что это крайне маловероятно. Даже когда индивидуальным командам ставится задача достичь целей спринта и скоординировать интеграцию между командами и подсистемами, присутствует целый ряд больших трудностей. Это необходимость в создании целостной системы, когда мы встраиваем и тестируем наши интеграции со всеми подсистемами и где подсистемы работают вместе для обеспечения более широких требований пользователей, а вся система должна соответствовать требуемому уровню качества, производительности и надежности. Теперь нам требуется, чтобы любая работа отдельной команды считалась законченной и интегрированной и работа всех команд по интеграции тестированию должна быть закончена. Это показано на рис. А3.3.

Рис А33 Система из трех подсистем Для решения этих проблем многие команды - фото 37

Рис. А3.3. Система из трех подсистем

Для решения этих проблем многие команды добавили роль технического лидера, выполняемую на уровне системы. Архитекторы, лидеры команд, менеджеры продуктов и персонал контроля качества часто объединяются в дополнительную Scrum-команду, думающую и действующую на системном уровне. Кроме того, члены этой команды могут также применять Scrum-метод на уровне системы, устанавливать набор целей спринта и создавать пункты бэклога, включающие системные интеграции, демонстрации на системном уровне, контрольные точки проверки качества, создание пробных выпусков и других мероприятий, гарантирующих, что разработка системы идет по выбранному пути. Из всей этой работы возникает общая картина, показанная на рис. А3.3.

1.6.3. Инструментальная инфраструктура для гибкости предприятия

Даже при таком уровне структуры и координации в больших проектах и при распределенных командах могут ощущаться недостаток координации между командами и недостаточная проектная прозрачность, необходимые для надежного выпуска программного обеспечения с помощью быстрых, полностью протестированных итераций. Хотя Scrum предоставляет проверенную основу для управления проектами, касающимися разработки программного обеспечения, он не предписывает специфические методы разработки и не рекомендует конкретный набор инструментов для поддержки Scrum-процесса. Философия Scrum в этом отношении состоит в том, чтобы «сохранить его простым и позволить команде решать». Поскольку организации испытывали трудности с применением современных инженерных практик, Scrum.org представил курсы и программы для Scrum-разработчиков, ориентированных на современные инструменты управления жизненным циклом приложений.

Читать дальше
Тёмная тема
Сбросить

Интервал:

Закладка:

Сделать


Джефф Сазерленд читать все книги автора по порядку

Джефф Сазерленд - все книги автора в одном месте читать по порядку полные версии на сайте онлайн библиотеки LibKing.




Софт за 30 дней. Как Scrum делает невозможное возможным отзывы


Отзывы читателей о книге Софт за 30 дней. Как Scrum делает невозможное возможным, автор: Джефф Сазерленд. Читайте комментарии и мнения людей о произведении.


Понравилась книга? Поделитесь впечатлениями - оставьте Ваш отзыв или расскажите друзьям

Напишите свой комментарий
x