Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным
- Название:Софт за 30 дней. Как Scrum делает невозможное возможным
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-768-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным краткое содержание
Эта книга поможет руководителям и менеджерам компаний, которые хотят покончить с дорогим и медленным циклом разработки ПО.
На русском языке публикуется впервые.
Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Обучение разработчиков. Разработчики, задействованные в гибкой разработке, должны научиться действовать как самоорганизованные, кросс-функциональные команды, которые предоставляют законченные инкременты функциональных возможностей, используя современные инженерные практики и специфические технологические приемы.
Обучение Agile/Scrum : успешное внедрение Scrum будет в значительной степени зависеть от общего знания терминологии всех вовлеченных в процесс людей. Это может быть достигнуто в течение 2–4-часовых вступительных курсов для 30–50 % организации.
В дополнение вы можете использовать другие виды деятельности для увеличения видимости и уровня одобрения Scrum в организации.
Информационные материалы . Уведомляйте о состоянии Scrum-проектов через простые и убедительные информационные материалы, такие как панели задач, бэклог продукта и выпуска, а также диаграммы сгорания задач.
Чтение. Составить список книг и статей, способствующих дальнейшему расширению знаний, которые могут быть предоставлены всем людям в организации.
Семинары и неформальные встречи с участием руководства . Лидеры, отвечающие за изменения, должны часто и открыто общаться по поводу того, что происходит в организации. Неформальные встречи, такие как общение за обедом, имеют тенденцию позитивно влиять на протекание изменений.
Общение в корпоративных чатах, публикация отзывов людей, участвовавших в пилотных проектах . Результаты пилотных проектов должны быть доступны каждому, это расширит обсуждение и вовлеченность на всех уровнях организации.
1.4.4. Действие 3 – достижение воздействия
Так как пилотные проекты доказали, что с помощью гибких методов разработки программного обеспечения достигается реальная польза, цель этого действия заключается в достижении более значительного влияния на более широком уровне, что может быть продемонстрировано только с помощью все более и более крупных проектов. При помощи предыдущих действий организация накопила значительное количество явных и косвенных знаний, чтобы справиться со следующим шагом с высокой вероятностью успеха. На этом этапе не менее 25 % всей организации должны быть вовлечены в реализацию Scrum.
Эффективное изменение теперь должно происходить как внутри, так и за пределами отдела разработки. Внутри отдела эта работа лежит на команде разработки. За его пределами деятельностью по ликвидации препятствий руководит Scrum-мастер организации, а сама работа выполняется затронутыми ведомствами.
I. Проекты по разработке программного обеспечения
Продолжительность: постоянно.
Поддержка: внутренняя.
Описание: разработка проектов по созданию программного обеспечения с контролем показателей возврата инвестиций.
II. Проекты изменений
Продолжительность: б о льшая часть работы приходится на один-два года, а далее по необходимости.
Поддержка: внутренняя.
Описание: проекты организационных изменений устраняют возникающие препятствия в разных ведомствах предприятия.
III. Оценка и адаптация
Продолжительность: каждый спринт.
Поддержка: внешний/внутренний Scrum-мастер.
Описание: обзор количественных и качественных показателей. Добавление дополнительных показателей и обзор того, какие показатели фиксируются каждый раз, когда происходят непредвиденные случаи.
1.4.5. Действие 4 – измерение, оценка и регулировка
Цель этого действия заключается в оценке прогресса организации и создании более широкого набора показателей, служащих основой для дальнейшего расширения. Руководитель должен быть в курсе, что предстоящее обсуждение новых показателей может вызвать как споры, так и поддержку в связи с тем, что многие традиционные показатели, которые применялись в организации до внедрения Scrum (например, показатель полноты документации), теряют свое значение. К счастью, Scrum и гибкие методы разработки – действительно контролируемые и измеряемые, поэтому использующие эти методы исполнители получают набор показателей, предоставляющих качественную и достаточную обратную связь как на уровне процесса разработки, так и на уровне проекта.
Но перед началом обсуждения новых показателей должна быть четко проведена граница между множеством традиционных процессов разработки программного обеспечения и гибкими процессами, то есть Scrum.
Основной показатель гибкого метода разработки программного обеспечения – существует ли реально работающее программное обеспечение и подходит ли оно для использования по планируемому назначению. В Scrum этот ключевой индикатор определяется опытным путем, путем демонстрации в конце каждого спринта.
Эта первичная мера качества программного обеспечения и производительности – сущность процесса гибкой разработки. Таким образом, со Scrum вы не можете отойти слишком далеко от цели, не зная, где находитесь. Все остальные показатели находятся в подчинении этой цели и постоянно повторяющегося принципа «частой поставки рабочего программного обеспечения».
На данном этапе процесса адаптации Scrum значительная часть организации уже работает в гибкой манере. Результаты спринтов первоначальных проектов – основные показатели эффективности новой модели поведения команды и новых процессов. Эти данные должны быть опубликованы и проанализированы.
Более того, теперь самое подходящее время для определения набора вторичных показателей, служащих ориентиром организации на пути реализации Scrum. При этом есть два типа показателей, которые могут быть применены.
Показатели процесса – в первую очередь качественные показатели эффективности команд и организации в усвоении Scrum. Это такие элементы, как эффективность команд по управлению бэклогом продукта, эффективность Scrum-процессов, например ежедневного Scrum-митинга, планирования спринта и так далее.
Показатели проекта – на уровне проекта дополнительный набор показателей может быть применен для оценки результатов конкретной Scrum-команды и службы, компонента или системы, за которую эта команда несет ответственность. Этот набор может включать в себя некоторые традиционные показатели, например подсчет дефектов, процент кода с юнит-тестированием, процент кода с автоматическим регрессионным тестированием и так далее. А также специфические Scrum-показатели: количество законченных пользовательских историй и демонстраций в конце каждого спринта.
Клиенты часто оказывают давление на организации разработчиков программного обеспечения с целью получить функциональные возможности быстрее, чем это возможно. Некоторые организации идут на это за счет снижения качества продукта, отбрасывая рефакторинг, урезая время тестирования и других необходимых инженерных манипуляций. Это не поддерживается в Scrum-процессах, так как система или продукт – корпоративный актив, который постоянно усовершенствуется и объективно оценивается, а не одноразовый проект активов. Инженерные организации, поддавшиеся этому давлению, в конце концов строят «мертвые модели» систем, которые не могут эффективно обслуживаться и улучшаться. Организация тратит огромные средства на переписывание и повторный выпуск существующей основы программного кода. Чтобы этого избежать, только на уровне высшего руководства может быть принято решение о снижении качества.
Читать дальшеИнтервал:
Закладка: