Ролевая модель команды

Программная инженерия. Лекция 4 РОЛЕВАЯ МОДЕЛЬ КОМАНДЫ Состав команды определяется опытом и уровнем коллектива, особенностями проекта, применяемыми технологиями и уровнем этих технологий. В малых командах роли могут совмещаться. В больших – выделяться группы или отделы (отдел проектирования, отдел тестирования, отдел контроля качества, отдел подготовки документации и т.д.). Состав команды определяется также типом выполняемых работ: под заказ или коробочное производство (продукт на рынок). Инженерный психолог и инженер по маркетингу нужны в последнем случае. В представленной модели выделены следующие основные роли: • Менеджер проекта - главное действующее лицо, обладающее знаниями и навыками, необходимыми для успешного управления проектом. Его основные функции: ✓ Подбор и управление кадрами ✓ Подготовка и исполнение плана проекта ✓ Руководство командой ✓ Обеспечение связи между подразделениями ✓ Обеспечение готовности продукта • Проектировщик - это функция проектирования архитектуры высокого уровня и контроля ее выполнения. В небольших командах функция распределяется между менеджером и разработчиками. В больших проектах это может быть целый отдел. Основными функциями проектирования являются: ✓ Анализ требований ✓ Разработка архитектуры и основных интерфейсов ✓ Участие в планировании проекта ✓ Контроль выполнения проекта ✓ Участие в подборе кадров • Разработчик – роль, ответственная за непосредственное создание конечного продукта. Помимо собственно программирования (кодирования) в его функции входит: ✓ Контроль архитектурных и технических спецификаций продукта ✓ Подбор технологических инструментов и стандартов ✓ Диагностика и разрешение всех технических проблем ✓ Контроль за работой разработчиков документации, тестирования, технологов ✓ Мониторинг состояния продукта (ведение списка обнаруженных ошибок) ✓ Подбор инструментов разработки, метрик и стандартов. Контроль их использования. • Тестировщик – роль, ответственная за удовлетворение требований к продукту (функциональных и нефункциональных). В функции тестировщика входит: ✓ Составление плана тестирования. План тестирования составляет один из элементов проекта и составляется до начала реализации (разработки) проекта. Время, отводимое в плане на тестирование может быть сопоставимо с временем разработки. ✓ Контроль выполнения плана. Важнейшая функция контроля – поддержка целостности базы данных зарегистрированных ошибок. В этой базе регистрируется: – кто, когда и где обнаружил, описание ошибки, описание состояния среды; – статус ошибки: приоритет, кто разрешает – состояние ошибки: висит, в разработке, разрешена, проблемы Эта база должна быть доступна всем, т.к. в тестировании принимают участие все члены команды. ✓ Разработка тестов. Самая трудоемкая часть в работе тестировщика. Тестирование должно обеспечить полную проверку функциональности при всех режимах работы продукта. ✓ Автоматизация тестирования включает автоматизацию составления тестов, автоматизацию пропуска тестов и автоматизацию обработки результатов тестирования. В виду важности автоматизации тестирования, иногда вводят нового участника – инженера по автоматизации. ✓ Выбор инструментов, метрик, стандартов для организации процесса тестирования. ✓ Организация Бета тестирования - тестирования почти готового продукта внешними тестерами (пользователями). Эту важную процедуру надо продумать и организовать в случае разработки коробочного продукта. • Инженер по качеству. В современном представлении рассматривается три аспекта (уровня) качества: – качество конечного продукта – обеспечивается тестированием, – качество процесса разработки (тезис: для повышения качества продукта надо повысит качество процесса разработки), – качество (уровень) организации (тезис: для повышения качества процесса надо повысить качество организации работ). В некоторых случаях функции инженера по качеству возлагаются на тестировщика. На самом деле они шире – два следующих уровня качества. Здесь приведены функции, отличные от функции тестировщика: ✓ Составление плана качества. План качества включает все мероприятия по повышению качества (на всех уровнях). Имеет долговременный характер. План тестирования – его оперативная составляющая. ✓ Описание процессов. Описание процессов является их формализацией. При описании вводятся метрики процесса, влияющие на качество продукта. ✓ Оценка процессов включает регистрацию хода выполнения процессов и оценку значений установленных метрик процессов. Выявление «слабых» мест и выработка рекомендаций по улучшению процессов. ✓ Улучшение процессов - переопределение процесса, автоматизация части работ, обучение персонала. Повышение качества процессов требует участия всех действующих лиц. Принятое решение должно быть обосновано, всем понятно и всеми принято. При повышении качества организации работа по улучшению процессов проводится по определенной схеме. На каждом шаге повышения уровня организации работ выделяются ключевые процессы и выполняются работы по улучшению этих процессов. • Технический писатель или разработчик пользовательской (и иной) документации как части программного продукта. Функциями технического писателя являются: ✓ Разработка плана документирования, который включает состав, сроки подготовки и порядок тестирования документов. ✓ Выбор и разработка стандартов и шаблонов подготовки документов ✓ Выбор средств автоматизации документирования ✓ Разработка документации ✓ Организация тестирования документацииУчастие в тестировании продукта. Технический писатель все время работает с продуктом (его готовыми версиями) и выступая от имени пользователя видит все недочеты и несоответствия. • Технолог разработки ПО обеспечивает выполнение следующих задач: ✓ Поддержка модели ЖЦ - создание служб и структур по поддержке работоспособности принятой модели ЖЦ ПО. В поддержке модели ЖЦ принимают участие все. Но контроль возложен на технолога. ✓ Создание и сопровождение среды сборки продукта. Функция особенно важна на завершающих этапах разработки или при использовании модели прототипирования. В такой ситуации сборка будет проводиться достаточно часто (в некоторых случаях ежедневно). Среда сборки должна быть подготовлена заранее, сборка должна проводиться быстро и без сбоев. С учетом сборки версий это не простая задача. ✓ Создание и сопровождение процедуры установки с тем, чтобы каждая сборка устанавливалась автоматически с учетом версии и конфигураций сред. ✓ Управление исходными текстами - сопровождение и администрирование системы управления версиями исходных текстов. Подводя итог, следует отметить, что ролевые модели проектных команд могут быть самыми разнообразными. МОДЕЛИ ОРГАНИЗАЦИИ КОМАНД Peopleware – человеческий фактор Как организовать работу команды? Команды из 10 человек и команды из 500 человек? Есть ли различия и в чем они состоят? Надо ли организовывать работу по жесткой технологии или надо предоставить свободу действий? Можно ли найти методологию (технологию) выполнения проекта, обеспечивающую успех? Алистер Коубен [Д1] – специалист в области технологий выполнения ИТ проектов приводит данные 23 проектов различной степени сложности, выполнявшихся по различным технологиям и имеющие различные результаты. Пытаясь проанализировать результаты применения различных технологий в тех или иных условиях, он приходит к выводу: • Практически любую методологию можно с успехом применять в какомнибудь проекте. • Любая методология может привести к провалу проекта. Главную причину он видит в том, прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Исследованию вопросов человеческого фактора (Peopleware) уделяется достаточно много внимания. Наиболее известными работами являются: • Weinberg, J., The Psychology of Computer Programming, Silver Edition, Dorset House, 1998. • DeMarco, T., Lister, T., Peopleware 2nd Edition, Dorset House, 1999. (Т. ДеМарко, Т.Листер. Человеческий фактор: эффективнын проекты и команды. - Пер. с англ. - СПб: Символ-Плюс, I кв. 2004 г.). • Константин Л. Человеческий фактор в программировании. - Пер. с англ. - СПб: Символ-Плюс, 2004. - 384 с. • и др. Проблемы человеческого фактора связаны с тем (проявляются в том), что участвующие в проекте люди: • Все разные – по характеру, темпераменту, активности, целям – нет двух одинаковых людей. • Все похожие – участие в проекте объединяет людей общностью целей, поиском путей достижения этих целей. • Различаются по типу: ✓ Индивидуалисты - члены команды ✓ Генераторы идей - исполнители ✓ Ответственные – безответственные • Постоянны и изменчивы – люди, как правило, проявляют постоянство своих привычек и свойств характера, но при этом способны проявлять «противоположные» качества: индивидуалист – командные качества, исполнитель – генерировать идеи, … • Многообразны – надо понимать, что многообразие людей является основной гарантией выживания человечества вообще и возможности выполнять ИТ проекты в частности. Если бы все были индивидуалисты или все командники, все генераторы идей или все исполнители, то вряд ли удалось выполнить хотя бы один проект, а мир стал бы ужасен. Как же управлять такими людьми? АДМИНИСТРАТИВНАЯ МОДЕЛЬ (ТЕОРИЯ X) Это традиционный стиль управления, связанный с иерархической административно-командной моделью, которую используют военные организации. В основе лежит теория X, которая утверждает, что такой подход необходим, поскольку большинство людей по своей природе не любит работу и будет стремиться избежать ее, если у них есть такая возможность. Однако менеджеры должны принуждать, контролировать, направлять сотрудников и угрожать им, чтобы получить от них максимальную отдачу. Девиз теории и модели: Люди делают только то, что вы контролируете. Или в более мягком варианте: Люди делают то, что они не хотят делать, только если вы их контролируете В конце концов, теория утверждает, что большинство людей предпочитают, чтобы им говорили, что следует делать и им не придется ничего решать самим. Характерные черты модели: • Властная пирамида – решения принимаются сверху-вниз • Четкое распределение ролей и обязанностей • Четкое распределение ответственности • Следование инструкциям, процедурам, технологиям • Роль менеджера: планирование, контроль, принятие основных решений. Преимущества модели: ясность, простота, прогнозируемость. Модель хорошо сочетается с каскадной моделью жизненного цикла и применима в тех же случаях, что и каскадная модель. Модель эффективна в случае установившегося процесса. Недостатки модели связаны с тем, что административная система стремится самосохранению (стабильности) и плохо восприимчива к изменению ситуации – новые типы проектов, применение новых технологий, оперативная реакция на изменение рынка. Кроме того, в административной модели плохо уживаются индивидуалисты и генераторы идей. Административная система (модель) – это тяжелый паровоз, идущий в «середине» и не поддающийся на «крайности» поиска новых путей и решений. Она воспринимает новые решения и технологии, но только проверенные, отработанные и стандартизированные. В этом ее сила, слабость и проявление принципа многообразия. Видимо, именно к ней в наибольшей степени применим термин «промышленное программирование». МОДЕЛЬ ХАОСА (ТЕОРИЯ Y) В основе модели хаоса лежит Теория Y, которая является полной противоположностью Теории X. Основной тезис Теории Y: работа — естественная и приятная деятельность и большинство людей, на самом деле, очень ответственны и не увиливают от работы. Характерными чертами модели хаоса являются: • Отсутствие явно выраженных признаков власти • Роль менеджера – поставить задачу, обеспечить ресурсами, не мешать и следить, чтобы не мешали другие • Отсутствие инструкций и регламентированных процедур • Индивидуальная инициатива - решения по проблеме принимается там, где проблема обнаружена • Процесс напоминает творческую игру участников на основе дружеской соревновательности Преимущества такой модели в том, что творческая инициатива участников ничем не связана и потенциал участников раскрывается в полной мере. Это бывает особенно эффективно в случае, когда для решения проблемы требуется поиск новых подходов, методов, идей и средств. Команда становится командой «прорыва», а работа проходит в форме игры, цель которой – поиск наилучшего результата. Процесс напоминает случайный поиск, когда идеи и решения рождаются при живом и как бы случайном обсуждении проблем в коридоре, столовой на пикнике. Собрать такую команду в рабочей комнате и устроить обсуждение по регламенту часто просто не удается – это команда творческих индивидуалистов. Недостатки модели связаны с тем, что при определенных условиях команда прорыва может стать командой провала. Причинами провала могут быть: • Творческая соревновательность переходит в конкуренцию сначала идей, а потом - личностей • Процесс начинает преобладать над целью проекта – высказанные идеи не доводятся до конца и сменяются новыми идеями, преобладание получают «красивые» идеи, лежащие в стороне от основных целей проекта. • Люди, способные к генерации идей, редко обладают терпением доведения идей до полной реализации Модель хаоса – это то, что нужно для освоения новых земель. Модель хаоса не противоречит административной модели – она ее дополняет и может эффективно с ней соседствовать (но в разных комнатах!). Многие мускулистые корпоративные бегемоты полагаются на исследовательские «отделы скунсов», откуда они черпают новые идеи, технологии и продукты. ОТКРЫТАЯ АРХИТЕКТУРА (ТЕОРИЯ Z) Административная и хаотическая модели являются двумя «крайностями», между которыми находятся множество моделей, сочетающих преимущества «крайних» моделей. Одной из таких моделей является модель открытой архитектуры, основанная на Теории Z. Эта теория была сформулирована Уильямом Оучи на основе изучения опыта японского стиля управления (Theory Z: How American Business Can Meet the Japanese Challenge,» Perseus Publishing, 1981). Теория Z предполагает (но не декларирует) наличие внутреннего механизма управления, основанного на влиянии со стороны коллег и группы в целом. Дополнительное воздействие оказывают культурные нормы конкретной корпорации. Основной принцип модели можно сформулировать так: «Работаем спокойно. Работаем вместе». Особенностями этой модели являются: • Адаптация к условиям работы – если делаем независимые модули, то расходимся и делаем, если нужна архитектура базы данных, то собираемся вместе и обсуждаем идеи. • Коллективное обсуждение проблем, выработка консенсуса и принятие решения – не все могут согласится, но принятое решение является коллективным и в силу этого – обязательным для всех. • Распределенная ответственность – отвечают все, кто обсуждал, вырабатывал, принимал. • Динамика состава рабочих групп в зависимости от текущих задач. • Отсутствие специализации – участники меняются ролями и функциями и могут при необходимости заменить друг друга. • Задача менеджера – активное (но рядовое, не руководящее) участие в процессе, контроль конструктивности обсуждений, обеспечение возможности активного участия всех. Открытая архитектура является более гибкой, адаптируемой, настраиваемой на ситуацию. Она дает возможность проявить себя всем членам команды – в ней могут уживаться и индивидуалисты и коллективисты. Коллективное обсуждение высказанных идей позволяет оставлять только прагматичные идеи. Общение в команде Коммуникации Основным фактором в разработке программного обеспечения является возможность коммуникации (общения участников проекта). Общение может проводиться в различных формах от строго формализованного (стандартизированная документация) до полностью неформализованного (вопрос-ответ соседу, обсуждение в неформальной обстановке). На рисунке [Д1] изображена некая кривая, иллюстрирующая эффективность различных способов общения. Кривая является обобщением ряда исследований в этой области. Видно, что эффективность общения падает по мере возрастания степени его формализованности. С одной стороны, в этом нет ничего удивительного – старый принцип бюрократа гласит: хочешь получить отказ – пиши письмо, хочешь получить обещание – звони по телефону, хочешь добиться результата – езжай сам. Но с другой стороны, надо помнить, что коммуникации в команде определяются количеством участников (рабочих связей): при двух участниках – это одна связь, при n участниках – n(n-2)/2. При этом, любая из этих связей может давать сбои и они не транзитивны: из того, что участник А хорошо контактирует с Б, а Б – с В вовсе не следует, что А контактирует с В. Т.е. неформальное, «живое» общение эффективно только в относительно небольших, хорошо организованных (сработавшихся) коллективах. Принятие решений – компромисс и консенсус Целью общения в команде разработчиков являются обсуждение текущих проблем и вопросов и принятие решений. Далее мы рассмотрим некоторые проблемы организации обсуждений и принятия решений. Начнем с принятия решений. Итак, принятое в результате обсуждения решение может быть достигнуто в результате компромисса или в результате консенсуса. В чем разница этих результатов? Начнем с определений (Глоссарий.ру): Компромисс - соглашение, достигнутое посредством взаимных уступок. Консенсус (коллективное мнение) - общее для конкретной группы мнение В чем же разница? Компромисс: • Это среднее решение, которое может оказаться (и, как правило, оказывается) хуже каждого из вариантов • Достигается путем взаимных уступок (мы согласимся с вашим вариантом интерфейса, если вы согласитесь с нашей организацией базы данных) • Может быть принят большинством (голосованием) Консенсус: • Это оптимальное решение, сочетающее лучшее из предложенных вариантов • Достигается путем обсуждения, анализа и генерации новых идей • Принимается общим согласием (все согласны, что найдено лучшее решение) Л. Константин [О3] приводит следующий пример компромисса и консенсуса. При обсуждении вопроса о размещении кнопок панели инструментов выдвинуты два варианта: горизонтально и вертикально. Компромисс – по диагонали (нелепое решение). Консенсус – настраиваемая пользователем панель (лучшее решение, включающее оба варианта на основе новой идеи – настраиваемая панель). Как добиться консенсуса? В отличие от компромисса, который чаще всего достигается в результате политических интриг и подковерных баталий, достижение консенсуса требует конструктивного и плодотворного напряжения всей команды и особого искусства управления командой. При этом рекомендуется придерживаться следующих принципов и правил: • Вера в достижение консенсуса – каждый член команды должен доверять другим в том, что обсуждение приведет к поиску оптимального решения, а не к борьбе личностных мнений. Создание такой атмосферы взаимного доверия является важнейшим в создании эффективной команды. Следует понимать, что взаимное доверие появляется не само по себе, а является результатом: ✓ Нескольких удачных консенсусов ✓ Участием всех в выработке и принятии оптимальных решений ✓ Созданием у каждого осознания причастности к принятым решениям • Не позиция, а варианты решений – на обсуждение люди должны приходить не со сформированной позицией (ни шагу назад), а с вариантами возможных решений • Объективность принимаемых решений как попытка ограничить проявления чувств и эмоций при обсуждении вопросов. Чувства и эмоции являются неотъемлемым свойством человеческой природы. Избежать их полностью вряд ли удастся, но для приведения их «в норму» можно использовать следующие правила: ✓ Критерии оценки вариантов – для объективности обсуждения крайне важно заранее договориться о критериях оценки – установить список критериев и выполнить их ранжировку по степени важности. ✓ Разделение фактов и мнений. Факты – объективные показатели, выраженные в большинстве случаев количественно (но не обязательно): быстродействие, время отклика. Мнения – то, что не основано на фактах. Мнениями не следует пренебрегать, т.к. они часто основаны на опыте, интуиции. • Замена позиций – в случае, когда обсуждение все же заходит в тупик, бывает полезно предложить участникам изменить точку зрения: «перечислите, пожалуйста, сильные стороны варианта Вашего оппонента и слабые стороны Вашего варианта» • Слегка управляя - роль руководителя в достижении консенсуса состоит в том, чтобы дать всем возможность высказаться и предложить свои варианты, оставляя свое мнение напоследок или не высказывать его совсем. Руководитель должен быть нейтрален. Руководитель (лидер) может принимать активное участие в обсуждении, но только на правах равного и поручить в этом случае руководство собранием другому человеку.