XML OLTP Утопия
Сказка ложь, да в ней намек
Добрым молодцам урок
Продолжая тему Карра работаю над утопией быстрого построения OLTP приложений. ИТ становится дешевым товаром и XML здесь играет свою роль.
Брукс кончено был прав, что в ближайшие Икс лет (не помню цифр, кажется книга была в 75, прогнозировалось 15 лет и в 95 его же статься подтверждающая прогнозы) не произойдет взрыва производительности труда программистов. Однако в дополнение к разнообразным компонентам и библиотекам появляются целые стандартизированные области и законченные структуры данных, готовые к употреблению из коробки. К таким вещам можно отнести UBL - бесплатную библиотеку стандартных электронных XML бизнес-документов. Напомним немного что это такое ссылкой.
Если сегодня строить бизнес-систему, то почему бы не взять за основу UBL? Что нам это даст? Сначала конечно стандартные XSD схемы бизнес-документов. Вторым важным готовым элементом будут XForms произведенные на основе UBL схем (free-ubl-kit).
Постоянное хранение - Xml СУБД. Исключительно в качестве эксперимента хочу пробовать в ближайшее время Sedna и Xml-Xindice. Отображение XFroms Apogee / Orbeon. Apogee немного потрогал - довольно просто получается. Пугает пока только, что вестей по проекту нету. Из основного осталось построить списки, но думаю, что это самая простая из проблем.
Процессы и Бизнес-правила пока под вопросом, т.к. UBL определяет свои схемы процессов, с которыми пока не ознакомился, но связи с BPEL какие-то существуют и думаю со временем будут укрепляться (сладкое слово стандарты).
И конечно же бизнес-приложению нужны отчеты на основе Xml, и они тоже есть - это BIRT (JDBC, XML, Web Services, and Flat File support, as well as support for using code to get at other sources of data).
Довольно перспективная идея автоматической генерации мощных приложений, т.к. все технологии для этого как бы уже есть. XSD, XForms, XMLDB вообще не вызывают проблем (разве что с производительностью). Сомневающимся предлагаю посмотреть простой кусок кода по отображению XForms из SWT и небольшую статейку по использованию Xindice.
Вот почему таких приложений пока нету, хотя все технологии готовы? Никому не нада? Никто не верит? Ни у кого нету комплекса необходимых знаний? Как по Карру, так такое бы рынок ИТ в плане бизнес-приложений то и пообрушило ... Ищу спонсоров 
----------
Фитнесс и бодибилдинг сделают ваше тело стройным, избавят от болезней и помогут освободиться от излишков веса.
Оставляя Delphi
Сидя на красивом холме
видишь ли ты то что видно мне
в игре наверняка что-то не так
(С) Б.Г.
Смотрю со стороны за своей блого-деятельностью и вижу как она постепенно превращается из развлечения в какую-то обязанность. Просто чувствую, что нужно высказаться по определенному вопросу ...
Появилось несколько интересных новостей, звезды выстроились в необходимом порядке и вот случился этот пост. Давно не заходил на delphiplus.org (когда-то посещал его постоянно) но вот недавно зашел и увидел две интересные новости - (1) появился наконец официальный dbExpress драйвер под Firebrid (2) Peter Morris бросает свои открытые Delphi-проекты и переходит на C#. И вот закончилось оценкой Eclipse Foundation совместно с IDC Обзор итогов работы сообщества Eclipse.
Еще менее года назад я был просто программист Delphi. Вокруг бушевали страсти по .Net и Java, Borland становился CodeGear и давно подсел на .Net, многие знакомые свернули Delphi проекты и пересели на C#. И глядя на статистику предложений о работе казалось вполне естественным экономическим шагом тихонько перейти на C# ... Немного поразмышляв об этом я понял простую истину - деньги там где Enterprise. На Delphi его никто его не делает и значит денег здесь гораздо меньше. Кстати забегая на перед скажу что никто из оставивших Delphi и ушедших в C# не жалел, а наоборот, восхищался даже просто возможностями среды.
Сегодня кстати наступила некоторая Delphi усталось что-ли ... В СНГ было сделано много внутренних проектов, программисты потихоньку мигрировали в Java и С#, и сегодня найти адекватных Delphi программистов становится проблемой. Вспоминается Cobol и С++ пару лет назад. Это хорошо для delphi разработчиков - наконец они могут немного покачать права и добиться большего вознаграждения. В Киеве уже например вполне реально получит зарплату в 1200 у.е. или может даже больше.
Но речь не о С#. Что самое неприятное, оставаясь на Delphi вы просто игнорируете огромные возможности производительности просто за счет использования готовых и часто открытых решений, которые не успевает или не хочет внедрять CodeGear. Размер сообщества среды и технологий разработки дает о себе знать, как никогда раньше. А в Delphi с этим Застой.
На самом деле до момента денег я не рассматривал всерьез перехода на новую платформу разработки. В конце концов появился Turbo Explorer и можно было наконец заниматься разработкой бесплатно.
Подсел на Borland я еще в школе - во времена TurboPascal 5.5 и Turbo C 2.0. В институте в 1992 компьютеров было мало и доступ был сильно ограничен. Да и после школьных IBM PS2/30 на Искре даже неприятно было на кнопки нажимать ... Я забросил программирование на несколько лет и вернулся уже где-то в 97-98 уже немного на Delphi 4.0 и потом как-то сразу на 5.0. Тогда я конечно был поражен и засел за изучение VCL... В общем дальнейшие почти 10 лет были плотно связаны с Delphi, но прозрение все-таки наступило, пусть и не так скоро как хотелось бы.
Манил веб и кросс-платформенность и перед отпуском я скачал Eclipse 3.2 SDK. Никаких быстрых движений я тогда особо не планировал, но потихоньку пробовал делать тоже самое что и на Delphi. Начал я с изучения справки по Eclipse JDT - читаю справку и повторяю в среде то что там написано. Кстати есть русский перевод 2005 года может кого заинтересует. И чесно сказать был поражен возможностями и удобством среды по работе с исходным кодом. Именно этот тот предпоследний день отпуска, потраченный на изучение Eclipse JDT, наверное и есть та точка в пространстве и времени, которая отвратила меня от Delphi. Потом уже были RCP, менеджер обновлений, огромное количество подключаемых модулей ... потом - для первого же увлечения хватило возможностей редактора кода! После этого, особо не обращая внимания на Eclipse, я поработал с Delphi еще пару месяцев и затем уволился... немного поработал с J2EE и JSF, сделал пару мелочей на C# Developer и стал аналитиком.
Сегодня я мало программирую, но технологиями немного интересуюсь. Как видно из моих последних постов мне интересны XML технологии - BPM, XSD, XForms, XML DB - и мне кажется это естественным. Даже если бы я и захотел делать свои изыскания на Delphi то просто не нашел бы поддержки этих технологий в самом продукте. Это даже без обид Petera Morisa ...
Однако хочу также заметить что Together остается передовым средством моделирования, JGear тоже выглядит довольно приятно. Т.е. не стоит сбрасывать Borland и CodeGear со счетов вообще, но целиком они уже не поспевают. Ну и конечно OpenSource ... в мире караоке-капитализма капиталист должен что-то давать обществу и IBM, Sun, много кого еще дают, а Borland как-то не очень.
Service Data Objects (SDO) 2.0
Даже странно подумать, что раньше
Каждый шел как хотел, а теперь
Паровоз, как мессия, несет нас вперед
По пути из Калинина в Тверь.
(С) Аквариум
Последнее время много времени провожу в поисковой строке гугла. Дай людям поиск и что они будут делать? Конечно же искать!
Последними XML постами я пытался показать одну мысль - современные корпоративные приложения обмениваются данными, и в 99% случаев это XML - стандарт де-факто для взаимодействия приложений через web. Сказать только одно слово "XML" будет слишком большим упрощением здесь нужно добавить немного страшных слов типа XSD, WSDL, XSL, XFoms, XPath и XQuery. И это далеко не полный список... а еще недавно хватало простого SQL и он пока не отменяется. XML сегодня определяет не только данные, но и метаданные, а также стандартные способы манипуляции этими данными и метаданными.
В общем натолкнулся на статью - Service Data Objects (SDO) 2.0: Создание и чтение документа XML на основе схемы XML. Понравился мне там примерчик - как легко в стиле RowSet можно работать с XML экземплярами не отвлекаясь на DOM/SAX.
Интерфейсы SDO 2.0 предоставляют единообразный способ создания данных и доступа к ним, а также избавляют разработчиков от необходимости подробной разработки процедур парсинга и поддержки целостности данных. На сегодняшний день SDO 2.0 является инкубаторным субпроектом (под названием Tuscany) организации Apache Software Foundation, цель которого - стать де-факто стандартным интерфейсом программирования моделей данных для разработки SOA.
.. интерфейсы SDO 2.0 полностью избавляют вас от необходимости знания и использования API парсера XML для чтения, записи и управления данными. Если вы создаете на Java DataObject, представляющий данные XML в соответствии с определенной вами схемой XML, SDO 2.0 обеспечивает вам удобство и гибкость, позволяя сконцентрироваться непосредственно на работе с данными. В результате этот API предоставляет значительные преимущества, заключающиеся в повышении производительности разработки и качества продукта.
Затем сходил на сайт продукта Apache Tuscany и это не только прозрачная работа с XML - файлами а еще с Data Access Services (DAS) и Service Component Architecture (SCA)... В общем всем кто работает с XML на Java рекомендую посмотреть. Хочу обратить внимание на простоту работы - оказывается для всей работы хватает всего трех элементов
---
Холодильные шкафы, камеры морозильные и льдогенераторы для магазина или склада продуктов вы всегда можете купить у компании «Холод-Торг»
Улетное секс видео со страстными латинками, сисястыми азиатками и крикливыми ниггершами ждет тебя на эротическом портале ebemsa.com. Просмотр всех роликов бесплатен, здесь нет никаких платных аккаунтов и доступа через СМС!
Принципы независимости бизнес-правил
Вчера попал на Манифест бизнес-правил - решил что это довольно важный документ для понимания темы BRMS и попытался перевести. Замечания и предложения по переводу приветствуются.
The Business Rules Manifesto
Статья 1. Первичные требования, а не вторичные
1.1. Правила это элита граждан мира требований.
1.2. Правила неотъемлемая, а не дискретная часть, бизнес-моделей и технологических моделей.
Статья 2. Отдельны от процессов и не заключены в них
2.1. Правила - четкие ограничения на поведение и/или оказывают поддержку поведения.
2.2. Правила не являются процессом или процедурой. Они не должны включаться в эти понятия.
2.3. Правила применяются вокруг процессов и процедур. Должен быть один последовательный свод правил, исполняющийся последовательно во всех соответствующих областях бизнес-деятельности.
Статья 3. Хорошо продуманные знания, а не побочный продукт
3.1. Правила опираются на факты, а факты опираются на понятия выраженные в условиях.
3.2. Условия выражают бизнес-концепции; факты утверждают эти концепции, правила ограничивают и поддерживают эти факты.
3.3. Правила должны быть ясными. Правило не всегда предполагает какую-либо концепцию или факта.
3.4. Правила являются базовыми для понимания бизнесом самого себя - то есть, основным бизнес-знанием.
3.5. Правила должны быть развитыми, защищенными и управляемыми.
Статья 4. Декларативные, не процедурные
4.1. Правила должны выражаться в описательных предложениях на естественном языке деловой аудитории.
4.2. Если что-либо не может быть выражено, то это не правило.
4.3. А набор высказываний декларативный, только если набор не поразумевает последовательность.
4.4. Любые утверждения о том, что правила требуют других конструкций, помимо терминов и фактов, означают предположения о внедрении системы.
4.5. А правило не зависит от каких-либо воздействий, определенных для него. Правило и его воздействие - отдельные проблемы.
4.6. Правила должны определяться независимо от ответственности за то "кто", "где", "когда" и "как" их выполняет.
4.7. Исключения из правил выражаются другими правилами.
Статья 5. Правильно-сформированные выражение, не специальные
5.1. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены на корректность деловыми людьми.
5.2. Бизнес-правила должны выражаться таким образом, чтобы они могли быть проверены в отношении логичность друг к другу.
5.3. Формальная логика, например, логика предикатов, имеет основополагающее значение для правильно-сформированных выражений правил в терминах бизнеса, также как и технологий, обеспечивающих реализацию бизнес-правил.
Статья 6. Архитектура основанная на правилах, не косвенная реализация
6.1. Приложения бизнес-правил намеренно построена с учетом непрерывных изменений в бизнес правилах. Платформа, на которой запускается приложение должна поддерживать такие непрерывные изменения.
6.2. Непосредственно выполнение правил - например, в машинах в правил - лучше реализации стратегии переписывания правил в различные процедурные формы.
6.3. Система бизнес-правил должна всегда быть в состоянии объяснить рассуждения, с помощью которого она приходит к заключения или принимает решения.
6.4. Правила основаны на значениях истинности. Определение или поддержка значение истинности скрыто от пользователей.
6.5. Отношения между событиями и правилами, обычно, как многие-ко многим.
Статья 7. Процессы ведомые правилами, а не программирование основанное на исключениях
7.1. Правила определяют границу между приемлемой и неприемлемой деловой деятельностью.
7.2. Правила часто требуют особой или выборочной обработки обнаруженных нарушений. Такие правила нарушения деятельности есть деятельность, такая же как и любая другая.
7.3. Для обеспечения максимальной согласованности и повторного использования, обработки неприемлемой деловой деятельности должна быть неотделима от обработки с приемлемой деловой деятельности.
Статья 8. Во имя бизнеса, а не технологии
8.1. Правила касаются бизнес практики и руководства; поэтому, правила диктуются бизнес-целями и задачами, и формируется под влиянием различных воздействий.
8.2. Правила всегда стоят что-то бизнесу.
8.3. Стоимость исполнения правила должна быть сбалансирована с бизнес-рисками, и в отношении упущенных коммерческих возможностей.
8.4. Обычно меньшее количество "хороших правил" лучше чем "больше правил" вообще.
8.5. Эффективная система может основываться на небольшом количестве правил. В дополнение, большеинство специфический правил можно добавить потом, так что со временем система будет становиться умнее.
Статья 9. От бизенса, к бизнесу, и для людей бизнеса, не для людей ИТ
9.1. Правила должны возникать от знающих людей бизнеса.
9.2. Люди бизнеса должны иметь инструменты, помогающие им формулировать, утверждать и управлять правилами.
9.3. Люди бизнеса должны иметь инструменты, помогающие им проверять логичность бизнес-правил по отношению друг-к-другу.
Статья 10. Управление бизнес-логикой, а не аппаратно-программной платформой
10.1. Бизнес-правила являются жизненно важных бизнес-активом.
10.2. В долгосрочной перспективе, правила являются более важными для бизнеса, чем аппаратно-программные платформы.
10.3. Бизнес-правила должны быть организованы и храниться таким образом, чтобы их можно было легко перевести на новые аппаратно-программные платформы.
10.4. Правила, а также возможность эффективного изменения, имеют основополагающее значение для улучшения адаптивности бизнеса.
Version 2.0, November 1, 2003. Edited by Ronald G. Ross.
Copyright, 2006. Business Rules Group.
Simple Brillants
Фергюс О'Коннел "Simple Brilliant. Все гениальное просто".
До того как мне предложили эту вещь был знаком с его "Управление проектами Серебрянная пуля" и взял "за глаза" не смотря на цену и объем. Простотой подкупила первая книга. Вот кстати отличная обзорная статья
1. Многие вещи просты и первый принцип гласит: нужно избегать сложности
и стремится к простоте. Ищите самые простые решения. Для уже имеющихся решений ищете способы их еще упростить.
2. Важно иметь представление о том, что вы собираетесь сделать
"Если вы не знаете в какой порт плывет ваш корабль - любой ветер будет для вас попутным."
поймите, что вы пытаетесь сделать (цели);
узнайте, хотят ли все того же самого (максимизация благоприятных условий для всех участников);
следите за изменениями того, что вы пытесь сделать (если цели изменились пройдите еще раз пункт максимизации благоприятных условий).
3. Всегда существует последовательность событий.
Когда вы пытаетесь что-либо сделать обязательно существует последовательность событий. Знание этого факта приводит к планированию, расстановке приоритетов, поиску оптимальных путей.
мысленно пройдите весь путь от начала до конца (план проекта);
пройдите путь, акцентируя внимание на мельчайших деталях (детализация);
используйте свои знания и предположения;
пересчитайте кирпичики в стене (повторяющиеся действия);
всегда существует другое решение (альтернативный план);
записывайте то, что происходит на самом деле (история и чужой опыт);
старайтесь найти взаимосвязь вещей.
4. Задания не выполняются, если люди их не выполняют
Здания не будут выполнены, если не будут их выполнять. Если большое количество задач
останется невыполненным, то все пойдет на перекосяк. Есть масса причин ко которым это
может происходить:
неразбериха - люди не знали что они должны были что-то сделать, или не знали что именно им следовало сделать;
черезмерная загруженность - задачи есть, но нет времени на их выполнение;
некомпетентность - нет опыта, навыков или необходимого уровня знаний для решения конкретной задачи.
Лечить назначением конкретного исполнителя для каждой задачи. Обеспечение высокого профессионального уровня коллектива.
Карточки танцев - полный учет времени по задачам
проекты\всего\интервал1\интервал2
---------------------------------
проект1 20 10 10
проект2 25 10 15
... .. .. ..
---------------------------------
итого: 45 20 25
Таблицы с планками - кто чем занимается
---------------------------------
дата / состав исполнителей (задача)
исполнитель1 / исполнитель2 / ...
---------------------------------
1 задача1 задача2
2 задача2 -
оптимизация времени
- сокращение времени на типичные задачи, например почту, телефон, совещания ..
- не выполнять вообще некоторые задачи
Последствия давления по Deadline Де Марко
Скорость мышления людей, когда на них оказывают давление, не становится быстрее.
Увеличение сверхурочной работы - тактика, ведущая к снижению производительности труда.
Сверхурочное время может оказаться полезной тактикой (концентрация усилий, осознание важности), но оказывать давление длительное время это ошибка.
Пожалуй, руководители слишком часто прибегают к оказанию давления, потому что не знают, что еще можно сделать, или же их пугают трудности альтернативных подходов.
Ужасное подозрение: что если настоящая причина оказания давления и принуждения сотрудников работать сверхурочно, не что иное как способо выставить себя в лучшем свете, когда проект пойдет под откос?
Учет времени на помехи и внесение их в план\карточку танцев
5. Редко все получается так, как ожидалось.
В жизни всегда есть место для непредвиденных обстоятельств. Нужно свести к минимуму их количество и возможные последствия. "Если вы не будете вести активное наступление на риски, то риски будут сами активно атаковать вас" Том Джилб
Всегда обещайте меньше чем выполняете.
Добавьте резерв в проект.
Управляйте рисками.
6. Вещи либо есть, либо их нет
Вещи либо есть, либо их нет. Также и работа - либо сделана, либо нет. Задания нужно дробить на элементарные составляющие, так чтобы можно было точно сказать выполнена задача или нет.
7. Взгляните на проблему с точки зрения других людей
Практически в любом из наших заданий и проектов неизбежно участвуют другие люди.
Умение рассматривать любые вопросы с точки зрения других людей может помочь нам
правильно понять и выполнить любое задание.
Если люди относятся к заданию положительно и у них высокая мотивация, они могут
буквально свернуть горы.
Станьте на место других людей. Полезная привычка - умение мыслить так, чтобы в выигрыше оставались все вовлеченные в это дело стороны. Увеличивайте до максимума благоприятные условия для всех участников совместного дела. Убедитесь, что все хотят именно того, чего хотите добиться вы.
Mobile-ON - все про сотовые телефоны, и для них: темы, игры, картинки. Узнай все про мобильные телефоны ведущих брендов: Нокиа, Сони Эриксон
Для московской компании «Latini» лучшие кухни на заказ поставляются со знаменитых итальянских фабрик. Специалисты «Latini» помогут вам не только выбрать подходящую кухню, но и выполнить дизайн проект квартиры.
Для того чтобы стать начальником нужно вести себя так как ведет начальник. И завести два пиджака, один из которых будет на вас, а другой на спинке вашего стула создавать постоянную видимость присутствия. (Стул в моем пиджаке скажет: "Вышел. Весь вышел, не знаю когда и прийдет").
Во какие мысли лезут в голову простому украинскому безработному в это не по-зимнему сырое январское утро. По радио Чай-Ф "у судьбы как у трамвая жизнь кольцо .. быть первым как и тот что тащится за ним, впереди только рельсы и провода". Вспоминается летний утренний вид 1993 года на салтовку из 802 расширителя. Привет, Длинный!. Утро перед практикой после первого курса, или утро после посиделок до утра с Вовой, Бортником и Ткаченко - "ростер" и бутерброды с тушенкой
"Молодые львы .. они свободны от наших потерь, и им нечего делать с собой сейчас - они войдут когда Екатерина откроет им дверь."
"Я пишу эти песни в конце декабря, голый в снегу при свете полной луны... но если ты меня слышишь наверное это не зря" - какой контраст однако. И Рыжая на балконе квартиры Длинного в Мелитополе с грустно смешной фразой: "Где мои шестнадцать лет" ...
Вот же будит воспоминания музыка. Ловлю себя на том, что в последнее время музыку почти не слушаю, хотя старательно собираю все на компьютере. А тут включил JAM FM и протащился. Ночью репертуар гораздо ближе.
Вальсируя с медведями - Проекты на выживание
"В этих случаях непоколебимая жертвенность непреложно требуется от всех до одного участников проекта. Проект требует забросить личную жизнь, бесконечно работать сверхурочно, проводя субботы и воскресенья в офисе, отделиться от семьи и т.д. Неприемлемо ничто меньшее , чем полное посвящение себя проекту.
Оправдание этих жертв всегда апеллирует к важности проекта: это так важно и необходим, что требует предела возможного от персонала проекта. Но есть нечно загадочное в этом утверждении. Если этот проект так важен, почему компания не может потратить время и деньги, необходимые для его нормального осуществления?
По нашему опыту, единственной общей характеристикой таких проектов является низкая ожидаемая выгода. Это проекты, на выпуск продуктов монументальной незначительности. Единственным реальным обоснованием проектов на выживание является то, что выгода столь мала, что нормальное выполнение проекта явно привело бы к затратам, которые будут больше выгоды. Только героическими усилиями можно надеятся заставить свинью летать.
Второй характеристикой проекта на выживание является одурачивание людей, чтобы заставить их принести свою личную жизнь в жертву компании, убедив, что только это может привести к успеху, поскольку выгода столь крохотная, что осмысленным будут только самые низкие затраты.
Третья характеристика такого проекта состоит в том, что они почти всегда кончаются полным фиаско, не создав ничего или почти ничего (обычно при затратах выше среднего) и заставив всех чувствовать себя одураченными и озлобленными. Должен быть выход лучше."
ЗЫ. Книжка довольно интересная. Обязательно вернусь и опишу подробнее как появится время. Интересна прежде всего тем, что она не только о рисках, а как всегда при разработки ПО случается, касается еще кучки маленьких бездн. Тут много теории вероятности применимой как к рискам так и к ожидаемой окупаемости и еще много интересных наблюдений и статистики.
Теория W
Открытые системы #05/2003
Человеческий фактор в управлении ИТ-проектом
Теория W
В 1989 году Барри Боэм и Рони Росс описали парадигму управления программным проектом, получившую название Теории W («Theory-W Software Project Management: Principles and Examples», IEEE Trans. Software Eng., July 1989). Для каждого проекта, согласно Теории W, следует создавать взаимовыгодные условия, формировать такой же процесс и производить взаимовыгодный продукт.
Взаимовыгодные условия. Те, кто создает взаимовыгодные условия, понимают, что самые лучшие рабочие взаимоотношения — это те, выигрыш от которых может получить каждый. Ничья, проигрыш одних и выигрыш других могут озлобить одну или обе стороны, поэтому лучше пытаться создавать взаимовыгодные ситуации. Сделать можно это следующим образом.
Понять, что каждый хочет выиграть. Выяснить, какая для каждого отдельного человека ситуация будет выигрышной. Для большинства людей выигрыш означает деньги, власть и признание, но есть и другие, менее очевидные условия, такие как удовольствие от своей работы, чувство причастности и моральное удовлетворение.
Формировать разумные надежды. Необходимо создавать разумные и взаимно осуществимые ожидания в каждом аспекте человеческих отношений. Гарантировать, что постановка задач для каждого конкретного человека будет способствовать формированию выигрышной для него ситуации.
Способствовать общению. Создать атмосферу, поддерживающую выигрышные для сотрудников условия. Такая атмосфера может проявляться в разных формах, таких как материальные стимулы, групповая деятельность и общие беседы, позволяющие устранить проблемы.
Взаимовыгодный процесс. Создание такого процесса означает внедрение системы, которая приведет к успеху. Сюда относится реалистичное планирование процесса на основе определенной стандартной методологии, будь то внутренняя, общекорпоративная или готовая.
Крайне важно руководить ИТ-проектом, опираясь на план. Недаром говорят, что «план — ничто, а планирование — все». «Слишком часто менеджеры разрабатывают план для того, чтобы проект одобрило руководство или заказчик, а затем, после того, как проект утвержден, забывают о плане. Наоборот, они должны использовать и поддерживать план на всем протяжении срока существования проекта.
Как менеджеру проекта вам необходимо помнить о рисках, которые могут привести к общему проигрышу. Убедитесь, что вы представляете себе эти риски и приняли необходимые меры для того, чтобы избавиться от них как можно скорее. К примеру, решая поручить задание одному сотруднику, а не другому, вы создаете ситуацию, в которой один оказывается в выигрыше, а другой — в проигрыше. В этом случае следует поговорить с человеком, которому было отказано, для того, чтобы объяснить ему причины принятия такого решения и подтвердить его состоятельность. Точно также человек, который получил задание, должен понять причины этого, причем его следует предупредить, что не следует вести себя так, чтобы его «победа» вызвала чью-то обиду. Ему необходимо объяснить значимость другого сотрудника и необходимость привлекать его к выполнению полученного задания там, где это возможно.
Не менее важно не забывать о людях. Это улучшает взаимоотношения и позволяет добиваться того, чтобы все сотрудники принимали участие в работе группы. Прислушайтесь к советам других членов группы; скорее всего, у них есть великолепные идеи.
Взаимовыгодный продукт. Создание взаимовыгодных программных продуктов связано с процессом подготовки спецификации. Главное здесь — согласование выигрышных условий для пользователей и специалистов, поддерживающих программное обеспечение. Этот процесс предполагает тщательно выверенное формулирование возлагаемых на продукт надежд.
Теория W может оказаться адекватной для ситуации с рестораном, поскольку она согласуется с описанной ранее успешной стратегией. Вдобавок, если организовать согласованную, приятную работу для поваров и сотрудников и столь же приятные условия отдыха для клиентов, причем все это с четко продуманной направленностью ресторана и его популяризацией, то успех вероятен, если не возможен.
Должен быть один руководитель
"Лидер проекта". Это титул, который легко ложится на плечи подобно хорошему пальто. Мы становимся чуть выше от ответственности и нагрузки, которую мы теперь несем. Да действительно мы можем всегда указать руководителя проекта - если даже нет других признаков, мы всегда можем его отличить по походке!
.. не столько человека с титулом, сколько человека, который твердо намерен осуществить проект. Он живет, ест и дышит проектом. Он намерен выполнить его или умереть. В любое время он держит руку на пульсе проекта и знает как он идет... Весьма неверна интерпретация его как человека, чей зад пришпилен к проекту и кого обязательно уволят, если проект не будет сделан.
Одна из вещей, которая может случится с вами как с руководителем проекта, состоит в том, что ваше лидерство может оспариваться другим членом команды. Это означает что кто-то еще пытается стать неформальным лидером проекта и отобрать у вас власть. Если это произойдет вы должны нейтрализовать вызов.
Фергус О'Коннэл "Как успешно руководить проектами. Серебрянная пуля"
Армия это не только красивое слово, но еще и быстрое дело
Прапорщик Казаков, х/ф "ДМБ"
Есть тут очень интересный момент - это объем усилий, затрачиваемых на руководство проектом. Как правило он составляет 6-8% общих усилий по проекту. Несложно посчитать, что для больших проектов, один человек физически не сможет справиться с руководством. Тогда и появляются иерархии.
Не помню точно какое количество человек является оптимальным для проекта, по Бруксу кажется не более 10.
Вообще мне не кажется однозначным это утверждение. Возьмем например совет по управлению изменениями. Т.е. дело вроде меньшее чем руководство проекта, но требуется совет!
Все-таки я думаю что это сказано про технического руководителя. Есть ведь еще рукводитель/консультант от бизнеса. Который участвует в определении приоритетов и помощи в спорных ситуациях. В общем мне кажется тема до конца не раскрыта ... возможно специально упрощена... Также руководство экстремальных методологиях хочется поднять.
Как закончу пересмотр книги попытаюсь сделать полномасштабный обзор. Смотрел внешние ссылки на блог - кто-то порекомендовал ознакомится с моим непредвзятым мнением. Спасибо! Попытаюсь радовать обзорами и дальше. Действительно есть некоторое количество книг, которые для айтишника прочесть крайне желательно. И сталкиваюсь что многие просто не слышали ни Брукса, ни Де-Марко и даже Боэма. Откровения приходят и в 30 лет и наверное даже позже... "Радости профессии" и "Метод БигБук" Брукса способны пробуждать чувства даже у взрослых айтишников
Большинство книг повторяет одно и тоже и в общем случае, если читал одно - второе , третье .. десятое можно пропустить. Но есть некоторые с совсем противоположным вектором. Так например пока большинство бродит среди призраков сроков, бюджета и функциональности, Купер говорит, что хороший продукт рынок может и подождать.
Адаптивное планирование
Мартин Фаулер, Основы UML, третье издание
Эта школа поддерживает адаптивное планирование в соответствии с утверждением, что прогнозируемость это иллюзия. Вместо того, чтобы дурачить себя иллюзорной предсказуемостью, мы должны повернуться лицом к реальности постоянных изменений и использовать такой подход в планировании, при котором изменение в проекте является величиной постоянной. Это изменение контролируется таким образом, чтобы в результате выполнения проекта поставлялось как можно лучшее программное обеспечение; но хотя проект и контролируем, предсказать его нельзя.
Различие между прогнозирующим и адаптивными проектами проявляется разными путями, когда люди говорят о состоянии проекта. Когда утверждается, что выполнение проекта идет хорошо, поскольку работа ведется в соответствии с планом, то имеется ввиду метод прогназирования, При адаптивной разработке нельзя сказать "в соответствии с планом", поскольку план все время меняется. Это не означает, что адаптивные проекты не планируются; обычно планирование занимает значительное время, но план трактуется как основная линия поведения последовательных изменений, а не как предсказание будущего.
На основе прогнозирующего плана можно разработать контракт с фиксированной функциональностью по фиксированной цене. В таком контракте точно указывается, что должно быть создано, сколько это стоит и когда продукт будет поставлен. В адаптивном плане такое фиксирование невозможно. Вы можете обозначить бюджет и сроки поставки, но вы не можете точно зафиксировать функциональности поставляемого продукта.
Адаптивный контракт предполагает, что пользователи будут сотрудничать с командой разработчиков, чтобы регулярно пересматривать требуемую функциональность и прерывать проект, если прогресс слишком незначителен. Как таковой процесс адаптивного планирования может определять проект с переменными границами функциональности по фиксированной цене.
Естественно, адаптивный подход менее желателен, поскольку все предпочитают большую предсказуемость программных проектов. Однако предсказуемость зависит от точности, корректности и стабильности множества требований. Если вы не в состоянии стабилизировать свои требования, то прогнозирующий план базируется на песке, а изменения настолько значительны, что проект сбивается с курса. Отсюда вытекают два важных совета.
1. Не составляйте прогнозирующий план до тех пор, пока не получите точные и корректные требования и не будете уверены, что они не подвергнуться существующим изменениям.
2. Если вы не можете получить точные, корректные и стабильные требования, то используйте метод адаптивного планирования