Библиотека knigago >> Деловая литература >> Корпоративная культура >> Софт за 30 дней. Как Scrum делает невозможное возможным

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

Софт за 30 дней. Как Scrum делает невозможное возможным
Книга - Софт за 30 дней. Как Scrum делает невозможное возможным.  Джефф Сазерленд , Кен Швабер  - прочитать полностью в библиотеке КнигаГо
Название:
Софт за 30 дней. Как Scrum делает невозможное возможным
Джефф Сазерленд , Кен Швабер

Жанр:

Экономика, Корпоративная культура

Изадано в серии:

неизвестно

Издательство:

Манн, Иванов и Фербер

Год издания:

ISBN:

978-5-00100-768-5

Отзывы:

Комментировать

Рейтинг:

Поделись книгой с друзьями!

Помощь сайту: донат на оплату сервера

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

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

Читаем онлайн "Софт за 30 дней. Как Scrum делает невозможное возможным" (ознакомительный отрывок). [Страница - 2]

хотим вернуть ваше доверие. Во-вторых, программное обеспечение – это уже не только специализированный инструментарий для профессионалов. Программы теперь в нашем обществе выполняют все более и более важные операции. Мы хотим, чтобы вы были способны создать программное обеспечение, на которое мы все можем надежно полагаться.

Мы надеемся, что сможем достичь этих целей с помощью нашей книги.

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

1. Кризис в программном обеспечении: неправильный процесс разработки приводит к неправильным результатам

Ваша организация, будь то коммерческая, некоммерческая или государственная компания, должна быть в состоянии выдавать полезный продукт путем создания, настройки и использования программного обеспечения. Без программ ваша способность достичь целей как бизнес-лидера сильно ограничена, если не полностью невозможна. Но, несмотря на эту потребность, разработка программного обеспечения – исторически ненадежный, дорогостоящий и подверженный ошибкам процесс[1]. Это создает проблему: вам нужно программное обеспечение, но вы не можете получить его в нужное время, по приемлемой цене и с уровнем качества, которое делает его использование удобным.

Действительно, The Standish Group в своем CHAOS Report 2011 года обнаружила, что половина проектов по разработке программного обеспечения с 2002 по 2010 год описывались либо как трудные для выполнения, либо как полный провал. Только 37 % были классифицированы как успешные (рис. 1.1). The Standish Group скромно называет успешным проект, который обеспечивает требуемый функционал в срок и по заявленной цене.


Книгаго: Софт за 30 дней. Как Scrum делает невозможное возможным. Иллюстрация № 1 Рис. 1.1. Риски традиционного метода разработки программного обеспечения


Способность приспосабливаться к изменениям, управлять рисками или изначальная ценность программного обеспечения не рассматривалась.

Вероятность того, что проект разработки программного обеспечения будет успешным, невелика. Если вы пытаетесь сделать что-то важное, включающее в себя разработку программного обеспечения, то, вероятно, должны быть обеспокоены. Индустрия программного обеспечения, будучи медленной, дорогой и непредсказуемой, подведет вас. Если бы софт не был столь важным, вы бы, скорее всего, совсем не стали бы инвестировать в него.

И вы не одиноки. К примеру, проект «Страж» Федерального бюро расследований (ФБР) недавно столкнулся с проблемами, и его полностью обновили, используя идеи и процессы, описанные в этой книге.

Информация, касающаяся проекта «Страж», взята из общедоступных отчетов Министерства юстиции США. До того как вы определите это как частный случай, являющийся особенностью работы правительства, подумайте: если крупное министерство смогло кардинально улучить свой метод разработки программного обеспечения, то сможет и ваша организация.

Пример: проект «страж» федерального бюро расследований
Все записи, которые были созданы или получены в рамках того или иного расследования ФБР, собраны в папки. В 2003 году ФБР решило оцифровать дела и автоматизировать связанные процессы, чтобы агенты могли быстро сравнивать дела и обнаруживать связи между ними. Проект назвали «Страж».

В марте 2006 года ФБР приступило к разработке «Стража», целью проекта было создание базы для более чем 30 тысяч конечных пользователей, агентов ФБР, аналитиков и административного персонала. По предварительной оценке, на разработку и запуск «Стража», что должно было произойти к декабрю 2009 года, выделили 451 миллион долларов. Согласно первоначальному плану ФБР, разработка «Стража» должна была пройти в четыре стадии. Проекта поручили корпорации Lockheed Martin, практикующей традиционный процесс разработки программного обеспечения.

К августу 2010-го ФБР потратило 405 из 451 миллиона долларов бюджета --">

Оставить комментарий:


Ваш e-mail является приватным и не будет опубликован в комментарии.