Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным
- Название:Софт за 30 дней. Как Scrum делает невозможное возможным
- Автор:
- Жанр:
- Издательство:Литагент МИФ без БК
- Год:2017
- Город:Москва
- ISBN:978-5-00100-768-5
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Джефф Сазерленд - Софт за 30 дней. Как Scrum делает невозможное возможным краткое содержание
Эта книга поможет руководителям и менеджерам компаний, которые хотят покончить с дорогим и медленным циклом разработки ПО.
На русском языке публикуется впервые.
Софт за 30 дней. Как Scrum делает невозможное возможным - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
1. Понимает, как создать программное обеспечение, используя технологии, необходимые для пилотного проекта.
2. Имеет все необходимые навыки для разработки законченного фрагмента приложения.
3. Осведомлен об итеративно-инкрементальном процессе разработки. По крайней мере один участник команды должен иметь опыт создания программ этим методом, чтобы направлять других.
4. Каждый участник команды должен быть добровольцем, а не призывником.
5. Участник должен быть увлечен проектом.
Менеджер проекта помог обеспечить соответствующую обстановку для проведения пилотного проекта. В связи с тем что разработчики должны превращать в программное обеспечение идеи именно вице-президента, они организовали рабочее пространство в непосредственной близости от его кабинета. Менеджер проекта также предложил некоторые шаги.
1. Рабочее пространство должно быть организовано таким образом, чтобы все члены команды могли легко видеть, слышать друг друга и друг с другом эффективно взаимодействовать. Это позволит быстро обнаруживать и устранять недопонимания. Рабочее пространство должно быть открытым, без разделяющих перегородок.
2. Флипчарты и лекционные доски в рабочем пространстве могут помочь членам команды визуализировать возможности и найти идеи. Пространство должно обеспечивать место для работы и хранения инструментов на всем протяжении создания пилотного проекта.
3. Члены команды должны работать полный день, так как частично задействованные члены команды могут быть недоступны, когда в них нуждаются остальные. Даже когда они доступны, они могут продолжать думать о других обязанностях.
4. Вся работа должна быть ограничена обычным рабочим временем. Превращение требований в готовый к использованию инкремент программного обеспечения требует решения проблем. Отправляя членов команды по домам в конце обычного рабочего дня, вы позволяете их подсознанию найти новые подходы и обнаружить ошибки.
Итак, вице-президент сформировал команду, состоящую из него, менеджера проекта и трех разработчиков программного обеспечения.
Иногда очень сложно привлечь к проекту хороших разработчиков. Вы можете испытать такие проблемы, если люди не понимают, что эта задача значит для них. Каждый будущий участник команды должен понимать цель и масштаб работы в пилотном проекте.
Послание компании Curaspan, отталкивающее потенциальных сотрудников.Вот вам пример. Онлайн-приложение компании Curaspan используют больницы для передачи документов пациентов после выписки на реабилитацию или другие долгосрочные мероприятия, выполняемые после госпитализации. У компании Curaspan возникли проблемы. Это приложение было создано более десяти лет назад, и его работа стала неприемлемо медленной. Звонки в службу поддержки клиентов стали практически непрерывными.
Эдвина Миллера взяли на позицию вице-президента по управлению продуктами компании. Ранее он перевел несколько компаний на эмпирический метод разработки программного обеспечения. Руководство Curaspan ожидало, что он это сделает и в их компании. Миллер начал набор разработчиков для создания следующего поколения программного обеспечения. В поиске сотрудников он пошел по обычному пути: старые знакомые, люди, известные в индустрии, и агентства по набору персонала. Он просматривал резюме и приглашал подходящих людей на собеседование. Он сделал несколько предложений соискателям, но ни одно не было принято.
Проблема заключалась в том, что руководство и разработчики в Curaspan не были убеждены в том, что эмпирический подход правильный, и не понимали его. Отсутствие у них стратегической приверженности, незнание работы, которую люди будут делать, и их антипатия к эмпирическим процессам пугали соискателей. Даже в условиях экономического кризиса хорошие разработчики находили альтернативные предложения трудоустройства.
Люди чувствуют хорошие вещи. Даже если вы собираетесь экспериментировать с тем, чего вы не делали раньше, то должны создать четкое послание для людей, которых вы хотите привлечь (внутри организации или вне ее). Опишите перспективы и то, что вы для этого сделаете.
Рассредоточенная команда в Iron Mountain.Iron Mountain Digital – это компания по хранению и управлению данными стоимостью 3,1 миллиарда долларов. Она предоставляет услуги по внеофисному хранению резервных цифровых данных с помощью продукта LiveVault. В 2006 году продукт LiveVault испытывал трудности. Новая версия программного обеспечения не выходила более 12 месяцев. Отдельные люди в LiveVault читали об эмпирическом методе разработки программного обеспечения Scrum, но по-прежнему использовали старые методы. Не зная этих трудностей, маркетинговое крыло компании Iron Mountain заключило контракт с Microsoft в июне 2007 года. Microsoft обеспечивала своих пользователей программным обеспечением, постоянно создающим резервные копии. Резервные копии создавались на локальном сервере, и в Microsoft хотели предложить внеофисное хранение резервных данных в LiveVault в качестве альтернативы.
Как менеджер по продукции компании Пол Луппино заключил соглашение с Microsoft на выпуск нового релиза LiveVault. Контракт предполагал, что Microsoft начнет обеспечивать своих клиентов внеофисным хранением резервных данных к февралю 2008 года. Компания Iron Mountain предложила Полу стать менеджером по разработке этого продукта. Трудиться над ним предстояло в течение шести месяцев.
Пол был прижат к стенке, и его работу еще более затрудняло то, что ему приходилось управлять командами разработчиков, расположенных в разных местах. У Пола было множество партнеров, корпоративные обязательства, необходимость соблюдения даты выпуска, подавленная неудачами команда и 12 месяцев истории постоянных провалов.
Он слышал о Scrum, поэтому немедленно заказал обучающие курсы для всех участников проекта в Iron Mountain и одновременно начал разработку итераций. Пол не знал, какие у него могут возникнуть проблемы, но он знал, что, если все исследовать и обдумывать планы, могут пройти месяцы. Он решил начать разработку сразу, а проблемы решать по мере их поступления. Итерации позволят ему и Iron Mountain знать в пределах 30 дней, есть ли у них проблемы и выполним ли проект.
Все испытывали трудности из-за физической дистанции между командами разработчиков. Видеоконференции были дорогими, Skype работал недостаточно хорошо, и расходы на переезды также очень высоки. Каждый участник координировал свою работу во время ежедневных совещаний (используя дорогостоящие видеоконференции, электронную почту и инструменты социальных сетей), связывающих разработчиков из Iron Mountain в Массачусетсе, разработчиков Microsoft в Индии и менеджеров Microsoft по продуктам в Вашингтоне, чтобы оценивать прогресс в разработке и вносить изменения в дальнейшие планы.
Читать дальшеИнтервал:
Закладка: