Программирование как управление рисками

Об управлении рисками в процесс разработки я уже писал. Но мне кажется, об управлении рисками можно говорить даже в рамках программирования (т.е. написания и отладки программного кода). По крайней мере, я себя часто ловлю на том, что многие решения в процессе написания кода принимаются именно путем оценки и сравнения рисков альтернативных вариантов, последствий наших действий или не-действий. Многие т.н. best practices, кстати, можно «объяснить» различными рисками альтернатив.
Пример 1. Стандарты оформления исходного кода. Поддержка единого стандарта на форматирования кода, именования переменных и файлов и т.п. требует усилий и нек-рой дисциплины разработчиков. Отсутствие такого стандарта означает снижение читабельности кода.
Пример 2. Автоматизированные тесты. Тесты означает дополнительный код, который необходимо разрабатывать и поддерживать в актуальном состоянии. Отсутствие тестов означает потери времени на отладку и снижение точности планирования.

Пример 3. Размножение кода (copy&paste). Анализ программы для инкапсуляции схожего поведения в параметризованные функции/классы требует усилий, подчас значительных. Многократное копирование с незначительными изменениями означает и копирование возможных багов и необходимость изменения множества мест в программе.
Эти примеры, как и многие другие, не описывают некоторые незыблемые аксиомы и жесткие правила; каждая команда разработчиков решает их по разному. Важно только, как и в проектном управлении рисками, делать это осознанно.

Если уж вы называете глобальную переменную nrz вместо numberOfResidents, подумайте, что менее плохо: потери времени при наборе текста или потери в читабельности программы из-за непонятного имени.
Программирование — дисциплина очень многогранная, множество разных моделей придумано для ее описания. Думаю, важно не то, насколько точно та или иная модель описывает суть этой дисциплины, а дает ли модель пищу для ума и получения ответов.

Как, например, модель где программирование представляется как управление рисками. Ведь программирование — это во многом поиск баланса, компромисса (trade offs), а выразить этот баланс можно как раз через риски.

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


13 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Он провел параллель между решениями, которые принимает программист в процессе разработки, и управлением рисками, и отметил сходство. Я в принципе с этим согласен, хотя не совсем понятно, будет ли от этого наблюдения кому-то какая-то польза.

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

marrkiz, Прочтите комментарий самого Максима по поводу его собственной статьи:) Нет «менеджерского» и «программистского» понимания рисков (или других понятий из области разработки ПО). Есть определение, принятое всеми участниками этого процесса, и примененное именно программистами (я тоже программист, хотя и выполняю роль менеджера:)) и именно для того, что бы прогнозировать неопределенности в проекте. ЛЮБЫЕ неопределенности:) Даже самые незначительные. Но для того, что бы неопределенность (возможность), которая создает угрозу, была понятна, ее идентифицируют и оценивают. Причем, угроза не обязательно отрицательная — бывают и «хорошие» риски. Например, можно прогнозировать принятие Закона, который упростит предметную область проекта, и уберет необходимость в ряде функций (пример — налоговое право). Тогда мы прогнозируем уменьшение, а не увеличение объема работ. И это должен знать не только менеджер, а ВСЕ участники проекта (менеджер должен управлять этим процессом). Риски влияют на всех, поскольку влияют на проект в целом. И выявить определенную угрозу, и определить риск может как менеджер, так и тестировщик или внедренец. Не нужно выделять какие-то касты и правящие классы в проектах. Менеджер — такой же участник проекта, как и другие. И зависит он от всех даже больше, чем остальные от него. Не делайте из менеджера «царя горы»:) Тем более что зачастую у проекта два, а то и три менеджера, управляющих каждый своей областью ответственности. В аутсорсинге — это даже не исключение, а правило:) Ну и попытаюсь развеять последние сомнения. Вам может показаться, что работа с проектными рисками централизована, и ею в основном занимается менеджер проекта. А остальные ему только слегка помогают. Это не так! Менеджер не всегда может оценить угрозу (например, в днях, нужных на устранение последствий). Менеджер не всегда даже понимает суть технического или финансового риска. Особенно, когда проект большой и рисков много. Также, менеджер не всегда может определить что событие, которое сигнализирует о реализации риска, наступило. Этим всем занимаются конкретные специалисты, которые этот риск определили и оценили. Я, конечно, утрирую:) В нашем деле менеджер редко не является высококлассным специалистом и разработчиком в прошлом. Но все же бывают нюансы. Например, я не смог бы быть разработчиком в проекте под IBM WebSphere. Я не знаю этой технологии. Но управлять подобным проектом я бы смог:) Неполноценно, но лучше, чем многие профессионалы-разработчики в этой технологии от IBM. И конечно технологическими рисками, а также code review и design review я бы в этом проекте не занимался. Этим бы занимался специалист по IBM WebSphere:)

Я говорю о рисках в том смысле, в котором о них говорит Максим (если я правильно все понял, что он написал), мы ведь его пост обсуждаем, не так ли? Он провел параллель между решениями, которые принимает программист в процессе разработки, и управлением рисками, и отметил сходство. Я в принципе с этим согласен, хотя не совсем понятно, будет ли от этого наблюдения кому-то какая-то польза. Вы же понимаете риски в чисто менеджерском смысле, это может быть и 100% правильно, но по теме обсуждения дает мало пользы. Польза же для меня в том выводе, что программисту есть смысл познакомиться с управлением рисками (никто же не будет писать, что это нужно менеджеру, для менеджера это must), это улучшит качество его работы именно в плане написания кода и тестов.

marrkiz,

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

Мы здесь обсуждаем риски, которые используются в процессе производства ПО, или какие-то другие риски, о которых Вам что-то известно, а мне нет?:) Вы можете оценить угрозу/влияние реализованного риска на ход проекта? В противном случае это не риск;) А просто боязнь программиста допустить ошибку там, где он не уверен в своих знаниях/умениях.Давайте называть вещи своии именами. Мы ведь пожелания и тайные мысли заказчика не называем требованиями, правильно? И гениальный идеи архитектора, зарождающиееся в теплой ванной мы дизайном не зовем? Ну так и рисками всякую чушь называть не стоит:)

Не вижу никакого противоречия. Риском является невозможность выполнить ваши обязательства в силу некоторых возможных причин. Даже если вы договорились о меньших требованиях к качеству по GUI, это не означает, что как ни программируй, все равно заказчик будет доволен. Надо все далеть правильно: -) И best practices не всегда помогут. Они голову не заменяют, думать надо, и делать выбор надо, а значит и на риски смотреть. Другое дело, что те риски, который менеджер выписывает в проекте, и те риски, о которых задумается программист, могут быть очень разными.

marrkiz, «достаточно хороший софт» — это и означает качество продукта:) Это означает, что заказчик не требует абсолютно безглюковой работы определенной функции.У меня прямо сейчас есть подобный пример. Есть система, которая должна работать 24×7 в автономном режиме. Всю работу выполняют две службы. И эти службы используют определенные настройки, хранящиееся в базе MS SQL. Эта часть системы должна быть абсолютно без багов.Есть еще GUI по изменению настроек — отдельное приложение. Оно не взаимодействует со службами. Так вот его «безбаговость» не критична, что и указано в требованиях. Вполне приемлимымы считается вариант, когда приложение глюкнет, мы его перезапустим и продолжим работать. Это и есть КАЧЕСТВО! Оно не абсолютно:)

Максим, интересная и естественная идея думать о выборе, который приходится делать при программировании, как как об управлении рисками. Кажется, мы (ну я по крайней мере) именно так и делаем: взвешиваем все за и против в конкретной ситуации, соотнося выгоды и риски.Замечательное свойство разработки ПО (соглашаясь с Артуром) в том, что «треугольник» время-деньги-качество не работает. Улучшая качество, выигрываем и в других параметрах. Но это в общем. В частностях иногда нужно временно ’забить’ на качество и выдать продукт ’на вчера’, есть ведь понятие ’достаточно хороший софт’ — пользователь сможет терпеть какие-то баги, но некий функционал хочет уже сейас. Где-то таким образом можно сэкономить время за счёт качества. Вот тут то и самое время посмотреть в проектный risk log.

Jule, Качество — вне компромисов и оценок. Как можно «уменьшая качество на [что?], увеличиваем количство реализованных функций»? Качество — MUST BE. В нашем случае — это: а) соответствие ПО требованиям к нему (что проверяется тестированием) иб) соответствие процесса производства ПО требованиям к нему. Примером могут служить требования ISO 9001: 2000. RUP прекрасно адаптируется под них (как и MSF). Какое еще качество Вы предлагаете добавить к компромисам? Функция (фича, процесс) либо работает, либо не работает (работает неправильно) — это и определяет объем (scope). Если мы не можем однозначно доказать, что функция работает/неработает, значит это не функция, и сформулировали мы не требования и производим мы не тесты и вообще сделали не ПО, а «что-то», за что требуем оплату + бонусы:) И если заказчик соглашается на такое положение вещей, то простите, но он ЛОХ:)

Скакунов Александр Says: Лютий 22nd, 2007 at 15: 17> Компромис функциональность-время-деньги очевиден, а вот как оперировать > какими-либо числовыми параметрами такого компромисса — уже для меня вопрос.Всё сложнее:). функциональность-время-деньги и... качество. Выберете каких-нибудь три:)

под «программированием» я подразумевал именно то, что «принято» Lingvo. А что я хотел сказать «вообще» — сказать затруднюсь. Похоже, попал пальцем в небо.;)

akhavr,

Как, например, модель где программирование представляется как управление рисками.

Исли автор под «программированием» подразумевал то же, что и принято:

programming программирование, составление программы процесс проектирования, написания, отладки, тестирования, документирования и поддержки ПО. Термин возник в конце 1940-х годов в Англии — американцы тогда использовали слово «coding» (Lingvo)

. То это намного меньше, чем процесс разработки/производства ПО в современном его понимании. И совсем не «управление проектами» как дисциплина. Поэтому говорить о «рисках», как части программирования — это не совсем корректно. Тем более, говорить о моделях такой деятельности.Microsoft в MSF выделяет управление рисками в отдельную дисциплину и относит деятельность к кластеру «Program Management», который также включает и управление проектом (Project Management — планирование, организационные вопросы и т.п.).Другие методики/модели процесса производства ПО тоже связывают риски именно с управлением и планированием, но никак не с созданием исходного кода и дизайном классов/форм/таблиц.—Скакунов Александр, В данном случае никакой корреляции и нет. Базовый компромисс принимается в начале проекта, и определяет стратегию принятия решений. Риски от этого не зависят. Наоборот, от наличия рисков (выявленных, определенных и оцененных) тоже зависят решения и планы. А именно — пессимистическая оценка сроков и отказ от «рискованного» убыточного проекта.—В связи с этим, хочу задать автору статьи вопрос — что он имел в виду?:)

Я, честно говоря, не очень понимаю смысл выражения «управление рисками». Компромис функциональность-время-деньги очевиден, а вот как оперировать какими-либо числовыми параметрами такого компромисса — уже для меня вопрос.

Не согласен:) Best practices — это уже результат исправления ошибок проектирования (очень редко — ошибок управления и др.). Риски — это оперативное (тактическое) планирование. Из проекта в проект переходит опыт управления рисками, но не сами риски. Риски — это чистая динамика, а Best practices — это чистая статика. Нельзя их уравнивать под одну гребенку.По поводу приведенных примеров: Пример 1. Стандарты оформления исходного кода.Выбор сделан, стандарт используется. Где здесь угроза? Она исключена, значит и риска быть не может. Если мы нарушаем стандарт — это не риск, а ОШИБКА. Ошибки выявляют и исправляют:) Пример 2. Автоматизированные тесты.Выбор опять же сделан. Но! Действительно есть угроза. Угроза «непокрытия» кода тестами, и в связи с этим некачественного тестирования. Полагаемся на авто-тесты, и не тестируем ручками. Но эта угроза по сути сводится к опытности разработчика, создающего тесты. А опытность НИКОГДА не учитывается в прямых рисках, поскольку она влияет напрямую на ход проекта и на план. Вместо этого оцениваются КОНКРЕТНЫЕ пробелы в знаниях и умениях каждого разработчика, создается план обучения, и оценка задач включает оптимистический и пессимистический прогноз. А это уже планирование проекта -, а не управление рисками.Пример 3. Размножение кода (copy& paste).Как можно оценить угрозу от этого подхода к «генерации» кода? Это неизмеримо и не прогнозируемо. Риск создать код, который невыгодно поддерживать существует всегда. Но как его оценить? А это является необходимым шагом в управлении рисками. Можно просто рекомендовать разработчикам не использовать данный подход. Но есть случаи, когда он оправдан. Например, существует комплексный шаблон формы ввода, который каждый раз дорабатывают для конкретной функции. При этом нет возможности наследовать большую часть функционала. У нас в проекте есть подобное. В VS.NET 2005 появилось милое ограничение у визуальных компонент — нельзя настраивать унаследованную компоненту, содержащую свойство-коллекцию. Например, грид с его колонками. Приходится грид ложить каждый раз новый. Но в чем собственно здесь риск? Мы ведь знаем о такой специфике и само собой минимизируем ее влияние на поддерживаемость решения.Ну и про переменные. Не знаю как там в перлах/джавах и т.п., которые использует автор:) В VS 2005 комментарии к свойствам классов (=переменным) отображаются как подсказки при просмотре класса в дереве, при использовании в коде и т.п. Это очень удобно и наглядно. Конечно, называть свойства лучше так, что бы они сами себе документировали. Но использовать для этого 6−8 слов (в енумераторе и т.п.) — это слегка многовато. Поэтому можно часть названия сократить до букв, расшифровав значение в комментариях.Ну и про компромиссы (trade offs). Если каждый раз, создавая исходный код и проектируя, мы будем идти на компромисс, что это будет за решение такое?:) Не стоит усложнять и без этого сложный и творческий процесс. Есть компромиссы в организации проекта (время vs. объем vs. ресурсы/деньги), есть общие проектные риски и риски отдельной итерации/фазы. Зачем еще что-то? Что улучшит еще один уровень неопределенности? Что он даст? Гибкость подхода? Или надежность? Нет и нет. Только дополнительный расход времени и нервов.Ну и как подтверждение моих слов предлагаю автору найти методику проектирования/написания кода, основанную на рисках:) Управление проектом — это да, есть. Но не детальнее.

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