Scrum на практике. Высокая продуктивность и результаты – прямо сейчас | страница 7
Многое в этом методе обусловлено цифровыми трансформациями. Суть в том, что сошедшее на нет разделение между IT и бизнесом – к лучшему. Сейчас каждая компания технологическая, программное обеспечение поглотило мир. В вашей машине больше строк кода, чем в Windows. Да даже моя новая стиральная машина хочет знать пароль от Wi-Fi.
Теперь компании, зачастую с подачи CEO, который посмотрел TED Talk[5] или услышал о преимуществах Agile от товарищей либо консалтинговой компании, решают, что «после нас хоть потоп» и гибкими стать нужно.
И на этом моменте, думаю, пора дать определение термину Agile («гибкость») и тому, как с ним соотносится Scrum. Scrum появился в 1993 году, и был формализован его двумя соавторами – Джеффом Сазерлендом и Кеном Швабером – в 1995 году. В середине 1990-х в новостных группах Usenet[6] и на конференциях многие пытались придумать пути разработки программного обеспечения, которые обеспечили бы меньшую частоту провалов.
В 2001 году семнадцать таких людей на пару дней собрались вместе на горнолыжном курорте в городе Сноуберд. Мой отец Джефф Сазерленд был там, как и Кен Швабер, и еще один ранний адепт Scrum Майк Бидл, и четырнадцать человек с разным прошлым и разными методологиями. Однако все они признавали, что пытались решать одни и те же проблемы. Пути их были схожи, но не одинаковы.
В первый день, как мне рассказали некоторые из присутствовавших там, они спорили. В основном о том, как же назвать подход, что они нащупали, но которому еще не дали имя. К концу дня Майк Бидл предложил слово agile. Все согласились с тем, что оно лучше других предложенных, вроде lightweight («легковесность»). Так они решили назвать подход гибким. А потом начали обсуждать, что же именно это будет означать.
На следующий день они снова спорили. Хорошо, они нашли гибкость, но что же это значит? Как ее описать? Девятеро из тех, кто был в комнате, решили выйти покурить, восемь остались внутри. Один из них, Мартин Фаулер, подошел к доске и сказал что-то вроде: «Не правда ли, будет жаль, если мы так ни к чему и не придем за эти два дня?» И примерно за пятнадцать минут восемь человек, что остались в комнате, пришли к следующему.
Мы постоянно открываем для себя более совершенные методы разработки ПО, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать следующее.
Люди и взаимодействия важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.