|
Страница 19 из 19
Нужен ли вам гибкий процесс? Гибкие процессы подходят не для всех. Если вы решили идти этим путем, то нужно помнить о нескольких важных моментах. Впрочем, я абсолютно уверен, что эти новые методологии могут применяться достаточно широко. Во всяком случае, сейчас их принимает во внимание гораздо меньшее количество людей, чем может использовать. Сегодня самой распространенной методологией остается "пишем и исправляем". Внести в этот хаос немного дисциплины всегда на пользу, к тому же у гибких подходов есть существенное преимущество - переход к ним осуществить значительно легче, нежели использовать тяжеловесную методологию. Гораздо легче перейти к использованию простого процесса, особенно если до этого никакого процесса у вас вообще не было. Одно из самых серьезных ограничений этих методологий - применение их в больших командах разработчиков. Crystal используется в коллективах до 50 человек. К сожалению, у нас нет сведений, используются ли гибкие методологии бОльшими командами. Более того, неизвестно, можно ли их вообще использовать в таком случае. Надеюсь, в этой статье ясно прозвучал тезис, что гибкие подходы хорошо использовать в том случае, если вам неясны требования к системе или если они часто изменяются. Если у вас нет стабильных требований, то это не та ситуация, в которой можно разработать стабильную архитектуру или же работать по неизменному плану. Возможно, в этом случае адаптивный процесс будет не так удобен, зато он будет более эффективен. Нередко наибольшим препятствием на пути использования адаптивного процесса является заказчик. С моей точки зрения, заказчик должен понимать, что работать по предсказуемому процессу при часто меняющихся требованиях для них так же рискованно, как и для разработчиков. Итак, как вы заметили, я сказал, что если у вас в команде более 50 человек, вам следует использовать предсказуемый процесс, а если требования к системе часто меняются, то адаптивный. Что же делать, если у вас и большой проект, и меняющиеся требования? Честно говоря, не знаю. Могу только сказать, что вам придется попотеть, но вы об этом наверняка и сами догадываетесь. Если вы решили работать согласно адаптивному процессу, необходимо доверять своим разработчикам и привлекать их к принятию решений. Все адаптивные процессы основаны на доверии к команде, поэтому если вы считаете, что ваши разработчики не обладают достаточной квалификацией и мотивацией, используйте предсказуемый процесс. Итак, подведем итоги. Адаптивный процесс стоит использовать, если у вас: - Неясные или изменяющиеся требования к системе
- Ответственные и квалифицированные разработчики
- Понимающий заказчик, который согласен участвовать в разработке.
А в этих случаях лучше использовать предсказуемый процесс: - Команда разработчиков более 50 человек
- Контракт с фиксированной стоимостью, или, скорее, с фиксированным объемом работ.
Какой из гибких процессов выбрать? Все описанные выше процессы новые, поэтому я только могу дать вам совет, основываясь на личном опыте. По моему мнению, весь вопрос в размере команды и объеме дисциплины, на который они согласны. Я без сомнения порекомендовал бы ХР, если у вас есть дюжина или меньше разработчиков, которые хотели бы попробовать этот процесс. Возможно, ваша команда не будет соблюдать этот процесс в точности (по крайней мере, в начале), однако даже в этом случае, частичное использование ХР будет полезным. С моей точки зрения, главным показателем правильного использования процесса является написание автоматизированных тестов (unit testing). Если команда справляется с этим, то все остальное приложится. Если же нет, то, скорее всего, ХР им не подойдет. Если команда очень большая, или в ней хромает дисциплина, то я бы стал использовать Crystal. Это самая легкая из всех гибких методологий, а Коуберн очень восприимчив к урокам разработки. Но и в этом случае процесс планирования я бы позаимствовал у ХР. Впрочем, сам я работаю с командой из 40 человек, которые успешно используют многие из практик ХР, и уже довольно близки к использованию этой методологии в полном объеме. Таким образом, имея целеустремленную команду единомышленников, вы можете адаптировать процесс даже к нетипичным для него условиям. И, наконец, самое главное. Какой бы процесс вы не взяли, поначалу он все равно вам не совсем подойдет. Вы должны контролировать процесс, отслеживать его и подстраивать под ваши конкретные нужды. В конце концов, это будет ваш собственный процесс, а всяческие ярлыки не так уж важны. Благодарности Идеи для этой статьи я позаимствовал у большого числа людей, гораздо большего, чем могу здесь перечислить. За конкретные замечания я хотел бы поблагодарить Марка Бэлсера (Marc Balcer), Кента Бека, Алистэра Коуберна, Уорда Каннингэма, Билла Киммеля (Bill Kimmel) и Фрэнка Вестфэла (Frank Westphal). |