|
Страница 2 из 5
Динамические методологии Коль скоро мы осознаем, что каждый проект заслуживает своей собственной методологии, то становится понятно, что любое изначальное предположение о ней является всего лишь догадкой. Ответ на вопрос "как нам с течением времени трансформировать эту догадку в нечто действительно полезное для проекта" предполагает, что разработка ведется инкрементным методом. Насколько я могу судить, это единственное необходимое методологическое условие. При этом инкременты могут длиться от одной недели до полугода. Начало проекта Любая организация имеет некоторые характерные черты, сильные и слабые стороны. Чтобы первое предположение относительно методологии было максимально точным, нужно предварительно расспросить разработчиков о предыдущих проектах. Скорее всего, ваши собеседники опишут вам как сильные, так и слабые стороны работы компании. Вот два примера: "В успешно завершившихся проектах между разработчиками и пользователями (или менеджментом) была налажена тесная коммуникация. А в неудачных общение было поставлено из рук вон плохо". "Все ребята из команды разработчиков интерфейсов имеют кандидатскую степень по психологии и работают тремя этажами выше программистов. Во время работы мы столкнулись с определенными проблемами, обусловленными разным образованием и мировоззрением людей, а также недостаточностью личного общения." Первое утверждение указывает на то, что выявление наиболее удобных форм коммуникации и желание их внедрять должны стать первоочередной заботой руководителей с самого начала проекта. Второе - на то, что в используемом процессе должны существовать дополнительные механизмы для улучшения общения и совместной работы двух групп сотрудников. Лучше всего проводить опрос, не ожидая заранее каких-то определенных ответов. Нередко опрашиваемые говорят о вещах, которые как бы не относятся к процессу, но, тем не менее, оказываются очень важными для его улучшения. (Примером может служить вторая цитата, или же любой комментарий относительно личных качеств людей, освещения, совместного времяпрепровождения и т.п.) Таким образом, во время опроса можно смело спрашивать: "Что вы можете рассказать о том, как проходил проект?" "Что вам понравилось/не понравилось в работе над этим проектом?" "Что из этого вам хотелось бы изменить/оставить без изменений при работе над следующим проектом?" "Что вам кажется наиболее важным?" Все ответы и предложения должны быть тщательно запротоколированы. Теперь объедините данные всех опросов и выделите их общие черты. Именно они говорят о сильных и слабых сторонах организации. В тех ответах, которые доводилось слышать мне, максимальное внимание уделяется именно человеческому фактору (как в двух приведенных выше примерах). Нередко мне приходится сталкиваться и с комментариями относительно любви/или нелюбви к CASE инструментам, проверке и пересмотру кода, нестабильности требований, частоты итераций, тестирования и стандартов кодирования. В этот момент можно разработать первый вариант методологии для данного конкретного проекта, в частности, описать те моменты, которые относятся к составу команды разработчиков, стандартам, рабочим продуктам и контрольным точкам разработки. Не нужно включать сюда описания конкретных методологических техник, потому что они слишком объемны - на одном дыхании их не напишешь (и не прочтешь). Все, что вам нужно поначалу сделать, это дать ответы на следующие вопросы: Насколько продолжительными должны быть итерации и инкременты? Какие проверки и пересмотры делать? Где находятся рабочие места? Какие рабочие продукты необходимо создавать и поддерживать? Какие стандарты соблюдать необходимо, а какие рекомендуется (инструменты, диаграммы, тесты и код)? Как будет выглядеть отчетность по затраченному времени? Что можно сделать, чтобы поддержать общение и боевой дух в команде? Очень важно обсудить этот первый вариант методологии с самой командой разработчиков и с руководством и прийти к некоему компромиссному варианту. Все это занимает от двух до пяти дней, причем в результате процесс будет уже "настроен" для данной организации и работающих в ней людей. Первый инкремент Приблизительно в середине первого инкремента проведите повторный опрос команды (задайте им все те же вопросы - индивидуально каждому или всем вместе, в зависимости от размеров компании и физической удаленности сотрудников). Главный вопрос, на который вам нужно получить ответ, это "Сможем ли мы сделать работу, если будем работать так, как сейчас?" Как правило, в середине первого инкремента люди жалуются на недостаток общения, нестабильные требования и задают вопросы относительно стандартов. Теперь внесите в свои методологические выкладки те предложения, воплотить которые совсем несложно, или же те, которые просто нельзя проигнорировать. Остальную "доводку" оставьте на потом. Время, которое вам на это понадобится: от одного до трех часов. После каждого инкремента После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?" Скорее всего, вы получите комментарии, касающиеся всех областей работы над проектом - от жалоб на вмешательство начальства, до вопросов контроля времени, общения, расположения рабочих мест, пересмотра и анализа проекта и состава команды в целом. Как и при обсуждении первого варианта методологии, предложения, высказанные на собрании, выносятся на суд команды разработчиков и руководителей (если это необходимо), после чего получают статус новых установок по работе над проектом. На все это может уйти от четырех до двенадцати часов. Некоторые команды занимаются подобной деятельностью в рабочее время. Что касается разработчиков проекта "Insman", то они предпочитали делать это где-нибудь в другом месте, в спокойной, расслабленной обстановке, чтобы сочетать аналитическую деятельность с улучшением взаимоотношений в команде и проработкой планов на следующий инкремент. Следующие инкременты Последующие методологические "настройки" в середине инкремента можно опустить, но только если его длительность не превышает трех недель. Главный вопрос, на который надо ответить во время таких "внутриинкрементных" аналитических сессий, это "Все ли работает так, как надо?" Иногда у команды появляется новая идея на втором или третьем инкременте, и ее нужно опробовать. Может быть, эта идея не сработает, и тогда у команды должна быть возможность вернуться к предыдущему варианту методологии или же опробовать следующую идею. Проект "Winifred" трижды менял структуру команды во время третьего инкремента [С3]. Разработчики решили, что структура команды, использовавшаяся во время первого и второго инкремента, им не подходит. Впрочем, первые два предложения по новой структуре тоже оказались ошибочными. Третий вариант всех устроил. Его и использовали до конца проекта. Чаще всего во время аналитических обзоров методологии, которые проводятся в середине инкремента, вы будете слышать замечания относительно изменений стандартов создания и пересмотра кода, структуры команды и неформальных коммуникаций. Что касается времени, вам понадобится от двух до шести часов, в зависимости от объема требуемых изменений. В результате двойного пересмотра методологии в течение каждого инкремента, команда получает возможность использовать для ее разработки самые свежие свои достижения и идеи. Таким образом, во время работы над проектом разработчики используют методологию, специально сформированную для той ситуации, в которой они находятся. |