Comments on: Oracle ISV Days 2009

By: Bayram Annakov

Bayram Annakov — Thu, 28 May 2009 08:01:22 +0000

Павел, рад что нравится :)

By: @pavel_gite

@pavel_gite — Wed, 27 May 2009 19:20:24 +0000

Зачитался вашим блогом, спасибо за вашу работу.
Давно искал источник информации по построению систем.

Для меня это как пусть к истине – правде жизни. Ведь жизнь и есть система.

By: Bayram Annakov

Bayram Annakov — Mon, 25 May 2009 14:39:51 +0000

Сергей, спасибо большое! с удовольствием почитал статью про EBS: у нас в EPAM была правило про то, что задача не должна быть дольше 4 дней, хотя как я говорил на конференции для некоторых проектов адекватнее чтобы задачи были не более 1-2 дней или даже 4 часов иногда.

Еще понравилась идея приписывания времени на bug fix на время задачи, создавшей этот баг – мне это напоминает производственную систему Тойота :)

В общем, много полезных вещей в статье – спасибо!
А вот про управление рисками – мне кажется, что есть какое-то неверное мнение, что управление рисками это очень громоздкое занятие. Это как с моделированием – достаточно сделать удобный инструмент, который поможет менеджерам преодолеть барьер.. Не пробовал Oracle Risk Analysis правда, не знаю как он в деле

By: Sergey Kiselev

Sergey Kiselev — Mon, 25 May 2009 12:26:48 +0000

Для развития дискуссии. Теория Голдратта о Критической цепи в УП имеет как сторонников, так и противников. Критическая цепь в УП – это во многом “красивый” Грааль:
1. Многие из предложений Голдратта являются давно базовыми инструментами при расчетах расписаний и календарно-сетевых графиках.
2. Ориентация на максимальную задержку в выполнении заданий – увеличивает риски не выполнения задачи. Четкий план производственного предприятия творческой деятельности программистов. Поэтому расчет расписания «как можно позже» имеет возможности довести проект до полного краха. Даже с текущим состоянием дел, программирование нельзя причислить к ремесленничеству. Возможно, через 15-20 лет общий уровень поднимется настолько, что используя готовые блоки, можно будет поставить на поток 80% задач. (Интересно в этом вопросе мнение основателя компании IDS Sheer про развитие талантов программирования у менеджеров – http://www.ids-scheer.ru/ru/company/publications/35438.html, Вечные студенты).
3. Буферы – это новые сущности в УП. Компания должна понимать ответственность их использования. Например, Boeing использует у себя этот подход и отказались продуктов нашей компании. Причина банальна – большинство ПО для УП не поддерживает у себя эти сущности. Поэтому приходится использовать workarounds, усложняющие требования и понятность графиков.

По-моему мнению сейчас нужно смотреть с сторону недетермированных графиков, особенно в области разработки ПО. Очень интересная статья от Joel Spolsky про его подход к решению этой задачи используя Evidence Based Scheduling – http://www.joelonsoftware.com/items/2007/10/26.html. Сейчас управление рисками находится в зачаточном состоянии, хотя при использовании существующих программ они позволяют создавать системы, во многом схожие с подходами в Системной динамике. В частности модуль, Oracle Risk Analysis – (http://www.oracle.com/applications/primavera/primavera-risk-analysis.html).