Как оценить проект, чтобы не было мучительно больно... потом(… и что делать, если это «потом» все-таки наступило…)

Luxoft’ 2008-2010 Д. Башакин

Copyright © 2008-2009 by Luxoft, Inc. All rights reserved. Version 1.2.1

О тренере

Дмитрий Башакин (DBashakin@Luxoft.com)

Luxoft, группа компаний IBS – ведущий эксперт по управлению проектами Учебного Центра

В ИТ-индустрии с 1986, 12 лет опыта в управлении проектами и проектными программами (управление производством, управление бизнесом, управление персоналом), 6 лет опыта тренерской деятельности, с 2008 года – штатный эксперт УЦ Luxoft

Каталог курсов Учебного Центра, расписание, контакты и прочая информация:

http://www.luxoft-training.ru

2

Правила

График семинара

Вопросы – по окончании слайда или раздела, но можно и сразу!

Обсуждения – приветствуются! Но: или общие, или за пределами аудитории

Мобильные телефоны – вибро-режим, разговоры за пределами аудитории

Обратная связь – форма оценки

3

Наша цель

Обсудить основные критерии выбора и применения различных методик оценки проектов по разработке ПО

Обсудить основные трудности оценок и способы их преодоления

Обсудить пути выхода из кризиса «А с оценкой мы все-таки "пролетели"…»

Подробнее – на курсе Учебного Центра:

PM-005 «Оценка проекта: размер и трудозатраты» – 20 часов

Ближайшее чтение – 25.06-01.07.2010, Москва

Вне рамок семинара: детальное обсуждение конкретных методик оценки

4

Вступление.

Об Учебном Центре Luxoft

Учебный Центр Luxoft

Что такое Учебный Центр Luxoft?Мы - часть компании Luxoft, лидера в области разработки ПО на заказНаша миссия - повышать эффективность IT-команд в компаниях-

клиентах

Кого и чему мы учим? Наша ниша – программная инженерия. Все дисциплины для создателей

ПО

Кто у нас преподает? Лучшие эксперты компании Luxoft и индустрии Software Engineering

Как с нами работать? Очное и On-line Обучение. Корпоративные тренинги

Почему мы – лучшие в своей области? 3 причины учиться в УЦ Luxoft: Результат, Экспертиза, Гибкость

Мероприятия УЦ Luxoft

Очные мероприятия:

Открытые Тренинги и Классы в Школах www.Luxoft-Training.ru

Конференции с отраслевой тематикой www.Soft-Labs.ru

Семинары

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

Online мероприятия:

Online Тренинги и Классы в Школах

Вебинары

Школы и Классы в Школах

Школа Менеджера проекта (52 курса) Класс руководителя группы разработки; Класс менеджера проекта

Школа Аналитика (36 курсов) Класс системного аналитика; Класс бизнес аналитика

Школа Проектировщика (9 курсов) Класс проектировщика

Школа Разработчика (28 курсов) Класс .Net разработчика; Класс Java-разработчика

Школа Тестировщика (76 курсов) Класс Тест-менеджера; Класс Тест-дизайнера; Класс тестировщика; Инженеров по

автоматизированному тестированию

Каталог: www.luxoft-training.ru

Расписание: www.luxoft-training.ru, раздел Расписание и цены

Запись на обучение: для люксофтовцев, для внешних слушателей

Расписание – менеджерский блок

Школа Менеджера проекта

Очный Класс руководителя группы разработки: 05.04.2010-07.05.2010, 52 ч.

Очный Класс менеджера проектов:

Основы управления проектами: 11.05-27.05.2010, 44 ч.

Экспертный уровень управления проектами: 15.06-01.07.2010, 40 ч.

Онлайн Класс руководителя группы разработки: 08.02-15.02.2010, 20 ч. и 01.03-05.03.2010, 20 ч.

Чему мы учим?

• Rational Unified Process

• Agile, SCRUM

• ISO 2000, CMMI

• PMP

• UML, IDEF0

• J2EE

• MS .NET

• Oracle

• BEA, IBM

• Rational, Mercury

• XML, WebServices

• Планирование и

контроль

• Деловое общение

• Управление людьми

• Построение команды

• Презентации

• Управление проектом

• Анализ требований

• Проектирование

• Тестирование

• Конфигурационное

управление

• Управление

изменениями

IT-команда

Soft-labs

PM-labs: Конференция для менеджеров проектов

Arch-labs: Конференция для системных архитекторов и проектировщиков

Req-Labs: Конференция для системный и бизнес аналитиков

Test-labs: Конференция для инженеров по тестированию (тест-менеджеров, тест-дизайнеров, тестировщиков и автоматизаторов тестирования).

Dev-labs: Конференция для разработчиков ПО

Training-Labs: Конференция, посвященная обучению в сфере Software Engineering. Тренинговый марафон, в котором ведущие Учебные Центры индустрии, а также независимые тренеры представляют свои авторские курсы и проводят мастер-классы

Подробнее о конференциях: www.Soft-labs.ru

Training Labs 2010Москва, 17 апреля

Тренинговый марафон. Обучение в области разработки ПО

www.training-labs.ru

PM Labs 2010Москва, 28 сентября

Конференция для менеджеров ИТ проектов

www.pm-labs.ru

Ближайшие конференции Soft Labs в Москве

Семинары/вебинарыПартнерские мероприятия

Семинары / вебинары – очное / online бесплатное двухчасовое мероприятие, на котором эксперты Software Engineering (штатные эксперты УЦ, эксперты производственного подразделения Luxoft, внешние эксперты) делятся опытом реализации производственных задач в проектах

Партнерские мероприятия:

Семинары/Конференции совместно с Microsoft

Семинары с Oracle

Встречи .Net community, UML2.ru community

и т.п.

Расписание и регистрация на мероприятия:

http://www.luxoft-training.ru, раздел Мероприятия

Контакты

Учебный Центр Luxoft: www.Luxoft-Training.ru

E-mail: education@luxoft.com

Филиалы:

- Москва, Санкт-Петербург, Омск

- Киев, Одесса, Днепропетровск

Конференции Soft-labs: www.Soft-Labs.ru

География конференций: Москва, Омск, Киев

Часть 1.Как правильно оценить проект

Разработка ПО –хаос неизбежен?

16

Succeeded –выполнены в срок и в пределах выделенного бюджета

Challenged –превысили бюджет и/или сроки

Failed –прекратились ввиду невозможности довести проект до конца

Chaos Report (Standish Group) – анализ результатов исполнения ~ 70 000 ИТ-проектов, отражение положения дел в ИТ-отрасли

Источник: Trends in IT Value – 2008, Copyright © 2008 by The Standish Group International, Inc. All rights reserved.

Кто виноват?Нет, не так: что делать?

Итак, каждый пятый проект неуспешен, а каждый второй – исполняется с существенными проблемами

Почему?

Одна из существенных причин – неправильная оценка проектов

Оценка – основа планирования, неправильная оценка делает невозможным качественное планирование, а ведь «если вы провалите планирование, вы запланируете провал »

17

Цели проведения оценки

Подготовка технико-коммерческих предложений

Оценка проекта в целом

Планирование

Оценка отдельных задач в иерархической структуре работ (WBS)

Управление изменениями

Оценка запросов на изменения

Управление рисками

Оценка альтернатив

Переоценка при передаче проекта другой команде

Оценка несделанной части работ

(Пример: подготовка ТКП –> старт полномасштабного проекта)

Ваши дополнения? 18

В чем измеряются проекты?

С точки зрения Руководителя проекта?

В аналогичных проектах

С точки зрения Аналитика?

В сценариях (прецедентах) использования (use cases)

С точки зрения Архитектора?

В строках кода

С точки зрения Заказчика?

В килобаксах и ключевых контрольных событиях (вехах)

Почему это важно?

19

В чем измеряются проекты –почему это важно?

Получать оценку вы будете в понятных оценщикуединицах

И не требуйте от него преобразования во что-то другое!

Выдавать оценку Заказчику (потребителю) нужно в понятных ему единицах

Преобразовывать одно в другое – вам

20

Методики оценки

Экспертная оценка

Оценки с помощью моделей:

Оценка по аналогии

Use Case Points (UCP)

Function Points (FP)

Fast Function Points (FFP)

Early Functional Points (EFP)

Какими из здесь перечисленных и не перечисленных методик оценки приходилось пользоваться лично Вам?

21

Экспертная оценка (1)

Методика предназначена для оценки проектов с опорой на знания и опыт экспертов

Суть методики:

Оценка проекта в целом или его отдельных частей экспертами

На выходе – все, что угодно (но мы возьмем – скорее всего трудозатраты)

Плюсы:

Универсальная методика

Можно оценивать практически любые системы

Какие ограничения присущи этой методике?

Как обходить эти ограничения?22

Экспертная оценка (2)

Ограничения применимости:

Зависимость от наличия и квалификации экспертов

Может быть довольно трудоемкой

«Человеческий фактор»:

«все не так» (мало данных – плохо, много данных – тоже плохо)

усталость

риск «игнорирования» рисков

уровень ответственности – у каждого свой

23

Экспертная оценка (2)

Рекомендации:

Не пытайтесь оценить проект целиком – делайте декомпозицию:

По сущностям

Функциональность: количество экранов, отчетов, фидов (файлов экспорта или импорта) и т.п.

Данные: количество обрабатываемых сущностей и количество / сложность связей между ними

По объектам поставки (система, документация, обучающие материалы и т.д.) и функциональным блокам

Перепроверяйте!

Делайте несколько оценок, анализируйте и усредняйте

Проверяйте и корректируйте результаты оценки с помощью метрик

Используйте PERT (возможно, с подстройкой коэффициентов)

24

Оценка по аналогии (1)

Методика предусматривает оценку проекта на основании исторических данных. По сути –автоматизированная версия экспертной методики

Суть методики:

Оценка проекта на основании его «измерения» в формах, отчетах, подсистемах, сущностях и т.п.

На выходе – как решим, но скорее всего трудозатраты

Плюсы:

Устраняет недостатки экспертной методики

Очень хорошо подходит для развития существующего бизнеса

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

25

Оценка по аналогии (2)

Ограничения применимости:

Необходимо наличие исторических данных и их обработка

Слабо применима для новых проектов, новых бизнес-областей

При смене технологических платформ или команды требуется «перекалибровка»

Рекомендации:

Перепроверяйте! (пока не накопите хороший массив статистики)

26

Use Case Points (UCP) (1)

Методика предназначена для оценки проектов, для которых применяется определение требований с помощью сценариев (или прецедентов) использования (Use Cases)

Суть методики:

Выявление акторов (actors) и сценариев (прецедентов) использования, их «взвешивание» (оценка сложности)

На выходе – трудозатраты

Плюсы:

Быстро и просто!

Хорошо подходит для стандартных информационных систем (много пользовательского интерфейса, мало сложных алгоритмов)

Легко подстраивается под производительность команды или среднюю производительность по компании

27

Use Case Points (UCP) (2)

Ограничения применимости:

Для проведения оценки нужен аналитик

Требуется выделение «стандартных» (относительно простых) сценариев использования

Оценка сложности выполняется экспертным путем

Точность зависит от опыта аналитика и корректности коэффициента пересчета Use Case Points в человеко-часы

Не все системы можно оценивать по UCP (сложные алгоритмы и т.п.)

Рекомендации:

Подстраивайте под производительность команды

Если вы разрабатываете системы, описанными с помощью сценариев использования – используйте в повседневной практике!

28

Function Points (FP) (1)

Методика предназначена для оценки проектов на базе понятия «функциональная точка»

Суть методики:

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

Корректировка результатов – учет нефункциональных требований

Использование результата (в FP) в калькуляторе COCOMO (Constructive Cost Model – Barry W. Boehm) (пересчет в трудозатраты с разбиением по фазам проекта и процессам) или пересчет в размер кода и далее – в трудозатраты

Плюсы:

Высокая точность

Хорошо подходит для стандартных информационных систем29

Function Points (FP) (2)

Ограничения применимости:

Высокая трудоемкость применения методики и большая продолжительность процесса оценки

Необходимо детальное понимание того, как работает система (детальные требования, в идеале – еще и архитектурные решения)

Коэффициент пересчета FP в SLOCs зависит от языка программирования и использования «ускорителей» программистского труда (кодогенераторов и т.п.) – нужно измерять или покупать

Калькулятор COCOMO – инструмент, крайне чувствительный к квалификации оценщика

Рекомендации:

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

30

Early Function Points (EFP) (1)

Разновидность методики Function Points, допускающая применение в условиях отсутствия детальных требований

Суть методики:

Выявление всех информационных объектов и всех операций по обмену данными между системой и акторами

Корректировка результатов – учет нефункциональных требований

Пересчет в размер кода и далее – в трудозатраты

Плюсы:

Точность уровня методики Function Points для детально определенных частей системы

Сохранение работоспособности (путем повышение уровня абстракции) для поверхностно определенных частей системы

Хорошо подходит для стандартных информационных систем 31

Early Function Points (EFP) (2)

Ограничения применимости:

Оценка на высоких уровнях абстракции выполняется фактически экспертным путем

Коэффициент пересчета FP в SLOCs зависит от языка программирования и использования «ускорителей» программистского труда (кодогенераторов и т.п.) – нужно измерять или покупать

Невозможность применения результата в калькуляторе COCOMO

Рекомендации:

Используйте, когда система описана требованиями разного уровня детальности, но с преобладанием детальных описаний

32

Fast Function Points (FFP) (1)

Разновидность методики Function Points, допускающая применение в условиях отсутствия детальных требований

Суть методики:

Выявление всех информационных объектов и всех операций по обмену данными между системой и акторами (пользователями, другими системами) без оценки их сложности (= средняя)

Далее – полная аналогия с Function Points

Плюсы:

Нормальная работоспособность для недостаточно детально определенных частей системы

Возможность применения результата в калькуляторе COCOMO

Хорошо подходит для стандартных информационных систем

33

Fast Function Points (FFP) (2)

Ограничения применимости:

Отсутствует возможность оценки сложности даже для детально определенных частей системы

Коэффициент пересчета FP в SLOCs зависит от языка программирования и использования «ускорителей» программистского труда (кодогенераторов и т.п.) – нужно измерять или покупать

Рекомендации:

Используйте, когда система описана требованиями близкого и недостаточного для применения Function Points уровня детальности

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

34

Метрики (1)

Расширенный вариант цитаты: «Планирование без измерения невозможно, а если вы провалите планирование, вы запланируете провал »

Мини-опрос:

Какими метриками Вам приходилось пользоваться в процессе оценки и в целом в разработке программного обеспечения?

Для чего?

35

Метрики (2)

1. «Эффективность разработки»

Определение:

[Общие трудозатраты, чел.-часы] / [размер продукта, KSLOC]

Применение:

Оценка трудозатрат на исполнение проекта в целом, если известен размер кода и наоборот

2. «Производительность кодирования»

Определение:

[Размер кода, SLOC] / [трудозатраты на кодирование, чел.-часы]

Применение:

Оценка трудозатрат на кодирование, если известен размер кода и наоборот

36

Метрики (3)

3. «Распределение трудозатрат по процессам»

Определение: Распределение общих проектных трудозатрат между рабочими процессами:

Анализ требований, Проектирование, Кодирование, Тестирование, Документирование, Конфигурационное управление, Управление проектом

Применение:

Получение разбивки проектных трудозатрат на отдельные процессы (большинство методик дают на выходе полные проектные трудозатраты)

Получение общих проектных трудозатрат на основе известных затрат на один процесс (чаще всего это процессы кодирования и/или тестирования)

37

Проверка оценки

Сравниваем результаты, полученные по разным методикам

Не сошлось? Ищем ошибку у себя, а не в методике!

Используем метрики

Соотношение затрат на тестирование и на разработку – проверяем с помощью метрики «Распределение трудозатрат по процессам»

Подключаем здравый смысл

38

Поправки «на ветер»

Сработанность команды

Интеграция с другими системами

Специальные виды тестирования

Нагрузочное, производительности, удобства использования, …

Миграция данных из «старых» систем

Не забыть, что придется делать хотя бы один раз (возможно –многократно; возможно – в обе стороны)

Многоплатформенность

Разные операционные системы, браузеры, устройства (КПК, коммуникаторы, смартфоны), …

Необходимость / сложность обучения пользователей

Ваши предложения?39

Допущения в оценке

Допущение – «условие, необходимое для успешного выполнения проекта»

Каждое неясное место должно быть закрыто допущением!

Допущение – то, что делает оценку реальной

Не бывает оценок без допущений

Допущения превращаются в проектные риски

40

Где еще можно «подстелить соломку»?

«Рваная» загрузка ресурсов в плане-графике – источник риска перерасхода бюджета

Понимать, какие фазы оценивались!

Внедрение, опытная эксплуатация, поддержка – вне оценки по UCPи FP/FFP/EFP

«Водопад» для большинства проектов не работает!

Итерации + активное вовлечение Заказчика

Учесть риски и допущения и связать с ними буферы в плане-графике

41

Требования неясны, а fixedprice проект делать нужно

Проекты с фиксированной ценой – ночной (а иногда и дневной) кошмар менеджеров проектов

Идеально – оценка по Function Points, но где взять детальные требования? А что, если они «на салфетках»?

Выходы:

Разбиваем проект на относительно короткие итерации и «продаем» их по отдельности

Даже если «пролетим» с оценкой, потеряем существенно меньше

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

Заодно снимаем ключевые риски – правильным выбором содержания (scope) первых итераций

Даем грубую оценку и разбиваем проект на 2 части: уточнение и детализация требований + разработка; с переоценкой между ними

42

Часть 2. Как выходить из кризиса «А с оценкой мы все-таки "пролетели"…»

Что имеем?

Проект недооценен. Мы рискуем не выполнить обязательства перед Заказчиком:

На срок

На бюджет

Мини-опрос:

Что хуже?

И главное – что делать?

44

Первые мысли

Повысить интенсивность труда

«В сутках 24 часа, а не 8. В крайнем случае – 16…»

Добавить ресурсов, лучше всего – дешевых

«У нас же есть филиал в Урюпинске!…»

Сэкономить время и деньги

«С тестированием неплохо справится и сам Заказчик…»

Расслабиться и «засунуть голову в песок»

«А вдруг повезет? Бывают же форс-мажоры и у Заказчика…»

«В крайнем случае расскажем всем, что "в жизни все бывает"…»

45

Интенсификация

Плюсы:

Легко позволяет наверстать несколько дней отставания от графика

Чем больше команда, тем больше выигрыш

При умелом использовании способствует сплоченности команды

Минусы:

Не надейтесь наверстать месяц отставания

При длительном или частом применении приносит больше вреда, чем пользы:

Разрушается мотивация

Люди устают, делают больше ошибок, в итоге – с какого-то момента начинаем тратить больше, чем приобретать

Нарастают нервозность и негатив, нарушается внутри-проектная коммуникация, растет риск разрушения команды

Перерасход бюджета легко выходит из-под контроля46

Добавление ресурсов

Плюсы:

В условия низкой связанности задач позволяет разработать значительное количество дополнительного функционала

Минусы:

Теряется время на передачу знаний

Значительно (непропорционально результату) повышает стоимость проекта

Очень рискованно использовать для задач, находящихся на критическом пути

Демотивирует команду («они, значит, умнее нас?»)

«Разбалансирует» команду, отбрасывает ее на этап «Столкновение» (“Storming”) и тем самым значительно снижает ее производительность (помним жизненный цикл команды!)

47

Если ресурсы еще и дешевые

(Дополнительные) плюсы:

(Потенциально) позволяет снизить перерасход бюджета

(Дополнительные) минусы:

Передать проект в Урюпинск полностью все равно не успеем, а поддержка распределенной команды – вещь дорогая

48

Сэкономить на качестве…Расслабиться…

Без комментариев!

49

Действуем конструктивно! (1)

Внутренние резервы:

Мозговой штурм – вместе с командой!

«Срываем низко висящие плоды»:

На перфекционизм нет времени!

Устраняем барьеры для эффективной работы

Возможно, пришло время нарушить некоторые правила

Преподаем команде уроки эффективного управления временем

Определяем балласт в команде (деморализаторы, болтуны, халтурщики и т.п.) – отделяем (возможно, временно)

50

Действуем конструктивно! (2)

Внутренние резервы (окончание):

Привлекаем экспертов, вырабатываем альтернативы:

Оптимизируем решение (более простые и проверенные технические решения, …)

Повышаем эффективность работы (тулы, …)

Определяем альтернативы разработке своими силами (покупные компоненты, субподряд)

Заручаемся поддержкой своего руководства:

Оно много чем может помочь: советом, ресурсами, прямой коммуникацией с Заказчиком и демонстрацией личного внимания к проекту

Возможно, потом – когда основные проблемы будут решены – вам и достанется за допущенные промахи, но в этот момент вы будете уже не в худшей позиции

51

Действуем конструктивно! (3)

Внешние резервы:

Заказчик не меньше вас заинтересован в успехе проекта!

Вовлекаем ключевых заинтересованных лиц

Презентуем альтернативы

Более простые, проверенные и знакомые технические решения т.п.

Изменяем объем работ

Принцип Парето: 20% функционала системы удовлетворяют 80% потребностей пользователей, остальные 80% функционала можно сделать позже

Цель проекта – удовлетворение потребностей Заказчика и пользователей, а не формальная реализация требований!

52

Действуем конструктивно! (4)

Менеджер не должен быть «бутылочным горлышком»:

Делегируйте!

Помогите людям раскрыть свой потенциал!

«Никогда не говорите людям, как им действовать. Просто скажите, что нужно сделать, и они удивят вас своей изобретательностью!»

(George S. Patton (1885–1945))

53

Полезные ссылки (1)

Общее:

«IT Measurement: Practical Advice from the Experts» by International Function Point Users Group (Addison-Wesley Professional, April 27, 2002, 800 pages) (www.amazon.com, www.ozon.ru)

«Сравнение методов оценки стоимости проектов по разработке информационных систем» – Н.Михайловский (http://www.pmprofy.ru/content/rus/79/797-article.asp)

COCOMO:

COCOMO II –

http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html

54

Полезные ссылки (2)

Use Case Points:

«Project Estimation With Use Case Points» by Roy K. Clemmons(http://www.stsc.hill.af.mil/crosstalk/2006/02/0602Clemmons.pdf)

«How to Prepare Quotation Using Use Case Points» by Shivprasad koirala(http://www.codeproject.com/KB/architecture/usecasepoints.aspx)

Function Points:

IFPUG: International Function Point Users Group – www.ifpug.org

«Оценка трудоемкости разработки программного обеспечения методом Function Point с использованием модели COCOMO II» –Д.Либерман (http://www.talgar.ru/Articles/article.asp?ID=1145)

55

Полезные ссылки (3)

Fast Function Points:

FAST Function Points by David Seaver (presentation) (http://sunset.usc.edu/Activities/oct24-27-00/Presentations/Seaver_FAST%20Function%20Points.pdf)

Early Function Points:

Early and Extended Function Point: a new method for Function Points estimation by Roberto Meli (http://www.dpo.it/resources/papers/1997-ifpug-exfp-en.pdf)

Методика Function Points для предварительной оценки трудозатрат по проекту (http://www.pmprofy.ru/content/rus/20/203-article.asp)

Early Function Point Counting by Netherlands Software Metrics Users Association (http://www.nesma.org/english/earlyfpa.htm)

56

Вопросы?

57