На мой взгяд бесспорным лидером производства ПО является компания Microsoft, с каждым годом становится все меньше и меньше бизнес доменов, где бы Microsoft не выпускала свой продукт. Поэтому полезно знать, а как же ведутся проекты в этой компании.

Предлагаю список метериалов, которые мне удалось найти по MSF:

Microsoft Solutions Framework – официальный сайт MSF 4.0
Управление проектами: технология MSF – русский перевод MSF 3.0
Введение в методологию Microsoft Solutions Framework – статья из журнала BYTE

Six Sigma это методология для улучшения качества производства . Разработана компанией Motorola в начале 1980х, и успешно применяется во многих софтверных компаниях. Цель Six Sigma производить продукт постоянного качества со статистически измеренной оценкой дефектов, улучшение процесса для устранения дефектов, и мониторинг этих улучшений. Six Sigma успешно применяется, для улучшения организаций различных индустрий. В то время как она имеет успешную репутацию в больших компаниях с тысячами сотрудников, Six Sigma также можно применить в маленьких проектных командах.

Основу методологии Six Sigma составляет оценка отклонений фактических показателей процесса от кривой нормального распределения отклонений. Если те или иные показатели процесса находятся в определенных пределах отклонений, качество результатов процесса также остается высоким. Единицу измерения отклонений в статистике принято называть “сигмой”. Заметный эффект наблюдается при отклонении не более 4,5 сигма; в этом случае показатель числа дефектов на миллион единиц продукции составляет 3,4. Но это условие выполняется для стабильных процессов. Производственные процессы не отличаются стабильностью. Изобретатели методологии пришли к выводу, что отклонения процесса, вызванные его естественной нестабильностью, дают отклонения качества на уровне 1,5 сигма. Таким образом, если целевой уровень качества составляет 4,5 сигма, то с учетом 1,5 сигма на отклонения необходимо обеспечивать уровень качества в 6 сигма.” Чтоб достигнуть такого уровня качества в производственном процессе, 99.9997% от общего числа продуктов должны быть приемлемого качества (или 3.4 дефектов на миллион возможных).

Отклонение это важная часть Six Sigma. Вот что сказал General Electric, один из пионеров и новаторов методологии: “Наши клиенты чувствуют Отклонение, а не Среднее” Все процессы имеют некоторое наследованное отклонение. Нет процессов, особенно нет софтверных процессов, которые порождают дефекты с постоянным коэффициентом. Вот где Six Sigma особенно эффективна.

Цель Six Sigma это думать о каждом аспекте бизнеса как о процессе который можно улучшить и это можно измерить статистически. Основной инструмент это подход состоящий из 5 этапов называемый DMAIC (define, measure, analyze, improve, control).

DMAIC: 5 фазовый подход Six Sigma

1. Определение возможностей. (Define opportunities)

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

2. Измерение производительности (Measure performance)

Разработка плана по сбору и измерению данных о дефектах. Сбор данных из различных источников организации и определение уровня дефектов и других метрик. Обработка и отображение данных.

3. Анализ возможностей (Analyze opportunity)

Анализ и проверка собранных данных. Определение причин появления дефектов и рассмотрение возможностей для улучшения. Расстановка приоритетов для возможных улучшений.

4.Улучшение производительности (Improve performance)

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

5. Контроль производительности (Control performance)

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

Роли

Еще одним важным моментом реализации проекта Six Sigma является распределение ролей среди специалистов. Должны быть назначены “исполнители” на следующие ключевые роли.

“Лидер” (Champion)

Член высшего руководства предприятия, который, собственно, и должен принять решение о запуске проекта Six Sigma и затем обеспечивать его реализацию, устраняя все возможные препятствия и предоставляя требуемые ресурс

“Черный пояс” (Black Belt)

Методология Six Sigma имеет свою систему обучения и сертификации называемой программа Черного Пояса (Black Belt). Сертифицированный специалист Six Sigma Black Belt это професиионал прошедший обучение на внедрение Six Sigma в организации, также является инструктором который обучает принципам, сиситеме и инструментам Six Sigma. Он имеет доскональное понимание модели DMAIC и фундаментальным знаниям управления проектами.

Проектная группа

Проводит конкретную работу по внедрениюю В нее входят специалисты в тех областях, которые затрагиваются в рамках проекта Six Sigma, прошедшие обучение основам методологии. Они предоставляют необходимую поддержку в ходе реализации проекта и делятся своими знаниями.

Преимущества и недостатки.

Первым и наиболее очевидным преимуществом методологии Six Sigma является повышение рентабельности за счет сокращения прямых затрат. Благодаря участию в проектах Six Sigma квалифицированных и хорошо обученных специалистов это сокращение может быть весьма значительным.

Six Sigma позволяет добиваться полной удовлетворенности клиентов. И все же этого недостаточно. Компании могут рассчитывать на успех в длительной перспективе, только если смогут удивлять своих клиентов новаторскими предложениями. Более того, компании должны непрерывно совершенствовать свою деятельность. Повышенное внимание, уделяемое в методологии Six Sigma жесткости процесса, его соответствию установленным нормам, противоречит новаторству, которое, по существу, является отклонением от нормы. Инновационный подход означает отклонения в производственном процессе, избыточность, необычные решения, недостаточную проработку – все то, с чем борется Six Sigma. Об этом придется помнить руководителям, решившим внедрить эту методологию.

Есть и еще одно, весьма существенное именно для руководителей обстоятельство, о котором необходимо помнить. Six Sigma – не просто модификация старых технологических методов обеспечения качества; это принципиально новый подход к руководству предприятием. Руководители Motorola расширили идею гарантии качества далеко за рамки собственно производства. Six Sigma превратилась в способ организации труда на всем предприятии.

Эксперты не склонны противопоставлять Six Sigma и ISO 9001. Ряд специалистов рассматривает метод “Six Sigma” просто как один из статистических методов анализа и измерения качества, который можно использовать в качестве одного из возможных при внедрении ISO 9001. Этот стандарт качества предписывает обязательное применение статистических методов на производственных

Источники дополнительной информации:

iSixSigma (http://www.isixsigma.com)
Motorola University (http://www.motorola.com/motorolauniversity).
SixSigma в Росии (http://www.six-sigma.ru/ )
SixSigma в США (http://www.6sigma.us/)
Материалы по СМК (http://quality.eup.ru/index.php)

На вопрос как команды должны создавать ПО, можно получить десятки разных ответов. Но то что подходит одним командам может не подойти другим. Многие эксперты видят все в черно-белом свете: плохи те команды разработчиков которые не используют процессы и хороши те у которых процессы поставлены. Но не все в этом мире так просто. Прежде чем начать применять процессный подход, нужно понять что это принесет и почему процессы столь важны организации.

Команды могут быть эффективными и без формальных процессов

Существует много успешных команд которые не тратят время на постановку процессов. Во многих таких организациях отдельные программисты или небольшие команды ответственны за целый проект они общаются как с пользователями так и с организаторами проекта чтобы понять их требования к ПО, они же создают и поставляют ПО конечным пользователям.
Люда в такой ситуации вынуждены быть “на все руки мастерами” и делать все самим, от сбора требований до дизайна и разработки, тестирования и установки. Это эффективный путь создавать продукт: ограничивая количество вовлечённых людей и делая каждого ответственным за целый проект, требуется меньше документации и коммуникаций, меньшие издержки и сложность для проекта.

В дополнение к ситуации «на все руки мастер»-а программисты берут на себя инициативу и создают функциональность которая не является обязательной, но о которой попросили некоторые пользователи или клиент. Это происходит когда программист знает о нуждах пользователей и знает рутинные задачи которые можно автоматизировать. Когда такого рода изменения приводят пользователей в состояние счастья, программиста начинают признавать как гения, он пишет софт полезный людям и организации, который не требует работы с их стороны. Такой прекрасный вид работ для программиста, без давления сверху, определённых ожиданий пользователей, и высоко ценимый.

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

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

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

Интересно заметить что команды которые не имеют формального процесса как правило довольны ситуацией!

Команды производящие успешный софтверный продукт гордятся своими успехами. Известность и широкое признание означает что программисты высоко уважаемы в организации. Уважаемы за исключением случаем когда проекты проваливаются.

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

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

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

Эта проблема появляется когда знания необходимые для определения нужного поведения ПО не существует в организации. Программисты знают как программировать, но они не знакомы с ежедневными проблемами людей в бизнес которых они теперь вовлечены. Так в один день «мастер на все руки» находит себя на зыбкой почве. Он провел много времени изучая нужды небольшой группы людей и если новый проект требует понимания совершенно других отраслей, другого бизнеса, ему уже необходимо достаточно много времени чтобы изучить тонкости новой сферы.

Source: Applied Software Project Management, By Jennifer Greene, Andrew Stellman