Software Project Management Conference

Разработка ПО: факты против мифов

С. Архипенков

16 ноября 2012

{

{Еще раз о «Хаосе» ()

(C) Standish Group

3

{

{Миф: разрабатывать ПО просто ()Факты:• Много лет только 1/3 проектов

укладывается в треугольник: качество-стоимость-срок;

• Отраслевой прирост производительности – 3-5% в год;

• Разброс производительности в 10 раз;• 80% – интеллектуальная работа;• Пространство выбора решения – не

ограничено;

4

{

{Миф: разрабатывать ПО сложно ()

Факты:• Время вхождения в профессию

меньше, чем в других отраслях;• Нет физических ограничений;• Ограниченные усилия могут

принести колоссальный эффект;// Большинство выдающихся программных продуктов создано студентами в гараже;

5

{

{Миф: разработка ПО похожа на другие производства ()

НИР

ОКР

Производство

НИИ

КБЗавод

6

{

{Факт: разработка ПО – это только проектирование ()

НИР

ОКР

Производство

Компилятор

Вычислитель

Разработка

7

{

{Миф: разработка ПО – это инженерная дисциплина ()Факт:• Разработка ПО это гуманитарная

дисциплина• Гласс: Отсутствует теория;• Брукс:

– Отсутствуют средства визуализации;

– Неопределенность и изменчивость;

– Отличие производительности более чем в 10 раз. (Гласс: в 28 раз!);

• Коуберн: Успешность программного проекта на 100% определяется людьми; Пупкин Иванов

02468

10

Производительность

8

{

{Миф: разработку ПО можно ускорить ()

Факты:• Девять беременных женщин

не родят ребенка за месяц;• Ни один проект невозможно

завершить быстрее, чем за 3/4 расчетного оптимального графика;

• Демарко: «наиболее эффективно программисты работают без жестких сроков»;

Время

Затраты

, чел

.*м

ес.

Опт. ЗатянутыйМин.

…или так!

Дальше бывает

так..

9

{

{Миф: проблемы можно «закидать деньгами» ()Факты:• Добавление людей в

отстающий проект только увеличит отставание;

• Сверхурочные и авралы снижают производительность;

• Применение новых инструментов снижают производительность, но если повезет могут ее повысить на 5-10%;

10

{

{Миф: проблемы можно решить при помощи процесса ()Факты:• Существуют десятки

методологий, но ни одна не гарантирует результат;

• Коуберн не обнаружил корреляции между успехом/провалом проектов и методологиями, которые применялись в проектах;

SW-СММ, Capability Maturity Measure

Вес методологии

Как получится

Rational Unified Process

SEI PSP/TSP

ГОСТы19.ххх,34.ххх

Agile:XP,

Crystal,Scrum,ASD,FDDдр.

MSF

11

{

{Миф: работу программиста можно измерить ()

Факты:• Не работает;• НЕ РАБОТАЕТ!• Работу

программиста можно оценить;

12

{

{Миф: работу программистов нельзя измерить ()Факт – обязательно надо измерять:• Количество

протестированных функций;

• Количество изменений;• Объем кода;• Средняя

производительность;• Дефектность продукта;• Качество архитектуры;

13

{

{Миф: незаменимых людей нет ()

Про

дукт

ивно

сть

Время

В. Пупкин

И. Ива

нов

В.Пупкин ушел

И.Иванов «пришел»

Потери компании

От 2 до 12 месяцев

Факт – есть цена замены; Мы инвестируем в Васю; Вася остается; Мы «не попадаем» на потери ~ годовая зарплата;

14

{

{Миф: программисты анти-бюрократичны ()Факты:• Программисты – анти-

идеотичны;• Программисты сторонятся

тех, кто усложняет их работу;

• Программисты самоорганизуются вокруг тех, кто облегчает их работу;

15

{

{Миф: о железном треугольнике ()

Факты:• Разработка продукта

длилась 5 лет вместо одного года;

• Бюджет проекта был превышен более, чем в 5 раз;

• Это - провал?

// Нет - это был MS Word!

Содержание

Стоимость

Время

16

{

{Миф: программистами невозможно управлять ()Факты:• Методы Макдональдса не

работают;• Управлять разработкой ПО

надо иначе;

{

{Теория-W Барри Боэма ()

Надо ориентироваться не на проектный треугольник, а на людей:• Понять, что каждый хочет выиграть; • Формировать разумные ожидания;• Способствовать общению;• Создавать взаимовыгодный

процесс;• Создавать взаимовыгодный

продукт; // B.W.Boehm, R.Ross, Theory-W Software Project Management: Principles and Examples, 1989, IEEЕ

Loser

Winer

{

{Правильный продукт ()Демарко:• В разработке ПО есть два типа проектов:

– Тип A, которые приносят 10% прибыли;– Тип B, которые приносят более 500%

прибыли;• Вывод – давайте разрабатывать

программные продукты типа B.

// Tom DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, © 2009 IEEE

{

{Правильный персонал ()

Характеристики:• Сосредоточенность на проблеме;• Креативность и независимость;• Принятие себя и других, чувство

общности с другими;• Искренность, простота,

естественность, философский доброжелательный юмор;

• Сопротивление окультуриванию;// А. Маслоу, «Новые рубежи человеческой природы», М., Смысл, 1999

E = IQ x EQ2

20

{

{Правильный процесс ()

E(t) = F(Pt1, Pt

2, Pt3, Pt

4),где

Pt1- продукт, Pt

2- проект, Pt3- персонал, Pt

4- процесс.

Правильный процесс Pt4 opt обеспечивает максимум

работы

T

max R = ∫F(Pt1, Pt

2, Pt3, Pt

4 opt)dt Pt

4 0

{

{Правильный ПМ ()

Для «хорошего» управления количество возможных состояний управляющего устройства (разнообразие) должно быть не меньше, чем количество состояний объекта управления;

// Источник: У.Р.Эшби “Введение в кибернетику” М., ИЛ, 1959

Наблюдать

Общаться Анализировать

Синтезировать

ПробыватьОбобщать

22

Software Project Management Conference

Спасибо за внимание!