• создание способов программирования и команды разработки, позволяющих обеспечивать непрерывную адаптацию к изменяющимся требованиям.
В 2001 году многочисленные основатели и последователи таких методологий, включая лидеров, использующих Scrum, встретились, чтобы понять, что у них всех есть общего.
Они выбрали слово «гибкий» в качестве объединяющего термина и создали Манифест гибкой разработки программного обеспечения, в котором заявили общие ценности.
• люди и взаимодействие важнее процессов и инструментов;
• работающее программное обеспечение важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.
Манифест инициировал тысячи новых гибких проектов. Результаты и опыт этих проектов дали дальнейшее развитие практическим способам применения многочисленных форм гибких подходов к разработке программного обеспечения. Как и в любой деятельности, некоторые из них оказались успешными, а другие потерпели неудачу. Но самым поразительным было то, что и бизнесмены, и технический персонал относились к работе в этих проектах с любовью. Это был именно тот способ разработки программного обеспечения, о котором они мечтали, и конечные пользователи и клиенты также были с ними согласны. Успешные проекты порождали больше последователей, и, как и при успешном спринте, этот гибкий цикл продолжается по настоящее время.
1.3. Подготовка к Scrum
После того как высшее руководство предприятия получает общее представление о деловых и культурных преимуществах Scrum и гибких способов разработки, оно часто хочет сделать следующий шаг и оценить, как этот метод разработки может улучшить их организацию.
В течение первых 15 лет жизни Scrum его применение в большинстве случаев происходило в организациях снизу вверх. Другими словами, команда, работающая над проектом, пробовала Scrum и добивалась впечатляющих результатов. Затем его пробовала другая команда, и очень скоро Scrum-проекты появлялись по всей организации. В последнее время, однако, многие организации стремятся внедрить Scrum сверху, в рамках процесса развития компании и работы по улучшению производительности и ускорению реагирования на рыночные условия.
Поскольку Scrum – это в основном расширение прав и возможностей команды разработки в принятии самостоятельных решений, его внедрение сверху требует вдумчивого рассмотрения и подготовки, которую мы опишем в этом разделе.
1.3.1. Скрамить сразу и процесс разработки программного обеспечения, и организацию
Многие организации в течение долгих лет вынуждены были преодолевать различные препятствия и терпеть недостатки. Scrum быстро их выявляет и требует их устранения. К счастью, повышение производительности и ценности, полученные в результате Scrum-проектов, делают усилия по внедрению стоящими, но это все еще усилия.
Чтобы применить Scrum, организация должна выполнить два типа работы. Во-первых, проекты, где команды разработки учатся создавать программное обеспечение с использованием Scrum. Во-вторых, устранение препятствий на пути оптимизации создания и выпуска программного обеспечения, с которыми могут столкнуться Scrum-команды. Первая работа улучшает поставку программного обеспечения, а вторая убирает помехи на пути повышения прибыльности и производительности.
Оба типа работ представляют собой вызов и требуют значительных усилий сверх обычного процесса разработки программного обеспечения. Полная реализация Scrum на предприятии может занять до пяти лет. Независимо от интенсивности усилий и желаний руководства этот график не может быть ускорен, поскольку ядро проекта – организационное изменение.
Ежедневные и ежемесячные циклы инспекции и адаптации при использовании Scrum делают все видимым: технические методы разработки, технологический процесс и организационные помехи. Проекты, использующие Scrum, регулярно выявляют препятствия, которые должны быть записаны, которым должна быть дана оценка, присвоен приоритет и в отношении которых следует принять соответствующие меры.
Скорость внедрения Scrum напрямую связана со следующим:
• степенью необходимых изменений внутри организации;
• срочностью в улучшении разработки и выпуска программного обеспечения в пределах организации;
• эффективностью руководства в рамках организации.