PMBOK 9 Knowledge Areas to 5 Process Group Mapping

	Project Management Process Groups
Knowledge Areas	Initiating Process Group	Planning Process Group	Executing Process Group	Monitoring & Controlling Process Group	Closing Process Group
4. Project Integration Management	4.1 Develop Project Charter	4.2 Develop Project Management Plan	4.3 Direct and Manage Project Execution	4.4 Monitor and Control Project Work 4.5 Perform Integrated Change Control	4.6 Close Project or Phase
5. Project Scope Management		5.1 Collect Requirements 5.2 Define Scope 5.3 Define WBS		5.4 Verify Scope 5.5 Control Scope
6. Project Time Management		6.1 Define Activities 6.2 Sequence Activities 6.3 Estimate Activity Resources 6.4 Estimate Activity Durations 6.5 Develop Schedule		6.6 Control Schedule
7. Project Cost Management		7.1 Estimate costs 7.2 Determine Budget		7.3 Control Costs
8. Project Quality Management		8.1 Plan Quality	8.2 Perform Quality Assurance	8.3 Perform Quality Control
9. Project Human Resource Management		9.1 Develop Human Resource Plan	9.2 Acquire Project Team 9.3 Develop Project team 9.4 Manage Project team
10. Project Communications Management	10.1 Identify Stakeholders	10.2 Plan Communications	10.3 Distribute Information 10.4 Manage Stakeholder Expectations	10.5 Report Performance
11. Project Risk Management		11.1 Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses		11.6 Monitor and Control Risks
12. Project Procurement Management		12.1 Plan Procurements	12.2 Conduct Procurements	12.3 Administer Procurements	12.4 Close Procurements

Read more from PMBOK, Process Groups PMBOK

Эрик Эванс о едином языке команды разработки

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

Эрик Эванс о разнице диалектов

Проект сталкивается с серьезными проблемами, когда в нем отсутствует единый

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

собственный язык, приспособленный для описания предметной области в терминах

программной архитектуры.

Терминология повседневных дискуссий оторвана от терминологии, внедренной код

(а это, в конце концов, главный продукт, создаваемый в проекте) . Даже один и тот же

человек пользуется двумя разными языками на письме и в разговоре, так что самые

критические положения предметной области часто выражаются в промежуточной

форме, не фиксируемой в коде или даже в письменной документации.

Необходимость в переводе затрудняет коммуникацию и ослабляет интенсивность

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

Эрик Эванс о правилах предметной области

 Переработка знаний становится нетривиальным процессом именно тогда, когда сами знания представляют собой нечто большее, чем набор объектов и числовых показателей - ведь в заданных правилах делового регламента (алгоритмах операций, соотношениях между понятиями предметной области) могут иметься противоречия. Специалисты обычно не осознают, насколько сложны происходящие у них в уме процессы: в ходе работы применяются соотношения и правила, устраняются противоречия, пробелы в знаниях заполняются с помощью интуиции и здравого смысла. Но программа ничего этого не умеет. Соотношения и правила предметной области должны проясняться, конкретизироваться, очищаться от противоречий или вообще отменяться в процессе совместной переработки знаний с участием программистов и специалистов.

Эрик Эванс о связи модели и языка обсуждения проекта

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

разговоре.

Устраняйте трудности путем экспериментирования с альтернативными выражениями, отражающими альтернативные модели. Затем выполняйте рефакторинг кода,

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

образом, как мы приходим к согласию о значении обычных слов.

Осознайте, что изменения в ЕДИНОМ ЯЗЫКЕ - суть изменения в модели.

Специалисты в предметной области должны возражать против терминов или структур, неудобно или недостаточно передающих суть явлений из их области. А разработчикам следует отслеживать любую неодзнозначность и непоследовательность, потому

что из-за них пострадает архитектура программы.

Эрик Эванс, определение термина "модель"

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

Эрик Эванс о последствиях унификации модели в больших системах

Полная унификация модели предметной области для большой системы либо невозможна, либо

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

субъективно кажется некрасивым. Это сопротивление использованию нескольких моделей иногда вызывает к жизни амбициозные попытки унифицировать все программное

обеспечение в рамках одного проекта под эгидой единой модели. Я знаю этот грех и за

собой. 

Но рассмотрим же, чем это чревато.

1 . Слишком много уже имеющегося кода придется одновременно заменять на новый.

2 . Большие проекты могут затормозиться из-за того, что дополнительная нагрузка по

управлению ими превзойдет имеющиеся возможности.

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

модели, которые не полностью cooтветствуют их задачам, поэтому реализацию

важных операций придется выносить куда-то в другое место.

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

Эрик Эванс о проблеме работы с несколькими моделями

В любом крупном проекте возникает необходимость работать с несколькими моделями. Но при комбинировании в одно целое кода, разработанного на основе сильно отличающихся моделей, программа становится ненадежной, трудной в понимании, склонной к сбоям. Запутывается коммуникация между членами группы. Часто бывает непонятно, в каком контексте модель не должна применяться.

Эрик Эванс о бреши в базе знаний

Между тем в любом проекте существующая база знаний может "дать течь". Например, уволились сотрудники, которые уже чему-то научились. Или рабочая группа реорганизовалась, и накопленные ею знания снова стали фрагментарными. Или, скажем, критически важные подсистемы отданы для разработки субподрядчикам, и те присылают код, но не передают соответствующие знания, лежащие в его основе. Как правило, проектирование программ выполняется так, что ни код, ни документация не выражают знания, обретенные тяжкими трудами, в явной, понятной форме. Если по какой-то причине прекращается устная передача знаний в группе, это означает их потерю.

Эрик Эванс "Предметно-ориентированное проектирование"

Эрик Эванс об отличии ddd подхода от устаревшего "каскадного"

Переработка знаний не осуществляется в одиночку. Для этой цели разработчики программы сотрудничают со специалистами в предметной области - как правило, руководя этим процессом. Вместе они привлекают информацию и перерабатывают ее в удобную форму. Исходное информационное сырье приходит от специалистов в предметной области, пользователей существующих систем, из опыта технических сотрудников проекта по работе с аналогичными, более ранними системами или другими проектами в той же области знания. Информация поступает в виде проектной или деловой документации, а также бесконечных устных дискуссий. Ранние версии программ или их прототипы дают группе обратную связь и помогают видоизменять ее взгляды на проблему. 

В старой "каскадной методике" (waterfall тethod) специалисты по предметной области выдавали информацию аналитикам; те ее поглощали и абстрагировали, а затем передавали результат программистам, которые и писали программы. Этот подход неудачен, поскольку совершенно лишен обратной связи. Создание модели целиком возложено на аналитиков, а исходными данными им служит только информация от специалистов. Аналитики не имеют возможности научиться чему-либо у программистов или проанализировать результаты работы черновых версий программы. Знания протекают в одном направлении, но не накапливаются.

Эрик Эванс о составляющих успеха эффективного моделирования

 1 . Установили связь между моделью и ее реализацией. 

Уже в самом грубом прототипе присутствовала существенная связь с действительностью, и после всех последующих доработок эта связь сохранилась. 

2. Ввели в обиход язык, основанный на модели. 

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

3. Разработали информоемкую модель. 

У объектов есть заданные правила поведения и ограничения. Наша модель была не просто схемой хранения данных, а целостной методикой решения сложных задач. Она содержала в себе и обобщала обилие информации разного рода. 

4. Занимались дucстилляцией модели. 

По мере того как создание модели близилось к завершению, в нее добавлялись важные понятия. Но также важно и то, что понятия, оказавшиеся бесполезными или второстепенными, были отброшены. Если бесполезное понятие было тесно связано с необходимым, то находилась новая модель, в которой существенное понятие легко отделялось, а второстепенное отбрасывалось. 

5. Экспериментировали и nроводили мозговые штурмы. 

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

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

Эрик Эванс "Предметно-ориентированное проектирование"

Эрик Эванс о трех фундаментальных способах использования модели при разработке

 Выбор модели в предметно-ориентированном проектировании определяется тремя фундаментальными способами ее использования при разработке программы. 

1. Модель и арxuтектура программы взаимно определяют друг друга. Именно тесная связь между моделью и ее программной реализацией определяет важность и нужность самой модели, а также гарантирует, что проделанный при ее разработке анализ отражен в конечном результате, Т.е. в работающей программе. Связь между моделью и реализацией помогает также в процесс е дальнейшей доработки программы и выпуска ее новых версий, поскольку и сам программный код можно интерпретировать, основываясь на понимании модели. 

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

3 . Модель это дистиллированное знание. Модель представляет собой согласованный между разработчиками способ структуризации знаний из предметной области, а также выделения элементов, представляющих наибольший интерес. Модель передает наш способ мыслить о предмете, выраженный в выборе терминов, выделении понятий И установке связей между ними. Разработчики и специалисты в предметной области имеют возможность совместно переработать информацию в такую форму, поскольку для этого у них имеется общий язык. А связь между моделью и реализацией позволяет использовать опыт разработки ранних версий программы для корректировки самого процесса моделирования.

Эрик Эванс "Предметно-ориентированное проектирование"

Эрик Эванс о модели предметной области

Модель предметной области - это не некая нарисованная схема, а идея, которую схема должна отражать. Это не просто знания специалиста по данному предмету; это строго организованная выборка из такого знания. Схема может наглядно изображать модель, передавать информацию о ней, но того же самого можно добиться и при помощи программного кода или предложения на "человеческом языке". Моделирование предметной области не нацелено на создание максимально "реалистичной" модели. Даже в мире осязаемых, реальных вещей наша модель будет всего лишь искусственным творением. Но моделирование не состоит и в том, чтобы просто сконструировать программный механизм, который бы давал нужный результат. Процесс моделирования чем-то близок к съемке фильма - это тоже примерное изображение реальности , служащее конкретной цели. Даже в документальном фильме не показывают реальную жизнь совсем без прикрас. Как кинематографист выбирает отдельные аспекты реальной жизни и показывает их в своеобразном виде для раскрытия сюжета или передачи послания фильма, так и специалист, моделирующий предметную область, выбирает модель сообразно с ее применимостью .

Эрик Эванс "Предметно-ориентированное проектирование"

SoapClient не передает заголовки Basic Authentication

Столкнулся на проекте с необычной штукой. SOAP-сервер находился под http-аутентификацией. На development машинах код работал без ошибок. Но при выгрузке на production стал давать при инициализации клиета ошибку:

SOAP-ERROR: Parsing WSDL: Couldn't find  

 Поставил сниффер на машину с сервером. Оказалось, что  SoapClient, которому в options задавались логин и пароль не передавал заголовок Authentication. Причем было это, как я уже сказал, только на production сервере, где стояла Gentoo. Проблема была решена сменой версии php

5.3.8-pl0-gentoo на 5.3.25-pl0-gentoo

Вероятно, к этой версии баг был пропатчен.

ZF2 skeleton

composer create-project --repository-url="http://packages.zendframework.com" --stability=dev zendframework/skeleton-application test

Wordpress 2.6.1 под php 5.3

Пришлось перетаскивать старый сайт сделанный на Wordpress 2.6.1. Тут  же повылетали сообщения, что передача по ссылке уже запрещена. Обновляться до новой версии 3 не хотелось, поскольку может обернуться необходимостью тратить еще кучу времени на фиксирование несовместимостей, а времени особо нет.


Починил пока при помощи sed

 find -name \*.php -exec sed -i 's/=&/=/g' {} \;

Осталось  пофиксить ругань на eregi в админке, а так, вроде запустилось. 




 

Ошибка в меню Joomla

При переходе на php5.3 сайт на старой Joomla стал выкидывать warning 

modMainMenuHelper::buildXML() expected to be a reference, value given


Лечится простым фиксом  в /modules/mod_mainmenu/helper.php.
Меняем function buildXML(&$params) на function buildXML($params).

Using vimdiff as git diff tool

git config --global diff.tool vimdiff 

git config --global difftool.prompt false 

git config --global alias.d difftool 


Typing git d yields the expected behavior, type :wq in vim cycles to the next file in the changeset.

Из книги Гойко Оджича "Impact Mapping"

 К важным действующим лицам относятся конечные пользователи, а

также внутренние или внешние по отношению к проекту люди, принимающие

решения. Алистер Коберн советует искать действующих лиц трех типов:

1. Первичные действующие лица, на удовлетворение потребностей

которых направлен процесс разработки, например, игроки игровой системы.

2. Вторичные действующие лица, которые предоставляют услуги,

например, команда, занимающаяся предотвращением мошенничества.

3. Закулисные действующие лица, которые имеют заинтересованность в

проекте, но непосредственно не извлекают из него выгоду и не предоставляют

услуги. Пример – государственные агентства, регулирующие данный вид

деятельности, лица, принимающие решения на самых высоких уровнях в

соответствующих компаниях.

Гойко Оджич об определении действующих лиц в Impact Mapping

 Первый уровень impact map дает ответы на следующие вопросы: на чье поведение мы

хотим воздействовать? Кто сможет произвести желаемый эффект? Кто способен помешать?

Кто является потребителем или пользователем нашего продукта? На кого наш продукт повли-

яет? Это и есть те действующие лица, чье поведение может сказаться на результатах проекта.

Джеральд Вайнберг определяет качество как «ценность, предоставляемую кому-либо».

Чтобы обеспечить высокое качество результатов, мы сначала должны выяснить, кто эти люди

и какую ценность они хотят обрести, воспользовавшись продуктом или результатами нашего

проекта.

Гойко Оджич "Impact Mapping"

Гойко Оджич об отделении целей от продукта в Imapct Mapping

 Цели не должны описывать сам продукт, процесс его создания или

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

продукт будет полезен.

Целям следует определять проблему, которую предстоит решить, а не

воспроизводить решение. Избегайте включать в описание цели какие-либо

конструктивные ограничения, касающиеся готового продукта.

Гойко Оджич "Impact mapping"

Гойко Оджич о правильной формулировке целей в Impact Mapping

 Обозначенная цель дает разработчикам инструмент для пересмотра

первоначальных планов по мере поступления новой информации. Поэтому

верно сформулированные цели, как правило, соответствуют критериям

SMART: они конкретны, измеримы, ориентированы на совершение

конкретных действий, достижимы и ограничены во времени.

Гойко Оджич "Impact mapping"

Гойко Оджич о целях разработки

 Если очередной релиз или проект в целом позволяет достичь поставленной бизнес-цели, то это успех с точки зрения бизнеса, даже если в итоге

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

то же время, если программный продукт точно соответствует задуманным спецификациям, но

при этом не позволяет решить поставленную бизнес-задачу, его следует признать провальным.

Это верно даже тогда, когда разработчики не без оснований обвиняют клиента, что он сам

толком не понимает, чего хочет.

Гойко Оджич " Impact Mapping"

Из книги Гойко Оджича "Impact Mapping"

 Исследование, проведенное Гэри Кляйном на материале аварийно-спасательных служб

и армейских подразделений, показало, что при осуществлении любой деятельности люди на

местах должны понимать конечные цели операции, иначе они не в состоянии правильно реа-

гировать на непредвиденные проблемы.

Гойко Оджич об этапе определения целей в подходе Impact Mapping

 Центральная часть impact map должна отвечать на самый важный вопрос: зачем мы это

делаем? Это цель, которую мы стремимся достичь.

Может показаться, что стремление в самом начале проекта получить ясный ответ на этот

вопрос – всего лишь проявление здравого смысла. Однако мой опыт показывает, что лишь

немногие из разработчиков точно знают, какие бизнес-цели преследует заказчик. Иногда их

описывают в каком-либо формальном документе, но чаще всего бизнес-цели существуют лишь

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

разработчиков, они зачастую сформулированы весьма смутно.

Гойко Оджич "Impact Mapping"

Гойко Оджич об InUse и Impact Mapping

 Карты эффектов InUse скорее ориентированы на содействие инновационному дизайну продуктов и дизайну пользовательского опыта. Однако наиболее распространенными проблемами в компаниях, с которыми я работаю в качестве консультанта, являются недостатки в применяемых методах разработки, расползание границ проекта, тенденция упускать из вида общую картину, недостаточная ориентация разработчиков на достижение бизнес-целей. Эти организации бесполезно тратят массу времени и усилий на создание не того программного обеспечения, которое им нужно. Impact mapping представляет собой фантастический способ свести эти страдания к минимуму.

Гойко Оджич "Impact Mapping"