Формула
Старый пост на неопределенную тему. Вроде неплохой.
http://rsdn.ru/Forum/message/2740456.1.aspx
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными
MSS>Первое и главное. ( Сроки * качество * функционал ) = ( const * человекоресурсы ). То есть - надо сразу выбрать, чем жертвуем - сроками, качеством или функционалом.
Ну, идея выписать формулу - интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
Трудозатраты = Сроки * человекоресурсы.
Также, очевидно, что
Трудозатраты ~ качество * функциональность.
Бюджет ~ Трудозатраты
Итого,
Бюджет ~ Сроки * Человекоресурсы ~ Качество * Функциональность.
Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка - Сроки должны в знаменателе стоять.
Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей, что очень сильно и нелинейно влияет и на бюджет, и на трудозатраты, и на качество. Скажем, делаем мы среду разработки для собственного DSL. Бюджет и сроки будут радикально, на порядки разные при выборе в качестве основы VBA или Qt+Scintilla+Python, например. Или, скажем, Java + Eclipse. Или рукопашной разработке без применения интеллектуальной собственности. Но допустим, что это не важно. Есть много проектов, где подобный выбор не стоит - а если и стоит, то лучше для определения оптимума проводить отдельный "НИР" за рамками основного проекта (ОКР).
MSS>Еще могу заметить, что решение пожертвовать качеством во имя сроков зачастую несет за собой нехорошие последствия. А именно - пишут сначала начерно и быстро, думая, что потом будет время - и перепишем начисто. Так вот, эта переписка начисто может занять значительно больший срок, чем даже написание начисто с нуля. Такое возникает в условиях, когда система уже развернута, и в процессе переписывания никак нельзя лишать ее работоспособности. Потому принесение в жертву качества во имя сроков легко приводит к тому, что в конечном итоге сорванными окажутся именно сроки.
Хочу на всякий случай пояснить значение термина "качество" в управлении проектами, чтобы под ним не понимали черт знает что. Термином "качество" в разработке ПО обозначают количество дефектов, которые репортят кастомеры, и которые находит тестирование. Качество характеризуется метрикой Defects/KLOC. "Жертвовать качеством" - это означает экономить на тестировании, откладывая его на поздние этапы, не более того.
Вы можете называть качеством что угодно - красоту кода, стройность дизайна - ради бога, но имейте в виду, что в контексте управления проектами "качество" это довольно узкий и конкретный термин - связанный с метрикой "плотность дефектов".
MSS>Отдельно скажу о том, как правильно приносить в жертву функционал. Технологией роадмапов. То есть - в обсуждениях затрагивается функционал по максимуму, даже тот, что будет реализован через пару лет в лучшем случае. Обсуждается огромное количество функционала действительно на годы вперед, и вся команда в курсе этого функционала. После чего раздаются приоритеты - это делаем прямо сейчас, это делаем потом, это делаем - когда руки дойдут.
MSS>Цель такой технологии - архитекторы знакомы с требованиями на два года вперед. В архитектуру продукта эти требования изначально попадают, что повышает шансы на то, что не потребуется никаких _архитектурных_ изменений в течение такого длинного срока.
+1. А я дам одну из конкртеных техник, как это делать - из старой внутренней инструкции, в основе квадрат риск-приоритет. Читайте в тексте задача = задача по реализации одной прикладной функции.
Приоритет
Приоритетом функции является ее важность для конечного результата. Функция имеет высокий приоритет в том случае, если без нее обойтись не возможно, и низкий, если без этой функции можно обойтись. Не все функции одинаково важны для результата.
Для оценки приоритетов принимается 3-х бальная шкала:
1 Продукт без той функции выпускать нельзя.
2 Отсутствие данной функции существенно уменьшит целевую аудиторию продукта, и/или заметно ухудшит его потребительские свойства.
3 Отсутствие данной функции в целом окажет небольшое влияние на размер аудитории и основные потребительские качества, важные для данной аудитории.
Риск
Под риском понимается:
Степень определенности в прогнозе трудозатрат.
Степень уверенности в технической реализуемости.
Высокий риск имеют задачи, которые непонятно как делать, настолько, что неясно, сколько времени они займут, и/или можно ли их сделать вообще.
Количественным выражением риска в первом случае является величина PERT Deviation для прогноза сроков задачи, которую можно понимать как среднеквадратичное отклонение случайной величины - собственно прогноза срока.
Риск всего проекта - это риск срыва плана, риск вылезания проекта за бюджет и потери экономической целесообразности разработки. Риск - это характеристика нашей неуверенности и нашего незнания. По мере приближения к окончанию проекта, мы способны все точнее и точнее предсказать дату его завершения - риск уменьшается по мере продвижения по графику. Очевидно, чем быстрее снижается риск проекта по мере продвижения по плану, тем лучше.
Что говорит о том, что задачи с высоким риском (неточным погнозом), в целом, надо ставить вперед.
Для качественной оценки технического риска узла и изделия Балиным В.Н. введена следующая 3-х бальная шкала:
1, Понятны границы работ, понятно как делать - возможно возникновение непринципиальных проблем по ходу реализации, которые будут решены за счет удлиннения срока.
2, Понятно, что делать, понятно, что это сделать можно, однако не до конца понятно как. Затруднительна достоверная оценка сроков, свойств реализации, и составление плана. (Надо проработать архитектуру и/или провести прототипирование)
3, Нет ясности с требованиями, непонятно, можно ли это сделать в рамках заданных ограничений, совершенно непонятно, как это делать (Надо проводить исследование, чтобы разобраться с темой)
Определение порядка выполнения задач
Рекомендуется ставить задачи в следующем порядке, принимая во внимание риски и приоритеты, используя "квадрат риск-приоритет":
Задачи с высоким приоритетом, и высоким риском.
Высокий приоритет, низкий риск.
Низкий приоритет, низкий риск.
Задачи низкого приоритета и высокого риска являются кандидатами для исключения из плана.
При определении порядка задач необходимо проследить, чтобы были учтены зависимости задач.
MSS>Далее. Чего надо избегать. Избегать надо любого труда, требующего заметные человеко-часы. Надо быть ленивым, но не из соображений "меньше напрягаться", а из соображений "сократить сроки".
+1
MSS>Это особый вид лени. В нем "за борт" отправляется не то, что требует напряжения или что неприятно, а осознанно то, что требует человеко-часов.
См. правило .
MSS>Ни в коем случае нельзя отправлять за борт _продумывание_ чего-то. Продумывание занимает, например, рабочий день, а сэкономить может - неделю кодирования и отладки. Продумывание должно быть направленно именно на - "как реализовать фичи, имея в виду роадмап, и при этом написав как можно меньше кода". Писать код - дороже по часам, чем думать.
Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.
MSS>Отлаживать и искать баги - дороже по часам, чем писать код. Потому писать надо сразу с минимумом багов. Любой код пишется сразу начисто с мотивацией "чтобы больше к нему уже никогда не возвращаться", а методологии, в которых сначала пишут начерно, а потом начисто - идут за борт.
+1. Ты о предварительном проектировании, конечно.
MSS>Очень осторожно надо относиться к test-driven методологическим паттернам. Для оценки того, можно ли в данном месте применять test-driven, предлагается использовать воображаемую метрику "примерная цена поиска бага в человеко-часах". Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ - то и не нужно там никаких юнит-тестов. Юнит-тесты крайне нужны для тех компонент, баг в которых очевидно будет тяжел в поиске, например, может "отзвонить" в совсем другое место в системе, или сильно зависит от входных данных, или что-то вроде.
+1.
Они ваще идут нахрен, если надо сроки вытянуть. Тестировать надо только те сценарии, которые реально требуется - их надо ограничить, но протестить как следует.
MSS>В этой ситуации написание юнит-тестов, а также инструментирование кода чем то вроде ASSERTов (прекрасное дополнение к юнит-тестам) - просто обязательно. Причина - человеко-часы на инструментирование и написание тестов ниже, чем на поиск даже одной баги.
Можно съекономить на тестировании режимов работы юнитов, которые не задействованы в системных сценариях, разрешенных к тестированию. А вот Ассерты - это хорошо, это дешево.
MSS>Естественно, тесты пишутся наскоро, экономя время. Этот код имеет большие шансы попасть в помойку. Нежелательно использование в юнит-тесте никаких тулов со сложными процедурами деплоймента. Можно написать на охапке BAT или VBS файлов - на них и пишется.
MSS>Обвешивать все вообще юнит-тестами - это такое же безумие, как ехать 60км/ч в левом ряду фривея. При том, что на очень многих улицах и дорогах 60км/ч таки превышать не стоит. Что же касается сочетания test-driven и "разработки начерно", известного под названием "XP" - то это сочетание езды 60км/ч (даже на фривее) с полным отсутствием контроля давления в колесах, из соображений - "если и спустило, то не убьюсь". Сочетание ИМХО близко к безумию.
+1
MSS>За борт идут все соображения ортогональности вида "если написали operator+, напишите и operator-". Нет. Не так. Сначала плюс. Потом - когда минус будет нужен при реализации какой-то фичи - вот тогда напишем минус.
+1 Они у нормальных людей всегда идут за борт ИМХО. Лучше написать когда потребуется, и тогда отладить, чем сделать сразу, и наклепать там ошибок, но их не выловить, потому "что не потребовалось". А то, помню, дернешь за функцию - а она глючит не по децки, потому что ты за 7 лет первый, кто ее вызвал . Бесит.
Ну и далее везде.
http://rsdn.ru/Forum/message/2740456.1.aspx
Здравствуйте, Maxim S. Shatskih, Вы писали:
MSS>Предлагаю обсудить эту тему. Выскажу свои соображения, с четким осознанием, что они могут оказаться неверными
MSS>Первое и главное. ( Сроки * качество * функционал ) = ( const * человекоресурсы ). То есть - надо сразу выбрать, чем жертвуем - сроками, качеством или функционалом.
Ну, идея выписать формулу - интересная. Тока, думается мне, формула чутка другая. Ну-ка, попробуем вывести.
Очевидно, в предположении идеальной балансировки задач по ресурсам, которое будет почти верным в случае, если у нас ограничены ресурсы, а проект длинный:
Трудозатраты = Сроки * человекоресурсы.
Также, очевидно, что
Трудозатраты ~ качество * функциональность.
Бюджет ~ Трудозатраты
Итого,
Бюджет ~ Сроки * Человекоресурсы ~ Качество * Функциональность.
Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка - Сроки должны в знаменателе стоять.
Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей, что очень сильно и нелинейно влияет и на бюджет, и на трудозатраты, и на качество. Скажем, делаем мы среду разработки для собственного DSL. Бюджет и сроки будут радикально, на порядки разные при выборе в качестве основы VBA или Qt+Scintilla+Python, например. Или, скажем, Java + Eclipse. Или рукопашной разработке без применения интеллектуальной собственности. Но допустим, что это не важно. Есть много проектов, где подобный выбор не стоит - а если и стоит, то лучше для определения оптимума проводить отдельный "НИР" за рамками основного проекта (ОКР).
MSS>Еще могу заметить, что решение пожертвовать качеством во имя сроков зачастую несет за собой нехорошие последствия. А именно - пишут сначала начерно и быстро, думая, что потом будет время - и перепишем начисто. Так вот, эта переписка начисто может занять значительно больший срок, чем даже написание начисто с нуля. Такое возникает в условиях, когда система уже развернута, и в процессе переписывания никак нельзя лишать ее работоспособности. Потому принесение в жертву качества во имя сроков легко приводит к тому, что в конечном итоге сорванными окажутся именно сроки.
Хочу на всякий случай пояснить значение термина "качество" в управлении проектами, чтобы под ним не понимали черт знает что. Термином "качество" в разработке ПО обозначают количество дефектов, которые репортят кастомеры, и которые находит тестирование. Качество характеризуется метрикой Defects/KLOC. "Жертвовать качеством" - это означает экономить на тестировании, откладывая его на поздние этапы, не более того.
Вы можете называть качеством что угодно - красоту кода, стройность дизайна - ради бога, но имейте в виду, что в контексте управления проектами "качество" это довольно узкий и конкретный термин - связанный с метрикой "плотность дефектов".
MSS>Отдельно скажу о том, как правильно приносить в жертву функционал. Технологией роадмапов. То есть - в обсуждениях затрагивается функционал по максимуму, даже тот, что будет реализован через пару лет в лучшем случае. Обсуждается огромное количество функционала действительно на годы вперед, и вся команда в курсе этого функционала. После чего раздаются приоритеты - это делаем прямо сейчас, это делаем потом, это делаем - когда руки дойдут.
MSS>Цель такой технологии - архитекторы знакомы с требованиями на два года вперед. В архитектуру продукта эти требования изначально попадают, что повышает шансы на то, что не потребуется никаких _архитектурных_ изменений в течение такого длинного срока.
+1. А я дам одну из конкртеных техник, как это делать - из старой внутренней инструкции, в основе квадрат риск-приоритет. Читайте в тексте задача = задача по реализации одной прикладной функции.
Приоритет
Приоритетом функции является ее важность для конечного результата. Функция имеет высокий приоритет в том случае, если без нее обойтись не возможно, и низкий, если без этой функции можно обойтись. Не все функции одинаково важны для результата.
Для оценки приоритетов принимается 3-х бальная шкала:
1 Продукт без той функции выпускать нельзя.
2 Отсутствие данной функции существенно уменьшит целевую аудиторию продукта, и/или заметно ухудшит его потребительские свойства.
3 Отсутствие данной функции в целом окажет небольшое влияние на размер аудитории и основные потребительские качества, важные для данной аудитории.
Риск
Под риском понимается:
Степень определенности в прогнозе трудозатрат.
Степень уверенности в технической реализуемости.
Высокий риск имеют задачи, которые непонятно как делать, настолько, что неясно, сколько времени они займут, и/или можно ли их сделать вообще.
Количественным выражением риска в первом случае является величина PERT Deviation для прогноза сроков задачи, которую можно понимать как среднеквадратичное отклонение случайной величины - собственно прогноза срока.
Риск всего проекта - это риск срыва плана, риск вылезания проекта за бюджет и потери экономической целесообразности разработки. Риск - это характеристика нашей неуверенности и нашего незнания. По мере приближения к окончанию проекта, мы способны все точнее и точнее предсказать дату его завершения - риск уменьшается по мере продвижения по графику. Очевидно, чем быстрее снижается риск проекта по мере продвижения по плану, тем лучше.
Что говорит о том, что задачи с высоким риском (неточным погнозом), в целом, надо ставить вперед.
Для качественной оценки технического риска узла и изделия Балиным В.Н. введена следующая 3-х бальная шкала:
1, Понятны границы работ, понятно как делать - возможно возникновение непринципиальных проблем по ходу реализации, которые будут решены за счет удлиннения срока.
2, Понятно, что делать, понятно, что это сделать можно, однако не до конца понятно как. Затруднительна достоверная оценка сроков, свойств реализации, и составление плана. (Надо проработать архитектуру и/или провести прототипирование)
3, Нет ясности с требованиями, непонятно, можно ли это сделать в рамках заданных ограничений, совершенно непонятно, как это делать (Надо проводить исследование, чтобы разобраться с темой)
Определение порядка выполнения задач
Рекомендуется ставить задачи в следующем порядке, принимая во внимание риски и приоритеты, используя "квадрат риск-приоритет":
Задачи с высоким приоритетом, и высоким риском.
Высокий приоритет, низкий риск.
Низкий приоритет, низкий риск.
Задачи низкого приоритета и высокого риска являются кандидатами для исключения из плана.
При определении порядка задач необходимо проследить, чтобы были учтены зависимости задач.
MSS>Далее. Чего надо избегать. Избегать надо любого труда, требующего заметные человеко-часы. Надо быть ленивым, но не из соображений "меньше напрягаться", а из соображений "сократить сроки".
+1
MSS>Это особый вид лени. В нем "за борт" отправляется не то, что требует напряжения или что неприятно, а осознанно то, что требует человеко-часов.
См. правило .
MSS>Ни в коем случае нельзя отправлять за борт _продумывание_ чего-то. Продумывание занимает, например, рабочий день, а сэкономить может - неделю кодирования и отладки. Продумывание должно быть направленно именно на - "как реализовать фичи, имея в виду роадмап, и при этом написав как можно меньше кода". Писать код - дороже по часам, чем думать.
Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.
MSS>Отлаживать и искать баги - дороже по часам, чем писать код. Потому писать надо сразу с минимумом багов. Любой код пишется сразу начисто с мотивацией "чтобы больше к нему уже никогда не возвращаться", а методологии, в которых сначала пишут начерно, а потом начисто - идут за борт.
+1. Ты о предварительном проектировании, конечно.
MSS>Очень осторожно надо относиться к test-driven методологическим паттернам. Для оценки того, можно ли в данном месте применять test-driven, предлагается использовать воображаемую метрику "примерная цена поиска бага в человеко-часах". Если баг в каком-то месте кода _неизбежно сразу бросится в глаза при почти любом сценарии использования_ - то и не нужно там никаких юнит-тестов. Юнит-тесты крайне нужны для тех компонент, баг в которых очевидно будет тяжел в поиске, например, может "отзвонить" в совсем другое место в системе, или сильно зависит от входных данных, или что-то вроде.
+1.
Они ваще идут нахрен, если надо сроки вытянуть. Тестировать надо только те сценарии, которые реально требуется - их надо ограничить, но протестить как следует.
MSS>В этой ситуации написание юнит-тестов, а также инструментирование кода чем то вроде ASSERTов (прекрасное дополнение к юнит-тестам) - просто обязательно. Причина - человеко-часы на инструментирование и написание тестов ниже, чем на поиск даже одной баги.
Можно съекономить на тестировании режимов работы юнитов, которые не задействованы в системных сценариях, разрешенных к тестированию. А вот Ассерты - это хорошо, это дешево.
MSS>Естественно, тесты пишутся наскоро, экономя время. Этот код имеет большие шансы попасть в помойку. Нежелательно использование в юнит-тесте никаких тулов со сложными процедурами деплоймента. Можно написать на охапке BAT или VBS файлов - на них и пишется.
MSS>Обвешивать все вообще юнит-тестами - это такое же безумие, как ехать 60км/ч в левом ряду фривея. При том, что на очень многих улицах и дорогах 60км/ч таки превышать не стоит. Что же касается сочетания test-driven и "разработки начерно", известного под названием "XP" - то это сочетание езды 60км/ч (даже на фривее) с полным отсутствием контроля давления в колесах, из соображений - "если и спустило, то не убьюсь". Сочетание ИМХО близко к безумию.
+1
MSS>За борт идут все соображения ортогональности вида "если написали operator+, напишите и operator-". Нет. Не так. Сначала плюс. Потом - когда минус будет нужен при реализации какой-то фичи - вот тогда напишем минус.
+1 Они у нормальных людей всегда идут за борт ИМХО. Лучше написать когда потребуется, и тогда отладить, чем сделать сразу, и наклепать там ошибок, но их не выловить, потому "что не потребовалось". А то, помню, дернешь за функцию - а она глючит не по децки, потому что ты за 7 лет первый, кто ее вызвал . Бесит.
Ну и далее везде.