A6.4 Сравнение Процесса TenStep с Agile Software Development

(A6.4.P1)

В последние годы стали очень популярными идеи, как сделать процесс разработки программного обеспечения проще, легче и более отзывчивым к потребностям клиента. Экстремальное программирование (Extreme programming, XP), SCRUM, методологии Crystal - вот только некоторые примеры таких идей. В феврале 2001 года 17 энтузиастов, возглавлявших различные течения в данном направлении, встретились для того, чтобы сформулировать общие постулаты "быстрой" разработки программного обеспечения. Результатом стал манифест (Agile Manifesto), включающий ряд принципов и философию разработки, содержание которых мы приведем ниже.

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

The Manifesto for Agile Software Development
Seventeen anarchists agree:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Процесс TenStep

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

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

That is, while we value the items on the right, we value the items on the left more.

We follow the following principles:

 

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Философия Agile предполагает итеративную разработку с ранним созданием прототипа программного продукта и дальнейшим его развитием по мере уточнения требований. Это замечательный подход к разработке, но далеко не для всех типов проектов он приемлем. В то же время, если такой подход может иметь применение, то стоит попытаться его использовать.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

При итеративной разработке, требования к ПО не обязательно должны быть фиксированными на ранних стадиях. Но даже и в этом случае, с какого-то момента их стоит зафиксировать, чтобы произвести поставку результата. С момента фиксации требований в игру должна вступить процедура управления изменениями объема.

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

Подход TenStep заключается в том, что если потребности клиента меняются, команда проекта должна быть готова пойти навстречу. Если такие изменения начинают влиять на бюджет и сроки проекта, то они должны утверждаться спонсором. В этом и заключается сущность управления изменениями объема.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

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

"Быстрые" процессы также стремятся к сокращению цикла разработки, вплоть до недельного. Хотя это может оказаться не совсем просто в управлении, в таком подходе нет ничего противоестественного.

Business people and developers work together daily throughout the project.

Совершенно справедливо. Быть в курсе потребностей клиента - наилучший подход к разработке полезного результата.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

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

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

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

Working software is the primary measure of progress.

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

Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

При правильном планировании и управлении совершенно реально работать по 40 часов в неделю. Это действительно самый лучший подход.

Continuous attention to technical excellence and good design enhances agility.

Техническое совершенство и хорошая предварительная проработка архитектурных решений совершенно необходимы для успешного применения процессов "быстрой" разработки.

Simplicity—the art of maximizing the amount of work not done—is essential.

Справедливо. И разработчики, и клиенты должны в первую очередь сосредоточиться на реализации наиболее важных требований. Это позволит оптимизировать направление разработки и поставить полезные для заказчика результаты в кратчайший срок.

The best architectures, requirements and designs emerge from self-organizing teams.

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

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Совершенно справедливо. Команды должны постоянно стремиться к пониманию своих сильных и слабых сторон и к улучшению рабочих процессов. Процесс TenStep рекомендует также идеи по совершенствованию управления проектами выносить на уровень организации, чтобы они становились достоянием всего персонала.

—Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
www.agileAlliance.org

 

[Пред. стр. - Сравнение TenStep и Six Sigma]   [След. стр. - Сравнение TenStep с ISO 10006]

хостинг Rambler's Top100 Рейтинг@Mail.ru Рассылка 'Совет недели менеджеру проекта' Mail.Ru