Деловая зайка
Читаю новую книжку, ниже основные мысли каждой главы
Глава 1Глава 1
1 Оценка - приблизительный прогноз
1.1 Оценка - прогноз, цель - формулировка, обязательство - обещание предоставить функциональность
1.2 Оценка объективна и является основой для плана. Планирование субъективно, и служит для достижения цели
1.3 Что нужно спрашивающему оценку - оценка или план по достижению цели?
1.4 Точечная оценка - это цель. Если она оценка, то какова вероятность получения этого числа
1.5 Хорошая оценка в 75% случаев отличается от результата не более чем на 25%
1.6 Оценка не прогноз. Сначала оценка, потом обязательство, потом планирование
1.7 Оценка определяет, достаточно ли реалистичны цели проекта
1.8 Определение: хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей
Глава 2Глава 2
2. Хороший ли вы оценщик?
2.1 Простой тест по оценке на общие знания
2.2 - Значения достоверности в процентах имеют смысл, когда они поддерживаются количественными методами.
- Избегайте искусственного сужения диапазонов.
- Оценка в условиях неопределенности - обычное дело.
Глава 3Глава 3
3 Про преимущества точных оценок
3.1 Переоценка - закон Паркинсона (работа заполняет все отведенное время) и студенческий синдром Голдрэтта (адепты последнего дня). Недооценка - снижение эффективности планирования, мало времени на требования и проектирование, костыли. Потери от недооценки превышают потери от переоценки.
3.2 Чем больше проект - тем вышее вероятность его полного провала. Нарушения сроков обычно велики. Занижение оценок яввляется типичным явлением. Проблема недооценки суущеествует - надо начать с ее увеличения
3.3 Преимущества точных оценок: возможность отслеживать состояние проекта, повышение качества, улучшение координации, повышение доверия к разработчикам, обнаружение несоответствия между целью и оценкой проекта
3.4 Организация обычно ценит предсказуемость выше, чем срок разработки, затраты и гибкость
3.5 Методы оценки, основанные на интуиции или предположениях, можно выбросить за неэффективность.
Глава 4Глава 4
4 Откуда берутся ошибки оценки
4.1 Нельзя оценить объем работы, необходимый для построения чего-то нового, пока это что-то не определено
4.2 Конус неопределенности показывает, что точность оценки зависит от степени уточнения определения программы (мы уточняем определение с течением времени, вернее, в процессе работы над проектом). И единстввенным способом сокращения неопределенности в оценке - это сокращение ее в проекте
- оценка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса
- конус сужается только при устранении неопределенностей. Автоматически не сужается
- учитывайте наличие конуса, закладывая в своих оценках заранее определенную амплитуду неопределенности.
- учитывайте наличие конуса, разделяя оценку на 2 составляющие: количественная оценка и оценка неопределенности
- в широкой области конуса принимать обязательства неосмысленно. Надо дождаться сужения конуса
- при итеративном подходе на каждой итерации возникает свой малеенький конус неопределенности
4.3 Совершенствование методики оценки не обеспечит работу при хаотичным процессе разработки. Невозможно оценивать процесс, который не контролируется
4.4 Нестабильные требования: хаотичны, при изменении требований не происходит переоценки проекта. В условиях нестабильных требований следует ориентироваться нна стратегии управления проектом вместо стратегий оценки
4.5 Включайте в оценку время для всех видов требований: заявленных, неявных и функциональных. Учитывайте все необходимые операции (координация, настройка, прояснение требований, создание тестовых данных, выходные, обучение)
4.6 Оценки, полученные от разработчиков, скорее всего оптимистичны.
4.7 Избегайте включения регуляторов в свои оценки. Хотя может показаться, будто регуляторы улучшают точность, на самом деле они вводят в оценку субъективность и снижают реальную точность.
4.8 Не давайте импровизированных оценок. Лучше потратить немного времени.
4.9 Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.
4.10 Есть еще источники ошибок оценки
Глава 5Глава 5
5 Факторы, влияющие на оценку
5.1 Приложите соответствующие усилия для оценки размера программы, над которой вы работаете. Размер вносит наиболее значительный вклад в определение объема работы и сроков.
- Размер программы задается в количестве строк кода, потому что: современные среды программирования в меньшей степени ориентированы на строки кода, постановка требований, проектирование и тестирование не производят код, измеряемый в строках.
- Объем работ экспоненциально зависит от размеров проекта. Используйте специализированные программы для вычисления влияния издержек масштаба.
- Если вы ранее уже завершали предыдущие проекты, размер которых незначительно отличается от размера оцениваемого проекта (в диапазоне, в котором самый большой проект превосходит самый мелкий не более, чем в 3 раза), для оценки нового проекта можно смело использовать масштабный коэффициент (например, количество строк кода на человеко-месяц)
- Главный определяющий фактор - это размер проекта, эффект издержек масштаба - это фактор второго порядка.
5.2 В оценке учитывайте тип разрабатываемой программы - в отношении влияния на объем работы и сроки этот фактор является вторым по значимости.
5.3 Фактор подбора персонала (производительность работников может сильно различаться)
5.4 Язык программирования: опыт работы группы с конкретным языком и инструментарием; функциональность строки кода конкретного ЯП; широта возможностей инструментария и рабочих сред; разработчики, использующие интерпретируемые языки, обычно продуктивнее тех, кто использует компилируемые языки.
5.5 Здесь рассматриваются другие факторы, влияющие на оценку. В качестве примера берутся регулирующие факторы из программы Cocomo II
5.6 Не все факторы являются масштабными. Факторы, влияющие на издержки масштаба: изученность процесса, архитектура и разрешение рисков, прецедентность, слаженность команды, гибкость разработки.
Глава 6Глава 6
6.1 Выбор метода оценки определяется стремлением учесть все факторы и обойти источники ошибок оценки.
Что именно оценивается: вся область технической работы для реализации заданной функциональности (размер), количество функций, реализуемых в ограничениях срока и бюджета (функциональность). По размеру: малые проекты (5 и менее участников, лучше методы, основанные на оценках людей), большие (~25 участников, от 6-12 месяцев, на ранней стадии - оценка алгоритмов и статистики, на средней - сочетание методов, на поздней - оценка людей) и средние (5-25 участников, от 3 до 12 месяцев, все методы оценки).
Стили разработки: итеративный и последовательный.
Подходы к разработке: эволюционное макетирование (в случае: требования неизвестны, основная причина - содействие в определениях требований. итеративный стиль), экстремальное (только требования для итерации длиной в 1 мес, итеративный), эволюционная выдача (требования почти отсутствуют, либо итеративный, либо последовательный), поэтапная выдача (последовательный), унифицированный процесс (последовательный), scrum (итеративный).
Стадии разработки: ранняя (от начала построения концепта до определения требований или период исходного планирования), средняя (между начальным планирование и ранним конструированием, либо первые 2-4 итерации), поздняя (от середины разработки до выпуска)
Точности методики зависит и от оценки и специфики проекта и от того, правильно ли подобрана методика.
6.2 При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, стадию разработки, стиль разработки и требуемую точность.
Глава 7Глава 7
7.1 Считайте везде, где это возможно. Если счет невозможен - вычисляйте. Используйте оценки, полученные на основании одного лишь экспертного суждения, только в крайнем случае.
7.2 Найдите счетный показатель, который может использоваться для осмысленного измерения содержания работы в вашей среде. Показатель, доступный на ранней стадии цикла разработки. Показатель, дающий статически осмысленное среднее значение. Показатель, подсчитываемый с минимальными усилиями.
7.3 Соберите исторические данные, которые позволят вам вычислить оценку по счетным показателям. Не пренебрегайте возможностями простых, грубых оценочных моделей, таких как средний объем работы на дефект, средний объем работы на веб-страницу, средний объем работы на историю пользователя и средний объем работы на сценарий использования.
Не используйте экспертные суждения для подгонки оценок, полученных на основании вычислений. Подобная "экспертиза" обычно ухудшает точность оценки.
Глава 8Глава 8
8.1 Стройте свои оценки производительности на исторических данных. Производительность вашей организации в прошлом дает наилучшее представление о ее производительности в будущем.
Исторические данные помогают избежать решений, имеющих политическую подоплеку и возникающих из предположений типа "Моя группа ниже среднего".
8.2 При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показателей, и не изменяйте его между проектами. Собирайте исторические данные как можно раньше после начала проекта.
Организуйте периодический сбор исторических данных во время работы над проектом. Это позволит позднее построить профиль выполнения проекта, базирующийся на собранных данных.
Примерный набор данных: размер (например, количество строк), объем работы (человеко-месяцы), время (календарные месяцы), дефекты (с классификацией по степени тяжести)
8.3 Конечная цель сбора данных - преобразование данных в модель, которая может использоваться для оценки.
8.4 Используйте данные, полученные в ходе текущего проекта (проектные данные) для создания высокоточных оценок для оставшейся части проекта
8.5 Там, где это возможно, используйте для калибровки оценок проектные или исторические данные вместо среднеотраслевых. Помимо повышения точности оценок, исторические данные сокращают разброс оценок, обусловленный неопределенностью предположений по поводу производительности
8.6 Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно скорее
Глава 9Глава 9
Экспертные суждения - самый распространенный способ оценки.
9.1 Оценки уровня задач следует поручать людям, непосредственно занимающимся выполнением соответствующей работы. Если конкретные задачи еще не идентифицированы, то оценка должна создаваться опытным оценщиком/разработчиком.
Способ повышения точности оценок уровня задач - разбиение крупной задачи на подзадачи.
Создание оценок для лучшего и худшего случаев стимулирует мышление и помогает учесть весь возможный диапазон возможных результатов.
Кроме лучшего и худшего есть еще наиболее вероятный случай. И с помощью них можно вычислить ожидаемый случай по измененной формуле PERT: ожидаемый = [лучший + (3*наиболее_вероятный) + (2*худший)]/6
Используйте контрольные списки для улучшения индивидуальных оценок. Составляйте и ведите собственные контрольные списки.
9.2 Сравнивайте оценки с фактическими результатами, чтобы повышать качество своих оценок со временем. Можно вычислить величину относительной ошибки по формуле: MRE = Абсолютное значение * [(ФактическийРезультат - ОценкаРезультата)/ФактическийРезультат]
Глава 10Глава 10
Декомпозиция - разбиение оценки на фрагменты, раздельная оценка каждого фрагмента и последующее объединение отдельных оценок в составную.
10.1 Разбейте общую оценку на фрагменты, чтобы воспользоваться действием закона больших чисел: ошибки в сторону завышения и занижения до определенной степени компенсируют друг друга.
Разработка программного обеспечения представляет собой процесс постепенного уточнения требований.
10.2 Используйте обобщенную структуру трудозатрат программных проектов (WBS), чтобы не забыть о типовых операциях.
10.3 Распространенная проблема построения сводных оценок по декомпозиционным оценкам задач - сочетание 90% уверенности и необоснованного оптимизма (чаще точечные оценки - это оценка лучшего случая, и при сложении таких оценок вероятность достижения их уменьшается)
10.4 Нужно создать более осмысленные общие оценки для лучшего и худшего случаев, чем с помощью суммирования.
При количестве задач до 10 считается по упрощенной формуле. Сначала сумма оценок лучших и худших случаев, потом СтандартноеОтклонение = (СуммаОценокХудшего случая + СуммаОценокЛучшегоСлучая)/6
Если более 10 задач: ОтдельноеСтандартноеОтклонение = (ОтдельнаяОценкаХудшегоСлучая + ОтдельнаяОценкаЛучшегоСлучая)/6 - это считается для каждой оценки, потом считается дисперсия для каждого отклонения. Результат равен квадратному корню суммы дисперсий.
Лучше брать не 6, а выбирать делитель в зависимости от точности диапазонов оценок.
Направьте усилия на повышение точности оценок ожидаемого случая. Если отдельные оценки точны, то и их объединение не создаст проблем. С другой стороны, если отдельные оценки неточны, объединение станет возможным лишь после того, как вы найдете способ повысить их точность.
Глава 11Глава 11
11.1 Оценивайте новые проекты, сравнивая их с похожими прошлыми проектами. Постарайтесь разбить оценку минимум на 5 составляющих.
1. Получить подробные данные об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта.
2. Сравнить размер нового проекта с аналогичным прошлым проектом.
3. Построить оценку размера нового проекта в процентах от размера старого проекта.
4. Создать оценку объема работ, руководствуясь размером нового проекта по сравнению с размером предыдущего проекта
5. Следить за тем, чтобы показатели старого и нового проектов базировались на единых предположениях.
11.2 Цель оценки - точность. Не решайте проблему неопределенности смещением оценки. Постарайтесь отразить неопределенность в самой оценке.
В конечном счете неопределенность в оценке перейдет в планы и обязательства проекта.
Глава 12Глава 12
При опосредованной оценке сначала идентифицируется посредник - показатель, коррелированный с оцениваемым, который проще вычисляется или подсчитывается. Суть опосредованного метода - целое содержит более достоверную информацию, чем отдельные части (эти методы полезны для создания оценок уровня проекта/итерации)
12.1 Нечеткая логика - применяется для оценки размера проекта в строках кода. Лучше всего работает при калибровке размеров по историческим данным вашей организации. Важно правильно классифицировать все функции по размерам. Метод может использоваться для оценки объема работ.
12.2 Метод стандартных компонентов подходит для оценки нескольких программ со схожей архитектурой: идентифицируем и оцениваем стандартные компоненты, сначала в старой программе, потом в новых, опираясь на данные, полученные из старой программы. Его нужно рассматривать как средство для получения оценки размера с минимальными усилиями на ранних стадиях проекта.
12.3 Метод абстрактных рейтингов используется для получения ранней оценки объема работ и сроков проекта, и в основу его закладываются данные того же проекта. Здесь рассматривается список историй (функций/требований), и каждой истории присваиваем размер, измеряемый в пунктах. Все истории оцениваются одновременно и по одной шкале. Затем планируется итерация, в ходе которой нужно выдать некоторое число пунктов. После первой итерации происходит калибровка преобразования абстрактных пунктов в объем работ и календарное время.
Будьте внимательны при вычислении оценок, в которых используются числовые рейтинговые шкалы. Убедитесь в том, что числовые категории на шкале действительно ведут себя как числа, а не как отвлеченные категории вроде "малый", "средний", "большой".
12.4 Метод футболки нужен, чтобы помочь не-техническим сторонам проекта принять решения по включению или исключению тех или иных функций в широкой части конуса неопределенности. В этом методе разработчики классифицируют затраты на разработку каждой функции по отношению к другим функциям: малые, средние, большие или очень большие. Параллельно отдел маркетинга и другие классифицируют коммерческую ценность каждой функции по той же шкале. Набор объединяется и сортируется по отношению затраты/выигрыш.
12.5 Используйте опосредованные методы для оценки количества тестовых сценариев, дефектов, страниц документации и любых других показателей, которые трудно оценивать напрямую. Подсчитывайте тот показатель, который прощу считывается и обеспечивает максимальную точность в вашей среде. Соберите калибровочные данные и используйте их для создания оценки, адаптированной к вашей среде.
Глава 13Глава 13
Экспертные оценки в группах.
10.1 Используйте групповое обсуждение для повышения точности оценки. Каждый участник оценивает фрагменты проекта по отдельности, после чего группа встречается для сравнения оценок. Не надо ограничиваться принятием усредненной оценки, обязательно нужно обсудить различия между результатами. Нужно согласовать оценку, принятую всей группой (не голосовать, а добиться консенсуса).
13.2 Широкополосной Дельфийский метод:
-1 Координатор предоставляет каждому оценщику спецификацию и форму заявки.
-2 Оценщики по отдельности готовят исходные оценки.
-3 Координатор созывает собрание для обсуждения проблем, связанных с оценкой проекта.
-4 Оценщики анонимно передают индивидуальные оценки координатору
-5 Координатор готовит сводку оценок в итеративной форме и представляет ее оценщикам.
-6.Координатор организует встречу для обсуждения расхождений в оценке
-7 Оценки проводят анонимное голосование по принятию средней оценки. Если один не согласен, то снова к шагу 3
-8 Окончательная - точечная оценка. Или диапазон, созданный в ходе обсуждения, а точечная - это ожидаемый случай.
Используйте этот метод для формирования оценок на ранней стадии проекта, в незнакомых системах, а также тогда, когда в проекте задействовано несколько разнородных дисциплин.
Глава 14Глава 14
14.1 Используйте оценочные программы для логической проверки оценок, созданных ручными методами. Оценки крупных проектов должны в большей степени опираться на коммерческие оценочные программы. Операции, которые сложно проделать вручную:
- Моделирование результатов проекта.
- Вероятностный анализ (вероятность оценки)
- Учет издержек масштаба
- Учет непредвиденного расширения требований.
- Оценка вторичных аспектов разработки ПО
- Вычисление плановых показателей и интеграция с программами планирования.
- Анализ "Что - если"
- Арбитраж нереалистичных ожиданий
- Объективное авторитетное суждение при пересмотре предположений
- Логическая проверка оценок, полученных неформальными методами
- Оценка крупных проектов
14.2 Данные, необходимые для калибровки программ - исторические данные даже одного проекта (лучше хотя бы 3 проекта) лучше, чем среднеотраслевые данные.
14.3 Не относитесь к результатам оценочной программы как к божественному откровению. Проверяйте их на соответствие здравому смыслу точно так же, как любую другую оценку.
14.4 Оценочных программ множество. (в главе - список популярных)
Глава 15Глава 15
Используйте несколько альтернативных методов оценки и проанализируйте совпадения или расхождения результатов. Если разные методы оценки приводят к разным результатам, попытайтесь выявить факторы, из-за которых возникают различия. Продолжайте оценивать проект заново до тех пор, пока результаты, полученные разными методами, не будут сходиться в пределах 5%.
Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.
Глава 16Глава 16
Процедуры уточнения оценок в правильно оцениваемом проекте.
16.1 Не оспаривайте результаты оценки, а принимайте их как данность. Изменение результата может производиться только одним способом: изменением входных данных и повторным вычислением.
16.2 Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость и функциональность по оценке размера.
16.3 Проводите повторную оценку (из-за конуса неопределенности)
Переходите от неточных оценок к более точным по мере продвижения работы над проектом.
Когда проект будет готов к назначению индивидуальных заданий, переходите на восходящую оценку.
16.4 Если оценка пересчитывается в результате нарушения промежуточных сроков, новая оценка должна базироваться на фактическом ходе проекта, а не на запланированных показателях.
16.5 Представляйте свои оценки в таком виде, чтобы они уточнялись по мере продвижения проекта (диапазоны).
Сообщайте о своих планах повторного проведения оценки заранее. Всегда планируйте переоценку заранее.
16.6 Правильно оцениваемый проект - если каждый из диапазонов включал в себя итоговой результат. Проверять оценку обязательно нужно - проанализировать историю и понять, удалось ли спрогнозировать конечный итог.
Глава 17Глава 17
Стандартизированная процедура принятия оценки - это четкий процесс создания оценок, принятый на уровне организации.
17.1 Определите стандартизированную процедуру оценки на уровне организации и применяйте ее на уровне отдельных проектов.
17.2 Координируйте стандартизованную процедуру оценки с процессом SDLC (жизненный цикл разработки ПО), принятым в вашей организации.
17.3 Процедура оценки для последовательных проектов:
- предполагает, что главным приоритетом является функциональность, а основная цель оценки - в повышении точности оценок стоимости и сроков
- по возможности базируется на подсчете и вычислениях, а не на субъективных оценках.
- поощряет применение нескольких альтернативных оценок и сравнение результатов.
- подразумевает план пересмотра оценки в заранее определенных точках проекта.
- определяет изменения метода оценки в ходе жизненного цикла проекта.
- содержит четкое описание неточности оценки
- определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта
- определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств.
17.4 Процедура оценки для итеративных проектов:
- предполагает, что итерации находятся под правильным управлением - нужный уровень качества, нет отставания от графика, нужная зачистка и т.д. Задача оценщика - оценить объем функциональности, который может быть реализован с фиксированным штатом за фиксированный промежуток времени.
- все остальные пункты точно такие же как для последовательного проекта, исключая самый первый)
17.5 Пример процедуры от прогрессивной организации. Удовлетворяет всем требованиям из 17.3, кроме первого.
17.6 Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повысить точность оценок и свести к минимуму затраты на их создание.
Глава 18Глава 18
Цель оценки размера - поддержка долгосрочной прогнозируемости в широкой части конуса неопределенности.
18.1 Проблемы при оценке размера.
Много показателей размера. Используйте строки программного кода для оценки размеров, но помните об общих ограничениях простых метрик, а также специфических тонкостях метрики LOC.
18.2 Воспользуйтесь методом функциональных пунктов, чтобы получить относительно точную оценку размера на ранней стадии проекта.
Для преобразования функциональных пунктов в строки кода хорошо бы использовать исторические данные.
18.3 Методы вычисления функциональных пунктов.
- Голландский. ИндекативныеФункциональныеПункты = (35 * ВнутренниеЛогическиеФайлы) + (15 * ВнешниеИнтересныеФайлы). 35 и 15 - коэффициенты, полученные посредством калибровки. Используйте этот метод для получения приближенной оценки с минимальными затратами на ранней стадии проекта.
- Элементы GUI. Подсчет элементов, преобразование их количества в функциональные пункты и вычисление пунктов. Используйте подсчет элементов GUI для получения приближенной оценки с минимальным объемом работы на ранней стадии проекта.
18.4 При правильной методологии оценка размера становится основой для всех остальных оценок. Пример создаваемой системы является важнейшим фактором, определяющим ее стоимость. Для повышения точности используйте альтернативные оценки со сравнением результатов.
Глава 19Глава 19
Проблемы при оценке объема работ
19.1 Факторы, влияющие на объем работ - размер программы и производительность организации.
19.2
Глава 1Глава 1
1 Оценка - приблизительный прогноз
1.1 Оценка - прогноз, цель - формулировка, обязательство - обещание предоставить функциональность
1.2 Оценка объективна и является основой для плана. Планирование субъективно, и служит для достижения цели
1.3 Что нужно спрашивающему оценку - оценка или план по достижению цели?
1.4 Точечная оценка - это цель. Если она оценка, то какова вероятность получения этого числа
1.5 Хорошая оценка в 75% случаев отличается от результата не более чем на 25%
1.6 Оценка не прогноз. Сначала оценка, потом обязательство, потом планирование
1.7 Оценка определяет, достаточно ли реалистичны цели проекта
1.8 Определение: хорошей считается оценка, которая обеспечивает достаточно ясное представление реального состояния проекта и позволяет руководителю проекта принимать хорошие решения относительно того, как управлять проектом для достижения целей
Глава 2Глава 2
2. Хороший ли вы оценщик?
2.1 Простой тест по оценке на общие знания
2.2 - Значения достоверности в процентах имеют смысл, когда они поддерживаются количественными методами.
- Избегайте искусственного сужения диапазонов.
- Оценка в условиях неопределенности - обычное дело.
Глава 3Глава 3
3 Про преимущества точных оценок
3.1 Переоценка - закон Паркинсона (работа заполняет все отведенное время) и студенческий синдром Голдрэтта (адепты последнего дня). Недооценка - снижение эффективности планирования, мало времени на требования и проектирование, костыли. Потери от недооценки превышают потери от переоценки.
3.2 Чем больше проект - тем вышее вероятность его полного провала. Нарушения сроков обычно велики. Занижение оценок яввляется типичным явлением. Проблема недооценки суущеествует - надо начать с ее увеличения
3.3 Преимущества точных оценок: возможность отслеживать состояние проекта, повышение качества, улучшение координации, повышение доверия к разработчикам, обнаружение несоответствия между целью и оценкой проекта
3.4 Организация обычно ценит предсказуемость выше, чем срок разработки, затраты и гибкость
3.5 Методы оценки, основанные на интуиции или предположениях, можно выбросить за неэффективность.
Глава 4Глава 4
4 Откуда берутся ошибки оценки
4.1 Нельзя оценить объем работы, необходимый для построения чего-то нового, пока это что-то не определено
4.2 Конус неопределенности показывает, что точность оценки зависит от степени уточнения определения программы (мы уточняем определение с течением времени, вернее, в процессе работы над проектом). И единстввенным способом сокращения неопределенности в оценке - это сокращение ее в проекте
- оценка не может быть более точной, чем это возможно на текущей позиции проекта внутри конуса
- конус сужается только при устранении неопределенностей. Автоматически не сужается
- учитывайте наличие конуса, закладывая в своих оценках заранее определенную амплитуду неопределенности.
- учитывайте наличие конуса, разделяя оценку на 2 составляющие: количественная оценка и оценка неопределенности
- в широкой области конуса принимать обязательства неосмысленно. Надо дождаться сужения конуса
- при итеративном подходе на каждой итерации возникает свой малеенький конус неопределенности
4.3 Совершенствование методики оценки не обеспечит работу при хаотичным процессе разработки. Невозможно оценивать процесс, который не контролируется
4.4 Нестабильные требования: хаотичны, при изменении требований не происходит переоценки проекта. В условиях нестабильных требований следует ориентироваться нна стратегии управления проектом вместо стратегий оценки
4.5 Включайте в оценку время для всех видов требований: заявленных, неявных и функциональных. Учитывайте все необходимые операции (координация, настройка, прояснение требований, создание тестовых данных, выходные, обучение)
4.6 Оценки, полученные от разработчиков, скорее всего оптимистичны.
4.7 Избегайте включения регуляторов в свои оценки. Хотя может показаться, будто регуляторы улучшают точность, на самом деле они вводят в оценку субъективность и снижают реальную точность.
4.8 Не давайте импровизированных оценок. Лучше потратить немного времени.
4.9 Количество значащих цифр в оценке (ее четкость) должно соответствовать точности оценки.
4.10 Есть еще источники ошибок оценки
Глава 5Глава 5
5 Факторы, влияющие на оценку
5.1 Приложите соответствующие усилия для оценки размера программы, над которой вы работаете. Размер вносит наиболее значительный вклад в определение объема работы и сроков.
- Размер программы задается в количестве строк кода, потому что: современные среды программирования в меньшей степени ориентированы на строки кода, постановка требований, проектирование и тестирование не производят код, измеряемый в строках.
- Объем работ экспоненциально зависит от размеров проекта. Используйте специализированные программы для вычисления влияния издержек масштаба.
- Если вы ранее уже завершали предыдущие проекты, размер которых незначительно отличается от размера оцениваемого проекта (в диапазоне, в котором самый большой проект превосходит самый мелкий не более, чем в 3 раза), для оценки нового проекта можно смело использовать масштабный коэффициент (например, количество строк кода на человеко-месяц)
- Главный определяющий фактор - это размер проекта, эффект издержек масштаба - это фактор второго порядка.
5.2 В оценке учитывайте тип разрабатываемой программы - в отношении влияния на объем работы и сроки этот фактор является вторым по значимости.
5.3 Фактор подбора персонала (производительность работников может сильно различаться)
5.4 Язык программирования: опыт работы группы с конкретным языком и инструментарием; функциональность строки кода конкретного ЯП; широта возможностей инструментария и рабочих сред; разработчики, использующие интерпретируемые языки, обычно продуктивнее тех, кто использует компилируемые языки.
5.5 Здесь рассматриваются другие факторы, влияющие на оценку. В качестве примера берутся регулирующие факторы из программы Cocomo II
5.6 Не все факторы являются масштабными. Факторы, влияющие на издержки масштаба: изученность процесса, архитектура и разрешение рисков, прецедентность, слаженность команды, гибкость разработки.
Глава 6Глава 6
6.1 Выбор метода оценки определяется стремлением учесть все факторы и обойти источники ошибок оценки.
Что именно оценивается: вся область технической работы для реализации заданной функциональности (размер), количество функций, реализуемых в ограничениях срока и бюджета (функциональность). По размеру: малые проекты (5 и менее участников, лучше методы, основанные на оценках людей), большие (~25 участников, от 6-12 месяцев, на ранней стадии - оценка алгоритмов и статистики, на средней - сочетание методов, на поздней - оценка людей) и средние (5-25 участников, от 3 до 12 месяцев, все методы оценки).
Стили разработки: итеративный и последовательный.
Подходы к разработке: эволюционное макетирование (в случае: требования неизвестны, основная причина - содействие в определениях требований. итеративный стиль), экстремальное (только требования для итерации длиной в 1 мес, итеративный), эволюционная выдача (требования почти отсутствуют, либо итеративный, либо последовательный), поэтапная выдача (последовательный), унифицированный процесс (последовательный), scrum (итеративный).
Стадии разработки: ранняя (от начала построения концепта до определения требований или период исходного планирования), средняя (между начальным планирование и ранним конструированием, либо первые 2-4 итерации), поздняя (от середины разработки до выпуска)
Точности методики зависит и от оценки и специфики проекта и от того, правильно ли подобрана методика.
6.2 При выборе метода оценки следует учитывать оцениваемый показатель, размер проекта, стадию разработки, стиль разработки и требуемую точность.
Глава 7Глава 7
7.1 Считайте везде, где это возможно. Если счет невозможен - вычисляйте. Используйте оценки, полученные на основании одного лишь экспертного суждения, только в крайнем случае.
7.2 Найдите счетный показатель, который может использоваться для осмысленного измерения содержания работы в вашей среде. Показатель, доступный на ранней стадии цикла разработки. Показатель, дающий статически осмысленное среднее значение. Показатель, подсчитываемый с минимальными усилиями.
7.3 Соберите исторические данные, которые позволят вам вычислить оценку по счетным показателям. Не пренебрегайте возможностями простых, грубых оценочных моделей, таких как средний объем работы на дефект, средний объем работы на веб-страницу, средний объем работы на историю пользователя и средний объем работы на сценарий использования.
Не используйте экспертные суждения для подгонки оценок, полученных на основании вычислений. Подобная "экспертиза" обычно ухудшает точность оценки.
Глава 8Глава 8
8.1 Стройте свои оценки производительности на исторических данных. Производительность вашей организации в прошлом дает наилучшее представление о ее производительности в будущем.
Исторические данные помогают избежать решений, имеющих политическую подоплеку и возникающих из предположений типа "Моя группа ниже среднего".
8.2 При сборе исторических данных для оценок убедитесь в том, что вы понимаете смысл показателей, и не изменяйте его между проектами. Собирайте исторические данные как можно раньше после начала проекта.
Организуйте периодический сбор исторических данных во время работы над проектом. Это позволит позднее построить профиль выполнения проекта, базирующийся на собранных данных.
Примерный набор данных: размер (например, количество строк), объем работы (человеко-месяцы), время (календарные месяцы), дефекты (с классификацией по степени тяжести)
8.3 Конечная цель сбора данных - преобразование данных в модель, которая может использоваться для оценки.
8.4 Используйте данные, полученные в ходе текущего проекта (проектные данные) для создания высокоточных оценок для оставшейся части проекта
8.5 Там, где это возможно, используйте для калибровки оценок проектные или исторические данные вместо среднеотраслевых. Помимо повышения точности оценок, исторические данные сокращают разброс оценок, обусловленный неопределенностью предположений по поводу производительности
8.6 Если в настоящий момент у вас еще нет исторических данных, начните собирать их как можно скорее
Глава 9Глава 9
Экспертные суждения - самый распространенный способ оценки.
9.1 Оценки уровня задач следует поручать людям, непосредственно занимающимся выполнением соответствующей работы. Если конкретные задачи еще не идентифицированы, то оценка должна создаваться опытным оценщиком/разработчиком.
Способ повышения точности оценок уровня задач - разбиение крупной задачи на подзадачи.
Создание оценок для лучшего и худшего случаев стимулирует мышление и помогает учесть весь возможный диапазон возможных результатов.
Кроме лучшего и худшего есть еще наиболее вероятный случай. И с помощью них можно вычислить ожидаемый случай по измененной формуле PERT: ожидаемый = [лучший + (3*наиболее_вероятный) + (2*худший)]/6
Используйте контрольные списки для улучшения индивидуальных оценок. Составляйте и ведите собственные контрольные списки.
9.2 Сравнивайте оценки с фактическими результатами, чтобы повышать качество своих оценок со временем. Можно вычислить величину относительной ошибки по формуле: MRE = Абсолютное значение * [(ФактическийРезультат - ОценкаРезультата)/ФактическийРезультат]
Глава 10Глава 10
Декомпозиция - разбиение оценки на фрагменты, раздельная оценка каждого фрагмента и последующее объединение отдельных оценок в составную.
10.1 Разбейте общую оценку на фрагменты, чтобы воспользоваться действием закона больших чисел: ошибки в сторону завышения и занижения до определенной степени компенсируют друг друга.
Разработка программного обеспечения представляет собой процесс постепенного уточнения требований.
10.2 Используйте обобщенную структуру трудозатрат программных проектов (WBS), чтобы не забыть о типовых операциях.
10.3 Распространенная проблема построения сводных оценок по декомпозиционным оценкам задач - сочетание 90% уверенности и необоснованного оптимизма (чаще точечные оценки - это оценка лучшего случая, и при сложении таких оценок вероятность достижения их уменьшается)
10.4 Нужно создать более осмысленные общие оценки для лучшего и худшего случаев, чем с помощью суммирования.
При количестве задач до 10 считается по упрощенной формуле. Сначала сумма оценок лучших и худших случаев, потом СтандартноеОтклонение = (СуммаОценокХудшего случая + СуммаОценокЛучшегоСлучая)/6
Если более 10 задач: ОтдельноеСтандартноеОтклонение = (ОтдельнаяОценкаХудшегоСлучая + ОтдельнаяОценкаЛучшегоСлучая)/6 - это считается для каждой оценки, потом считается дисперсия для каждого отклонения. Результат равен квадратному корню суммы дисперсий.
Лучше брать не 6, а выбирать делитель в зависимости от точности диапазонов оценок.
Направьте усилия на повышение точности оценок ожидаемого случая. Если отдельные оценки точны, то и их объединение не создаст проблем. С другой стороны, если отдельные оценки неточны, объединение станет возможным лишь после того, как вы найдете способ повысить их точность.
Глава 11Глава 11
11.1 Оценивайте новые проекты, сравнивая их с похожими прошлыми проектами. Постарайтесь разбить оценку минимум на 5 составляющих.
1. Получить подробные данные об итоговом размере, объеме работ и затратах для предыдущего аналогичного проекта.
2. Сравнить размер нового проекта с аналогичным прошлым проектом.
3. Построить оценку размера нового проекта в процентах от размера старого проекта.
4. Создать оценку объема работ, руководствуясь размером нового проекта по сравнению с размером предыдущего проекта
5. Следить за тем, чтобы показатели старого и нового проектов базировались на единых предположениях.
11.2 Цель оценки - точность. Не решайте проблему неопределенности смещением оценки. Постарайтесь отразить неопределенность в самой оценке.
В конечном счете неопределенность в оценке перейдет в планы и обязательства проекта.
Глава 12Глава 12
При опосредованной оценке сначала идентифицируется посредник - показатель, коррелированный с оцениваемым, который проще вычисляется или подсчитывается. Суть опосредованного метода - целое содержит более достоверную информацию, чем отдельные части (эти методы полезны для создания оценок уровня проекта/итерации)
12.1 Нечеткая логика - применяется для оценки размера проекта в строках кода. Лучше всего работает при калибровке размеров по историческим данным вашей организации. Важно правильно классифицировать все функции по размерам. Метод может использоваться для оценки объема работ.
12.2 Метод стандартных компонентов подходит для оценки нескольких программ со схожей архитектурой: идентифицируем и оцениваем стандартные компоненты, сначала в старой программе, потом в новых, опираясь на данные, полученные из старой программы. Его нужно рассматривать как средство для получения оценки размера с минимальными усилиями на ранних стадиях проекта.
12.3 Метод абстрактных рейтингов используется для получения ранней оценки объема работ и сроков проекта, и в основу его закладываются данные того же проекта. Здесь рассматривается список историй (функций/требований), и каждой истории присваиваем размер, измеряемый в пунктах. Все истории оцениваются одновременно и по одной шкале. Затем планируется итерация, в ходе которой нужно выдать некоторое число пунктов. После первой итерации происходит калибровка преобразования абстрактных пунктов в объем работ и календарное время.
Будьте внимательны при вычислении оценок, в которых используются числовые рейтинговые шкалы. Убедитесь в том, что числовые категории на шкале действительно ведут себя как числа, а не как отвлеченные категории вроде "малый", "средний", "большой".
12.4 Метод футболки нужен, чтобы помочь не-техническим сторонам проекта принять решения по включению или исключению тех или иных функций в широкой части конуса неопределенности. В этом методе разработчики классифицируют затраты на разработку каждой функции по отношению к другим функциям: малые, средние, большие или очень большие. Параллельно отдел маркетинга и другие классифицируют коммерческую ценность каждой функции по той же шкале. Набор объединяется и сортируется по отношению затраты/выигрыш.
12.5 Используйте опосредованные методы для оценки количества тестовых сценариев, дефектов, страниц документации и любых других показателей, которые трудно оценивать напрямую. Подсчитывайте тот показатель, который прощу считывается и обеспечивает максимальную точность в вашей среде. Соберите калибровочные данные и используйте их для создания оценки, адаптированной к вашей среде.
Глава 13Глава 13
Экспертные оценки в группах.
10.1 Используйте групповое обсуждение для повышения точности оценки. Каждый участник оценивает фрагменты проекта по отдельности, после чего группа встречается для сравнения оценок. Не надо ограничиваться принятием усредненной оценки, обязательно нужно обсудить различия между результатами. Нужно согласовать оценку, принятую всей группой (не голосовать, а добиться консенсуса).
13.2 Широкополосной Дельфийский метод:
-1 Координатор предоставляет каждому оценщику спецификацию и форму заявки.
-2 Оценщики по отдельности готовят исходные оценки.
-3 Координатор созывает собрание для обсуждения проблем, связанных с оценкой проекта.
-4 Оценщики анонимно передают индивидуальные оценки координатору
-5 Координатор готовит сводку оценок в итеративной форме и представляет ее оценщикам.
-6.Координатор организует встречу для обсуждения расхождений в оценке
-7 Оценки проводят анонимное голосование по принятию средней оценки. Если один не согласен, то снова к шагу 3
-8 Окончательная - точечная оценка. Или диапазон, созданный в ходе обсуждения, а точечная - это ожидаемый случай.
Используйте этот метод для формирования оценок на ранней стадии проекта, в незнакомых системах, а также тогда, когда в проекте задействовано несколько разнородных дисциплин.
Глава 14Глава 14
14.1 Используйте оценочные программы для логической проверки оценок, созданных ручными методами. Оценки крупных проектов должны в большей степени опираться на коммерческие оценочные программы. Операции, которые сложно проделать вручную:
- Моделирование результатов проекта.
- Вероятностный анализ (вероятность оценки)
- Учет издержек масштаба
- Учет непредвиденного расширения требований.
- Оценка вторичных аспектов разработки ПО
- Вычисление плановых показателей и интеграция с программами планирования.
- Анализ "Что - если"
- Арбитраж нереалистичных ожиданий
- Объективное авторитетное суждение при пересмотре предположений
- Логическая проверка оценок, полученных неформальными методами
- Оценка крупных проектов
14.2 Данные, необходимые для калибровки программ - исторические данные даже одного проекта (лучше хотя бы 3 проекта) лучше, чем среднеотраслевые данные.
14.3 Не относитесь к результатам оценочной программы как к божественному откровению. Проверяйте их на соответствие здравому смыслу точно так же, как любую другую оценку.
14.4 Оценочных программ множество. (в главе - список популярных)
Глава 15Глава 15
Используйте несколько альтернативных методов оценки и проанализируйте совпадения или расхождения результатов. Если разные методы оценки приводят к разным результатам, попытайтесь выявить факторы, из-за которых возникают различия. Продолжайте оценивать проект заново до тех пор, пока результаты, полученные разными методами, не будут сходиться в пределах 5%.
Если деловая цель противоречит нескольким сходящимся оценкам, лучше доверьтесь оценкам.
Глава 16Глава 16
Процедуры уточнения оценок в правильно оцениваемом проекте.
16.1 Не оспаривайте результаты оценки, а принимайте их как данность. Изменение результата может производиться только одним способом: изменением входных данных и повторным вычислением.
16.2 Сначала сконцентрируйтесь на оценке размера. Затем вычислите объем работ, сроки, стоимость и функциональность по оценке размера.
16.3 Проводите повторную оценку (из-за конуса неопределенности)
Переходите от неточных оценок к более точным по мере продвижения работы над проектом.
Когда проект будет готов к назначению индивидуальных заданий, переходите на восходящую оценку.
16.4 Если оценка пересчитывается в результате нарушения промежуточных сроков, новая оценка должна базироваться на фактическом ходе проекта, а не на запланированных показателях.
16.5 Представляйте свои оценки в таком виде, чтобы они уточнялись по мере продвижения проекта (диапазоны).
Сообщайте о своих планах повторного проведения оценки заранее. Всегда планируйте переоценку заранее.
16.6 Правильно оцениваемый проект - если каждый из диапазонов включал в себя итоговой результат. Проверять оценку обязательно нужно - проанализировать историю и понять, удалось ли спрогнозировать конечный итог.
Глава 17Глава 17
Стандартизированная процедура принятия оценки - это четкий процесс создания оценок, принятый на уровне организации.
17.1 Определите стандартизированную процедуру оценки на уровне организации и применяйте ее на уровне отдельных проектов.
17.2 Координируйте стандартизованную процедуру оценки с процессом SDLC (жизненный цикл разработки ПО), принятым в вашей организации.
17.3 Процедура оценки для последовательных проектов:
- предполагает, что главным приоритетом является функциональность, а основная цель оценки - в повышении точности оценок стоимости и сроков
- по возможности базируется на подсчете и вычислениях, а не на субъективных оценках.
- поощряет применение нескольких альтернативных оценок и сравнение результатов.
- подразумевает план пересмотра оценки в заранее определенных точках проекта.
- определяет изменения метода оценки в ходе жизненного цикла проекта.
- содержит четкое описание неточности оценки
- определяет, когда оценка может использоваться в качестве основы для формирования бюджета проекта
- определяет, когда оценка может использоваться в качестве основы для внутренних и внешних обязательств.
17.4 Процедура оценки для итеративных проектов:
- предполагает, что итерации находятся под правильным управлением - нужный уровень качества, нет отставания от графика, нужная зачистка и т.д. Задача оценщика - оценить объем функциональности, который может быть реализован с фиксированным штатом за фиксированный промежуток времени.
- все остальные пункты точно такие же как для последовательного проекта, исключая самый первый)
17.5 Пример процедуры от прогрессивной организации. Удовлетворяет всем требованиям из 17.3, кроме первого.
17.6 Анализируйте оценки и процедуры получения оценок в своих проектах; это поможет вам повысить точность оценок и свести к минимуму затраты на их создание.
Глава 18Глава 18
Цель оценки размера - поддержка долгосрочной прогнозируемости в широкой части конуса неопределенности.
18.1 Проблемы при оценке размера.
Много показателей размера. Используйте строки программного кода для оценки размеров, но помните об общих ограничениях простых метрик, а также специфических тонкостях метрики LOC.
18.2 Воспользуйтесь методом функциональных пунктов, чтобы получить относительно точную оценку размера на ранней стадии проекта.
Для преобразования функциональных пунктов в строки кода хорошо бы использовать исторические данные.
18.3 Методы вычисления функциональных пунктов.
- Голландский. ИндекативныеФункциональныеПункты = (35 * ВнутренниеЛогическиеФайлы) + (15 * ВнешниеИнтересныеФайлы). 35 и 15 - коэффициенты, полученные посредством калибровки. Используйте этот метод для получения приближенной оценки с минимальными затратами на ранней стадии проекта.
- Элементы GUI. Подсчет элементов, преобразование их количества в функциональные пункты и вычисление пунктов. Используйте подсчет элементов GUI для получения приближенной оценки с минимальным объемом работы на ранней стадии проекта.
18.4 При правильной методологии оценка размера становится основой для всех остальных оценок. Пример создаваемой системы является важнейшим фактором, определяющим ее стоимость. Для повышения точности используйте альтернативные оценки со сравнением результатов.
Глава 19Глава 19
Проблемы при оценке объема работ
19.1 Факторы, влияющие на объем работ - размер программы и производительность организации.
19.2
@темы: заметки на полях, read