Oracle ISV Days 2009


Автор:

Выкладываю презентации с моих докладов на Oracle ISV Days 2009:

Ненормальные методы управления проектами
Управление распределенными командами

Оформить и получить займ на карту мгновенно круглосуточно в Москве на любые нужды в день обращения. Взять мгновенный кредит онлайн на карту в банке без отказа через интернет круглосуточно.


Тэги: ,

categories Для любопытных, Новости | | datetime May 25, 2009 11:33 am

4 отзывов

  • By Sergey Kiselev, May 25, 2009 @ 3:26 pm

    Для развития дискуссии. Теория Голдратта о Критической цепи в УП имеет как сторонников, так и противников. Критическая цепь в УП – это во многом “красивый” Грааль:
    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).

    Ответить

    Bayram Annakov Ответ:
    May 25th, 2009 at 5:39 pm

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

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

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

    Ответить

  • By @pavel_gite, May 27, 2009 @ 10:20 pm

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

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

    Ответить

    Bayram Annakov Ответ:
    May 28th, 2009 at 11:01 am

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

    Ответить

Ссылки на эту статью

Оставить отзыв

WordPress Themes