Продолжается подписка на наши издания! Вы не забыли подписаться?

Каждой методологии - свое время**

Алистэр Коуберн
Humans and Technology
arc@acm.org
Humans and Technology Technical Report 2000.01
Original article

Содержание

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

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

Краткий обзор дискуссии

Эта статья - логическое продолжение предыдущих работ: "Characterizing people as first-order, non-linear components of software development" [Co1] (в русском переводе: "Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения") и "A methodology per project" [Co2] (в русском переводе: "Каждому проекту своя методология"), где обсуждалась возможность создания гибкой "человекоцентричной" методологии для отдельно взятой команды, причем непосредственно в процессе работы над проектом.

Суть изложенного в этих статьях материала сводится к следующему:

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

Можно, конечно, начинать давать рекомендации, основываясь только на принципах конструирования методологии (даже притом, что относительно самих этих принципов до сих пор нет единого мнения). Впрочем, один из них гласит, что в любом проекте человеческий фактор может легко возобладать над процессом (см. [Co1], [Wei]). Легкие методологии, основанные на межличностных коммуникациях, представляют собой довольно прочные структуры (см. [Co2]). Их оптимальный "вес" может разниться от проекта к проекту, в зависимости от количества занятых в работе людей и близости их физического размещения, а также ущерба от возможного сбоя системы (см. [Co2]).

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

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

Данная работа состоит из следующих частей:

<...>

Copyright © 1994-2016 ООО "К-Пресс"