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

Реальность такова:

1) Заказчик всегда хочет знать, во сколько ему обойдется проект до начала проекта. Если он не хочет этого знать, то он делает проект не за свои деньги, и вряд ли имеет финансовый интерес.

2) Редкий заказчик умеет адекватно ставить задачи и приоритеты, поэтому, скорее всего, придется это делать вам самим.

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

5) ЮнитТесты как правило удорожают проект, что не всегда оправдано.

6) Отсутствие документации по проекту это всегда недостаток, а не достоинство.

7) Постоянная доступность заказчика возможна в редких проектах, даже если заказчик доступен, хватает ли у него квалификации отвечать на вопросы, достаточно ли он компетентен в своей же области?

8) Парное программирование это круто? — если бы это было так, однажды попробовав, все бы писали в парах.

Уверен, что есть люди, опыт которых опровергает данные утверждения. Буду рад любым аргументированным комментариям.

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

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

Скрум собрание: Детали

Скрум собрания это пульс Скрума и проекта. Каждый рабочий день, в одном и том же месте и время, проводиться собрание с членами команды по кругу, на котором одни и теже специальные Скрум вопросы, на которые отвечает каждый из команды:

1. Что ты сделал со времени последнего Скрума?
2. Что ты будешь делать начиная с текущего момента до следующего Скрума?
3. Что происходит на пути к достижению целей итерации?
4. Есть ли задания для добавления в спринт резерв? (пропущеные задания, не новые требования)
5. Изучил или решил что нибудь новое, важное для кого нибудь из команды? (технические детали, требования, …)

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

Другие важные моменты:

• Собрание идеально проводить стоя в кругу, чтобы показать его краткость.
• В среднем, 15 или 20 минут для 7-10 человек. Более длинные собрания бывают в начале итерации.
• Не члены команды (цыплята) стоят за кругом.
• Он происходит около доски на которой написанны и докладываются все проблемные блоки. Скрум Мастер только стирает блок как только он разрешился.
• Должен быть спикерфон для участия офсайт людей—это обязательно.
• Скрум Матстер следит чтобы все шло по правилам, и готовит место для эффективного собрания.
• Должен начинатся во время. 
• Применяется правило Цыплят и Свиней: Не члены команды не говорят и не задают вопросов.
• Не допускается других дисскусий между 3 (или5) вопросом. Скрум Мастер обладает власью сменить фокус дисскусии.
• Если другие проблемы требуют обсуждения, происходит второе собрание сразу после Скрум собрания, обычно с частью команды. Например во время собрания я могу сказать Джо во время его отчета, “Мы должны поговорить об этом, давай встретимся после Скрума.”

Ценность Скрум собрания

1: Так как мы имеем, на время итерации, самоорганизующуюся команду, без менеджера, направляющего работников или решающего проблемы (пока не попросят), Скрум митинг создает ежедневный механизм, для быстрого информирования команды о состоянии проекта и людей. Затем люди могут действовать. Внешние люди могут присутсвовать на ежедневном Скруме для получения точного, временного и богатого информацией измерения прогресса и проблем. Это поддерживает активность.
2: Когда человек говорит, что он делает на следующий день, он дает в в некотором виде обещание команде. Это увеличивает ответсвенность и доведение дел до конца.
3: Скрум основывается на понимании, что разработка ПО это креативный и непредсказуемый процесс, и необходимы скорее эмпирические чем предопределенные методы. Скрум собрание обеспечивает часто измеримый и адаптивный механизм отклика, что и требуют методики основанные на опыте.
4: Риски проекта включают в себя учет не всех заданий, плохие прогнозы, и медленное разрешение проблем. Скрум митинг обеспечивает ежедневный обсуждение обновлений заданий, определение и удаление помех.
5: Постоянное улучшение и изучение людей и команд очень важно. Скрум митинг помогает в этом, особенное добавление 5-го вопроса. Невысказанная (или подразумеваемая) информация и знания становятся высказанной и общей.
6: Общий язык, ценности и практики помогают команде разработчиков. Это создается и укрепляется ежедневным скрумом.

Скрум также допускает комбинацию с другимим методологиями, например с унифицированными процессами (UP). Он допускает создание видения проетка (vision) или списка рисков.

Другие практики и ценности

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

Общие ошибки и недопонимания или как завалить Скрум проект

Не самонаправляемые команды; менеджер или Скрум Мастер направляет или организовывает команду— У менеджеров часто возникает желание приставать к команде, во время итерации, с советами как работать, как решать проблемы. Многие менеджеры делают упор на задании направления и планировании, чем на их роли в Скрум: быстро решать проблемы, обеспечивать ресурсами, буть фильтром между командой и компанией, но однако не стоять на пути. Это особенно справедливо для Скрум Мастера во время скрум митинга, когда естественная тенденция, чтобы выглядить лидером для команды определяющим направления и решения.
Не ежедневное обновление Спринт резерва разработчиками.
Новая работа добавляется к итерации или индивидуму—В море постоянных изменений требуется некоторая стабильность. Не изменять требования для однажды начатой итерации, это точка контроля Скрума.
Владелец продукта не вовлечен или не принимает решений—Скрум это мотодология управляемая заказчиком. Владелец продукта должен решить как приотизоровать бэклог продукта, и выбрать требования для следующей итерации.
Нет Спринт оценки (review)—Скрум строится на обратной связи и адаптации; демонстрация и оценка(review) необходима, чтобы проинформировать заказчика, чтобы он мог откоректировать следующую итерацию.
Много хозяев—Скрум требует один голос для требований из резерва свойств продукта, расставление приоритетов и выбор работ для следующей итерации обязанности владелца продукта.
Проектирование и создание диаграмм— Скрум более прогматичный в вопрсое командного подхода к проектированию: Если команда находит полезным некоторое пред-программное проектирование или создание диаграмм, во время итерации, они это делают
Вся команда (включая заказчиков и менеджмент) обрезают Скрум методологию и ее ценноости – что недопустимо.
Скрум собрание слишком длинное или не сфокусированно – Держите его в рамках 20 минут, и в рамках Скрум вопросов.
Каждая итерация заканчивается выпуском продукта в жизнь (production)—Хотя Скрум итерация может заканчиватся выпуском в жизнь (production release), это не требование. Это может потребовать несколько итераций перед выпуском ПО готового для исспользования пользователями.
Будущее планирование; планирование Перт диаграммами—Это неправильное понимание, создавать планы описывающие в точности, как много будет итераций для длинного проекта, и что будет происходить в каждой, или создавать Перт диаграммы показывающими много заданий, их порядок и предпологаемую длительность.

Вы не понимаете Скрум если…

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

“Agile and Iterative Development: A Manager’s Guide” – Craig Larman

Ссылки по теме:
http://en.wikipedia.org/wiki/SCRUM – Скрум в википедия.
http://scrumwiki.org/ – вики для Скрума
http://www.scrumalliance.org/ – Скрум альянс
http://www.controlchaos.com/ – сайт одного из создателей скрума Кена Швабера
http://groups.yahoo.com/group/scrumdevelopment/message/2116 – Tools, Tools, Scrum Tools!

Глоссарий

Предопределенный процесс (Defined process)
Предопределенный процесс ведущий к получению предсказуемого результата.

Эмпирический процесс (Empirical process)
Частая проверка и адаптация деятельности, чтобы удовлетворить желаемым результатам.

Итеративная разработка (Iterative development)
Разработка ПО которая представляет собой короткие и повторяемые циклы, с обратной связью от заказчика после каждой итерации.

Скрум Мастер (Scrum Master)
Менеджер проекта

Свинья (Pig)
Явный член проекта.

Цыпленок (Chicken)
Внешний наблюдатель Скрум проекта.

Спринт (Sprint)
30 дневная итерация с заранее определенным набором функциональности.
Результат Спринта это рабочее и демонстрируемое ПО.

Резерв свойств продукта (Product Backlog)
Репозитарий функционала ПО

Резерв свойств Спринта (Sprint backlog)
Функционал и требования в границах Спринта

Активность Зонта (Umbrella activity)
Администратиывные задания, которые не относятся на прямую к текущему программному продукту.

История

Корни Скрума произростают из статьи суммирующей общие лучшие практики в 10 инновационных японских компаниях, “The New New Product Development Game,” Harvard Business Review, январь 1986, написанной Такеши (Takeuchi) и Нонака (Nonaka). Они ввели термин Sashimi (slices) для IID (итеративной инкрементной разработки), и Скрум (Scrum) для адаптивных и само направляемых командных практик.

Название было взято из игры регби, из-за командного поведения передвигающего по полю мяч. Джеф Сазерленд (Jeff Sutherland) один из создателей Скрума и бывший вице-президентом в Easel Corp., в 1994-ом он представил свои методы, под влиянием отчета о гипер-продуктивных проектах в Borland Corp, которые эффективно использовали структурированные ежедневные митинги В 1996 Сазерленд перешел в Individual Inc., и попросил Кена Швабера (Ken Schwaber) помочь в адаптации идей Скрума. Швабер и Сазерленд отшлифовали и расширили Скрум.

Scrum – с англ. драка за мяч (в регби)

Введение

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

Ключевая тема Скрума – это сделать акцент на эмпирическом, а не на преопределенном процессе; т.е. на адаптивном подходе управляемым частой обратной связью, чем следавать набору предсказуемых и определенных задач, чья длительность и порядок может быть определен только на частично.

Основные характиристики:

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

Роли

Заказчик

Владелец продукта (Product Owner)

• один человек кто отвечает за создание и расстановку приоритетов в “Резерве свойств продукта”
• выбирает цели (из “Резерве свойств продукта”) для следующего Спринта
• совместно с другими заинтересованными лицами проверяет систему в конце каждого Спринта

Разработка

Скрум Команда (Scrum Team)

• работает над “Резервом свойств Спринта”
• нет других явных позиций кроме «член команды «

Управление

Скрум Мастер (Scrum Master)

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

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

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

Открытость—Открыто доступный “резерв свойств продукта” делает видимым объем работ и приоритеты. Ежедневные Скрумы делают видимым общий и индивидуальный вклад и состояние дел. Рабочий курс (Work trend) и скорость становиться видимым при помощи графика резерва свойств.

Уважение—Командная ответсвенность предпочтительее козлов отпущения. Отдельные члены команды отвечают за различные сильные и слабые стороны, но нет отвественного за провал итерации. Целая команда, а не менеджер, бросает свои силы, для решения “индивидуальных” проблем в группе, а также команда обладает властью и ресурсами реагировать на трудности, например нанимать консультанта-специалиста чтобы компенсировать отсутсвие экспертов.

Смелость—Руководство должно иметь смелость планировать и руководить, адаптируясь и доверяя индивидуалам и команде избегая говорить им что делать, чтобы итерация была сделана. Команда должна имеет смелость взять на себя ответсвенность, для самонаправления и самоуправления.

Основные практики

Спринт (Sprint)

Работа организовывается итерациями по 30 календарных дней, каждая из которых называется Спринт.

Самонаправляющиеся и самоорганизующиеся команды

Во время итерации, руководство и Скрум Мастер не направляют команду как выполнить цели итерации, не решают их проблем (кроме как принять решение когда запросить и удалить выполненный блок), не планируют и сортируют работу. Команда наделена правами, властью и ресурсами в поисках своего пути, и решении собственных проблем. Подход “руки прочь” на 30 дней, за исключением обеспечения ресурсами и удаления блоков, это возможно наиболее трудный аспект для руководителей адоптирующих Скрум.

Скрум собрание (Scrum Meeting)

Каждый рабочий день в одно и то же время на одном и том-же месте, собирается собрание членов команды, на котором даются ответы на специальные Скрум вопросы каждым членом команды.

Не добовлять к итерации (Don’t Add to Iteration)

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

Скрум мастер экран (Scrum Master Firewall)

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

Решение за час

Блоки определенные на скрум митинге которые требуют решения Скрум Мастера идеально его сразу же и получают, или в течении 1 часа. Пропогандируеся ценность “плохое решение лучше чем никакое, и также обратное”.

Блок уходит за 1 день

Блоки определенные к разработке на Скрум собрании идеально удаляются на следующем митинге.

Цыплята и свиньи

Во время Скрум собрания, только Срум Команда может говорить (свиньи). Все остальные кто присутствует на митинге, должны молчать (цыплята), даже CEO.

Пред игровое планирование

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

Планирование Спринта

Перед началом каждой итерации—или Спринта—проводится два последовательных митинга. На первом, заинтересованные стороны встречаются чтобы детализировать и расставить приоритеты резерву свойств продукта и резерву свойств текушего выпуска, выбрать цели для следующей итерации, обычно руководствуясь важнейшими бизнес задачами и рисками. На втором митинге, Скрум команда и владелец продукта встречаются чтобы обсудить как достичь поставленых целей и создать резерв заданий Спринта (в 4-16 часовом разбиении). Если оцененный усилия превышают ресурсы, происходит другой цикл планирования. Резерв Спринта коректируется, часто ежедневно на ранней стадии итерации, как только обнаруживаются новые задания и когда итерация заканчивается. С ростом истории по многим спринт резервам, команда улучшает качество создания своих новых спринтов.

Команда Семерых

Скрум можно масштабировать до больших проектов, но рекомендуют в одной команде иметь максимум до 7 человек. Большие проекты это несколько команд.

Общая комната

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

Ежедневные билды

Как минимум ежедневная интеграция и регрессионное тестирование всего нового кода для проекта. XP практика непрерывной интеграции (Continuous Integration) еще лучше.

Проверка Спринта (Sprint Review)

В конце каждой итерации, проводится собрание для проверки (максимум 4 часа) проводимое Скрум Мастером. Команда, Владелец Продукта, и другие заинтересованные лица присутсвуют на собрании. Показывается демо продукта. Цели собрания включают информирование о фунциях системы, дизайне, сильных и слабых сторонах, достижений команды и обнаруженных будущих проблемных местах. Собираются отзывы и проводится мозговой штурм будущих направлений, но не дается ни каких обязательств во время митинга. Позже на следующем собрании планировании Спринта, команда и заказчики принимают на себя обязательства. “PowerPoint” презентации запрещены. При подготовке делается акцент на показе продукта.

Продолжение следует: Scrum (часть 2)

Основу методологии 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