Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2007 г.

Групповая разработка и организация коллектива
Лекция из курса «Введение в технологию программирования»

Терехов Андрей Николаевич, Интернет-Университет Информационных Технологий, INTUIT.ru

Назад Оглавление Вперёд

Организация коллектива разработчиков в компании Microsoft

Относиться к компании Microsoft можно по-разному – слишком агрессивны, чрезмерное стремление к монополизму, программы огромны и неэффективны, документация часто непонятна и, опять-таки, очень объемна. Тем не менее, абсолютное большинство пользователей работает именно на продуктах этой компании, Microsoft поддерживает университеты по всему миру, да и со своим бесконечным ПО успешно справляется. Поэтому в лекциях по технологии программирования мы не можем пропустить опыт Microsoft в этой области[12].

Служба Microsoft Consulting Services провела анализ результатов выполнения большого количества программных проектов. Оказалось, что только 24% проектов можно признать в той или иной степени успешными, 26% не были завершены, а остальные столкнулись с большими проблемами, например, бюджет был превышен вдвое или затрачено в 1,5 раза больше времени.

Основными причинами неудач были признаны следующие:

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

Для преодоления этих трудностей был предложен набор моделей Мicrosoft Solution Framework (MSF), в котором учтен опыт, накопленный группами разработки программных продуктов.

Самыми революционными оказались модель команды разработчиков и модель процесса разработки. Первая модель (team model) описывает, как должны быть организованы коллективы и какими принципами им надо руководствоваться для достижения успеха в разработке программ. Разные коллективы могут по-своему применять на практике различные элементы этой модели – все зависит от масштаба проекта, размера коллектива и квалификации его участников.

Формирование коллектива – сложная задача, которая должна решаться с помощью психологов. Вот некоторые основные положения:

  • не должно быть команды из одних лидеров;
  • не должно быть команды из одних исполнителей;
  • в случае неудачи команда расформировывается;
  • система штрафов (если проект проваливается – наказывают всех).

Этот "бублик" описывает только роли, за ними могут скрываться несколько человек, исполняющих каждую роль. Самое удивительное, что в этой модели не предусмотрено единоначалия – все роли важны, все роли равноправны, поэтому MSF называют моделью равных (team of peers).

Program management – управление программой. Исполнитель этой роли отвечает за организацию (но не руководит!): осуществляет ведение графика работ, утренние 15-минутные совещания, обеспечивает соответствие стандартам и спецификациям, фиксацию нарушений, написание технической документации.

Product management – управление продуктом. Исполнители этой роли отвечают за общение с заказчиком, написание спецификации, разъяснение задач разработчикам.

Development – наиболее традиционная роль – разработка и начальное тестирование продукта.

User education – обучение пользователей. Написание пользовательской документации, обучающих курсов, повышение эффективности работы пользователей.

Logistic management – установка, сопровождение и техническая поддержка продукта, а также материально-техническое обеспечение работы коллектива.

Testing – тестирование. Выявление и устранение недоработок, исправление ошибок, другие функции QA.

Все решения принимаются коллективно, разделяется и ответственность в случае провала проекта.

В MSF утверждается, что такую модель можно масштабировать, разбивая систему по функциям. Лично у меня это утверждение (как и коллективная ответственность) вызывает большие сомнения.

Модель процесса определяет, когда и какие работы должны быть выполнены.

Назад Оглавление Вперёд

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (9)
Среда 22.11, 19:04
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...