Новости

27.01.2021

Книга «Совершенный софт»

Методология Лёве объединяет разработку систем и дизайн проектов, используя базовые принципы разработки ПО, корректные наборы инструментов и эффективные методы. Автор подробно описывает основы, на которых прокалываются многие архитекторы ПО, и показывает, как разложить систему на мелкие блоки или службы. Вы узнаете как вывести эффективный дизайн проекта из дизайна системы, как рассчитать время, необходимое на запуск проекта, его стоимость и риски, и даже как разработать несколько вариантов выполнения.

Метод и принципы «совершенного софта» можно применять независимо от размера проекта, компании, технологии, платформы или отрасли. Цель этой книги — решение важнейших задач современной разработки ПО, требующих исправления программных систем и проектов, ваш карьерный рост и, возможно, изменение всей IT-индустрии. Рекомендации и знания, которые вы получите, сэкономят десятилетия вашего опыта и спасут многие проекты. Эта книга принесет большую пользу разработчикам, архитекторам, руководителям проектов или менеджерам на любом этапе карьеры.

Расширенные методы планирования

Планирование проекта — весьма нетривиальная дисциплина, и в предыдущих главах
рассматривались только базовые концепции. Это было сделано намеренно, чтобы не создавать избыточных сложностей на начальном этапе. Однако область планирования проекта этим далеко не ограничивается, и в этой главе будут представлены дополнительные методы, которые принесут пользу практически в любом проекте, а не только в самых крупных или сложных. У всех этих методов есть кое-что общее: они позволяют лучше управлять риском и сложностью. Вы также увидите, как успешно справляться даже к самыми сложными и проблематичными проектами.

Божественные активности


Как следует из названия, божественные активности слишком велики для вашего проекта. Возможно, термин «слишком велики» нужно рассматривать как относительный — божественная активность слишком велика в отношении других активностей в проекте. Простой критерий для выявления божественных активностей — наличие активности, продолжительность которой отличается от средней продолжительности всех активностей проекта как минимум на одно стандартное отклонение. Впрочем, божественные активности могут быть слишком большими и в абсолютном отношении. Продолжительность в диапазоне 40–60 дней (и более) слишком велика для типичного программного проекта.

Возможно, ваши интуиция и опыт уже подсказывают вам, что от таких активностей стоит держаться подальше. Как правило божественные активности становятся обычными заполнителями для некой великой неопределенности, скрывающейся под ними. Оценки продолжительности и трудозатрат для божественной активности почти всегда имеют низкую точность. Соответственно, фактическая продолжительность может оказаться длиннее — теоретически достаточно для того, чтобы загубить проект. С такими опасностями следует разбираться как можно раньше, чтобы у вас сохранялись шансы выполнения своих обязательств.

Божественные активности также нередко искажают методы планирования проекта, описанные в книге. Они почти всегда являются частью критического пути, в результате чего многие методы управления критическим путем становятся неэффективными, потому что продолжительность критического пути и его положение в сети смещаются к божественным активностям. Ситуация усугубляется тем, что модели риска для проектов с божественными активностями выдают обманчиво низкие значения рисков. Большая часть усилий по такому проекту будет потрачена на критические божественные активности, в результате чего проект во всех практических отношениях станет проектом с высоким риском. Однако вычисление риска даст заниженные результаты, потому что другие активности, окружающие критические божественные активности, будут иметь высокий временной резерв. Если убрать эти окружающие активности, то риск моментально вырастет до 1,0 — правильный признак высокого риска, возникающего при использовании божественных активностей.

Решение проблемы божественных активностей


Лучший план действий с божественными активностями — разбиение их на меньшие независимые активности. Разбиение божественных активностей значительно улучшит качество оценки, сократит неопределенность и предоставит правильное значение риска. Но что, если объем работы будет действительно огромным? Такие активности следует рассматривать как мини-проекты и заняться их уплотнением. Начните с выявления внутренних фаз божественных активностей и поиска возможностей параллельной работы в этих фазах внутри каждой божественной активности. Если это невозможно, попробуйте сделать божественные активности менее критическими, убрав их с пути других активностей в проекте. Например, разработка имитаторов для божественных активностей снижает зависимости других активностей от самих божественных активностей. Это позволит организовать работу параллельно с божественными активностями, что сделает их менее критичными (или вообще некритичными). Имитаторы также сокращают неопределенность божественных активностей, так как устанавливаемые ими ограничения раскрывают скрытые предположения; это упрощает подробное проектирование божественных активностей.

Также следует рассмотреть возможности выделения божественных активностей в самостоятельные второстепенные проекты. Выделение во второстепенный проект особенно важно в том случае, если внутренние фазы божественной активности последовательны по своей природе. Это значительно упрощает управление проектом и отслеживание прогресса. Обязательно спланируйте точки интеграции в сети, чтобы сократить риск интеграции на завершающей стадии. Выделение божественных активностей подобным образом обычно повышает риск для остальной части проекта (после извлечения божественных активностей на долю других активностей остается намного меньший временной резерв). Обычно это хорошо, потому что в противном случае проект имел бы обманчиво низкие показатели риска. Ситуация встречается настолько часто, что низкие показатели риска часто указывают на то, что вам стоит заняться поиском божественных активностей.

Точка пересечения риска


В примере из главы 11 для включения и исключения вариантов планирования проекта использовались простые правила: риск должен быть ниже 0,75 и выше 0,3. При принятии решений о вариантах планирования можно действовать с большей точностью, не ограничивающейся простейшими правилами. На рис. 11.33 в точке минимума прямых затрат и непосредственно слева от нее кривая прямых затрат практически горизонтальна, но кривая риска имеет значительный угол наклона. Такое поведение ожидаемо, потому что кривая риска обычно достигает своего максимального значения до того, как прямые затраты достигнут своего максимума в решениях с наибольшим уплотнением. Единственная возможность достичь максимального риска до максимума прямых затрат — если изначально слева от минимума прямых затрат кривая риска растет намного быстрее кривой прямых затрат. В точке максимального риска (и немного справа от нее) кривая риска горизонтальная или почти горизонтальная, тогда как кривая прямых затрат имеет достаточно крутой угол наклона.

Отсюда следует, что слева от минимума прямых затрат должна существовать точка, в которой кривая риска прекращает расти быстрее кривой прямых затрат. Я называю эту точку точкой пересечения риска. В этой точке риск достигает максимума. Отсюда следует, что вам, вероятно, следует избегать уплотненных решений со значениями риска выше точки пересечения. В большинстве проектов точка пересечения риска совпадает со значением 0,75 на кривой риска.

Точка пересечения риска консервативна, потому что она не находится на максимуме риска, и при этом она базируется на поведении риска и прямых затрат, а не на абсолютном значении риска. Отсюда следует, что с учетом истории многих программных проектов некоторая доля осторожности никогда не повредит.

С полным содержанием статьи можно ознакомиться на сайте "Хабрахабр":

https://habr.com/ru/company/piter/blog/538528/


Комментарии: 0

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


Оставить комментарий






CAPTCHAОбновить изображение

Наберите текст, изображённый на картинке

Все поля обязательны к заполнению.

Перед публикацией комментарии проходят модерацию.