Agile-трансформация. Раскрывая гибкость бизнеса. Йорген Хессельберг

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

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

      Представление о том, что лучшее понимание проблемы появляется посредством экспериментов и совместной работы членов команды, применяется и за пределами разработки ПО – в мире разработки продуктов в целом. В 1986 году в журнале Harvard Business Review вышла статья «Разработка нового продукта. Новые правила игры», авторы которой, Хиротака Такеучи и Икуджиро Нонака, провели аналогию между новым способом работы и регби, метафорически описав, как игроки постоянно делятся информацией и передают мяч знаний друг другу.

      Сравнение весьма удачное: подобно спортивной команде, команда разработки ПО – это группа людей, чьи умения дополняют друг друга, собравшаяся, чтобы достичь общей цели.

      Для создания решений, которые понравятся потребителям, нужно проверять предположения об их нуждах, способствуя тем самым обучению – неотъемлемой части процесса разработки продукта. Такеучи и Нонака предупреждали, что способы работы, при которых все предположения о потребителях установлены заранее, несостоятельны:

      «Транснациональные компании должны стать быстрыми и гибкими в разработке продуктов. Чтобы сделать это, нужно использовать динамический процесс, который во многом полагается на метод проб и ошибок и на обучение в процессе работы. Сегодня, в мире постоянных изменений, нужны непрерывные инновации»[14],[15].

      Это понимание заинтересовало Джеффа Сазерленда, бывшего военного летчика, занимавшегося развитием IT-систем в Easel Corporation. Вместе с коллегами он начал искать более гибкий путь разработки программного обеспечения, который учитывал бы обучение, основанное на опыте, напряженную совместную работу и частые петли обратной связи. В 1995 году Сазерленд вместе с Кеном Швабером, разработчиком ПО и промышленным консультантом, формализовали этот способ работы и назвали его фреймворком Scrum. Он был представлен на индустриальной конференции OOPSLA[16].

14

https://hbr.org/1986/01/the-new-new-product-development-game

15

Источник: http://agilerussia.ru/methodologies/разработка-нового-продукта-новые-пра/. Прим. пер.

16

http://www.jeffsutherland.org/oopsla/schwapub.pdf