Команды Agile работают качественнее, результаты выдают быстрее, кроме того, они более гибки, что позволяет им быстрее отвечать на изменения в требованиях (когда эти требования приняты всеми заинтересованными лицами). В итоге это ведет к тому, что соотношение прибыли ко вложенному капиталу у них больше (да и сама прибыль зачастую поступает быстрее). Прошли времена доминирования отдельных крупных проектов. В последние годы IT-проекты становятся все мельче и мельче. Поэтому все выше важность создавать продукты быстро и с низкими затратами - это и касается и малых/средних проектов, и подэтапов в больших проектах.

Сейчас рынок быстро развивается во многих отраслях промышленности, и при так называемом традиционном методе выполнения каскадных проектов, когда у вас есть все процедуры, этапы и вся документация об их выполнении, вам очень трудно идти в ногу с конкурентами. На протяжении последних нескольких лет гибкие (Agile) технологии представляли собой одну из ключевых потребностей для изменения процесса разработки, которая позволяет не отставать от следующих лучших поколений продукции. Сейчас конкуренция на многих разных уровнях в промышленности жесткая, многие люди берут уже существующие идеи других людей, а затем просто переносят их на следующий уровень. Так что если вы один из первых, кто сделал отличный продукт, сегодня появляется множество людей, которые автоматически делают то, что делаем мы. Вы должны идти в ногу с ними, а при традиционном каскадном подходе, если бы мы проходили через все эти процедуры, то не добились бы этого. Гибкий подход действительно позволяет нам ускорить процесс и выпускать продукцию на рынок вместе со всеми нашими конкурентами.

Они говорят: переходим на гибкую разработку (Agile). Все будет просто супер. Они, разумеется, не технические писатели.

В настоящее время я уже два года работаю на скрам-команды гибкой разработки в качестве инженера по технической документации (иначе говоря, техническим писателем). За это время я прошла несколько эмоциональных стадий: волнение, уверенность, смятение, разочарование, отчаяние, принятие - и снова уверенность. К этой последней уверенности я пришла, глядя, как мои коллеги по техническому перу начинают свой путь в командах гибкой разработки. В их глазах я вижу те же отчаяние и сомнение, что поразили некогда и меня. И, с сочувствием гладя их по плечу, я осознаю, какой путь я проделала, чтобы прийти к пониманию роли технической информации в гибкой разработке. Не бойтесь, говорю я коллегам. Все не так печально, как кажется. Напротив, скоро вы обнаружите, что все это весьма неплохо работает!

Я работал со многими командами, адаптирующими Agile в своей работе. В каждой ситуации, как правило, камнем преткновения всегда оказывались пользовательские истории, при часто задаваемом вопросе типа: “В чем заключается различие между традиционными требованиями, вариантами использования и пользовательскими историями?” Я бы хотел ответить на этот вопрос, дать определение каждому типу требования и привести примеры. Я буду использовать следующие пример на протяжении всей статьи: представьте, что вы создаете программное оборудование для фирм по трудоустройству управленческих кадров, и одна из таких фирм запросила возможность поиска кандидатов на определенную должность по специальности в пределах конкретной географической локации. Например, “Я хочу найти всех бизнес-аналитиков, специализирующихся в области закона Сарбейнса-Оксли (SOX), в пределах пятидесяти миль от Нью-Йорка”.

Пользовательские истории сильны в определении функциональности продукта с точки зрения пользователя и клиента: каждая пользовательская история описывает единицу функциональности продукта, например, “Являясь провайдером приложения, я бы хотел зарегистрироваться в центре приложений, чтобы иметь возможность пользоваться его услугами”. Сосредоточив внимание на отдельной области функциональности продукта, история позволяет команде понять, внедрить и протестировать требование.

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