Заметки консультанта

Шамрай Александр Владимирович

Archive for Август 2010

Локализация схем ClearQuest

Posted by Шамрай Александр на Август 31, 2010

<< Перейти в раздел «ClearQuest FAQ»

Для быстрой локализации схем в ClearQuest можно использовать утилиту cqload. Эта утилита позволяет установить новые значения для текста помощи полей и надписей полей на форме без использования дизайнера схем. Для этого есть специальные подкоманды (на момент публикации заметки еще не документируемы):

  • exporttranslations – для экспорта значений текста помощи и надписей формы.
  • Importtranslations – для импорта новых значений текста помощи и надписей формы.

Пример

Посмотрим на примере схемы ALM, как работает этот подход.

  • Исходные значения текста помощи и надписи на форме для поля ActivitiesRelated на английском языке

  • Экспортируем в отдельный файл описание всех значений с помощью утилиты cqload exporttranslations с параметрами:
    • [-dbset dbset_name] – наименование подключения, если отличается от значения по умолчанию
    • clearquest_login – логин пользователя с правами дизайнера схем
    • clearquest_password – пароль пользователя
    • schema_name – наименования схемы
    • notranslate_pathname – файл без перевода (оставляем пустым)
    • schema_pathname – файл, в который будут выгружены все значения для текста помощи и надписей на формах

Пример:

cqload exporttranslations -dbset alm_test admin «» ALM «» c:\temp\schema.txt

  • В результате работы утилиты будет файл следующего формата:

  • Добавим новые значения в файл экспорта. Для этого нужно добавить структуры <target>Новое значение</target> в структуру для поля <trans-unit>. Изменения должны вноситься в формате UTF-8

  • Импортируем новые значения для поля с помощью cqload exporttranslations с параметрами:
    • [-dbset dbset_name] – наименование подключения, если отличается от значения по умолчанию
    • clearquest_login – логин пользователя с правами дизайнера схем
    • clearquest_password – пароль пользователя
    • schema_name – наименования схемы
    • schema_pathname – файл, в котором находятся новые значения для текста помощи и надписей на формах

Пример:

cqload importtranslations -dbset alm_test admin «» ALM c:\temp\schema.txt

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

Реклама

Posted in ClearQuest FAQ, IBM Rational | Отмечено: , , , | Leave a Comment »

Вложенные UCM Project VOB в ClearCase

Posted by Шамрай Александр на Август 24, 2010

Оригинал: Understanding Nested UCM Project VOB Environments

Введение

IBM ® Rational ® ClearCase ® Unified Unified Change Management (UCM) позволяет делать расширение с использованием ассоциации административных проектных VOB-ов (PVOB). В этом документе приводятся детали и передовой опыт для сред, которые реализуют структуру административных VOB-ов, которая включает использование нескольких PVOB-ов (вложенные PVOB). В этом документе также рассматриваются дополнительные варианты для среды ClearCase MultiSite. Документ не отображает всех возможных конфигураций с участием UCM PVOB в среде UCM.

Этот документ предназначен для администраторов ClearCase UCM, ответственных за организацию конфигурации UCM.

Прежде чем приступить вы должны иметь глубокое понимание общих концепций UCM, которые приведены в разделе Understanding UCM руководства IBM Rational ClearCase Managing Software Projects.

Обзор

Вложенные проектные VOB-ы могут добавить дополнительный уровень масштабируемости и функциональности для среды UCM, которая позволяет администраторам разделять метаданные по нескольким проектным структурам UCM. Такая вложенная конфигурация может помочь разделить метаданные между несколькими административными VOB-ами и избежать больших баз данных для VOB-ов. Она также может быть полезна для повышения производительности за счет перевода вновь созданных проектов в отдельные проектные VOB-ы. Эта статья должна помочь избежать многих проблем, которые могут возникнуть при связывании проектных VOB-ов.

В этом документе будет рассматриваться следующее:

  • Стандартная разработка с одним проектным UCM VOB-ом
  • Создание структуры вложенных проектных VOB-ов
    • Использование существующего проектного VOB-а в качестве административного VOB-а для дочерних проектных VOB-ов.
    • Использование общих административных VOB-ов для нескольких проектных VOB-ов
  • Использование ucmutil link_pvob
  • Среда MultiSite и общие проблемы, которые могут возникнуть

Стандартная разработка с одним проектным UCM VOB-ом

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

Ниже на рисунке отображена ассоциация проектного VOB-а и компонентного VOB-а для стандартного UCM. Рисунок отображает некоторые основные данные, сгенерированные в обоих VOB-ах, что более подробно раскрывается ниже.

Стандартная UCM разработка предполагает, что элементы данных файл и каталог будут созданы в компонентном VOB-е. Каждая версия, сгенерированная в компонентном VOB-е, связывается с UCM активностью. Каждая сгенерированная версия должна быть связана с типом ветви ClearCase.

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

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

Базовая линия UCM является объектом, созданным в рамках проектного VOB-а. Она связана с обычным типом метки, созданным в компонентном VOB-е. Тип метки применяется для единственной последней версии для каждого элемента в выбранной конфигурации. Как правило, эта конфигурация определяется потоком, в котором создается базовая линия.

Создание структуры вложенных проектных VOB-ов

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

На данный момент есть два способа добавления нового проектного VOB-а в существующую среду UCM.

  • Добавить новый проектный VOB и выбрать любой проектный VOB (существующий или новый) в качестве единой административного VOB-а. Однако этот вариант не очень масштабируем. Эта конфигурация представляет риск разрастания одного проектного VOB-а. Это также увеличивает значимость существующего проектного VOB-а.

Рисунок А.1

  • Добавить новый проектный VOB и новый общий административный VOB. Эта конфигурация становится масштабируемой и предусматривает равное значение для обоих проектных VOB-ов. Это помогает сохранить специфические объекты проектного VOB-а отдельно от общих глобальных метаданных, таких как тип ветви. Такая структура также будет держать метаданные организованными в общем административном VOB-е. Такая конфигурация потребует использования утилиты поставляемой в комплекте с ClearCase. Утилита называется «ucmutil» и далее о ней будет рассказываться более подробно.

Рисунок А.2

Использование ucmutil link_pvob

В выше указанной конфигурации необходимо использование «ucmutil». Утилита имеет подкоманду «link_pvob». Эта подкоманда позволяет администраторам связать существующий проектный VOB с верхнеуровневым административным VOB-ом. Утилита требует, чтоб существующий проектный VOB не был связан с любыми другими административными VOB-ами. Целью этой утилиты является выполнение следующих операций.

  • Передать все существующие глобальные определения типов ветви существующего проектного VOB-а в административный VOB
  • Переопределить ассоциацию всех существующих потоков с глобальными определениями типов ветви перемещенными в административный VOB
  • Перенаправить связи с административным VOB-ом любых соответствующих компонентных VOB-ов к новому административному VOB-у. Как вы можете видеть на рисунке выше, компонентный VOB теперь указывает на общий административный VOB, что является результатом запуска «ucmutil link_pvob». Необходимо также отметить, что ассоциации компонентов остаются с первоначальным проектным VOB-ом.

Утилиту «ucmutil» можно найти в следующих каталогах:

  • Windows: %CLEARCASE_HOME%\etc\utils\ucmutil.exe
  • Linux/Unix: /opt/rational/clearcase/etc/utils/ucmutil

Для более подробной информации об этой утилите смотрите Technote 1237620 About ucmutil.

Примечание: В приведенном ниже примере вы должны установить свой путь к утилите ucmutil в переменную среды (или обеспечить полный путь к ucmutil) и установить контекст в представление для выполнения команд.

Пример использования:

——————————————————————————————————————
M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB
Checking branch type ccrc_deliver.
Checking branch type composite_Integration.
Checking branch type deliver_Integration.
Checking branch type william_child_deliver.
Checking branch type william_child2_deliver.
Checking branch type william_deliver.
Total of 6 global branch types in VOB \pvobing.
Total of 6 UCM branch types checked.
M:\adminView>
——————————————————————————————————————

Как можно увидеть в приведенном выше примере, подкоманда link_pvob будет находить все глобальные определения типа ветви для дочернего проектного VOB-а. Этот пример выполнен в -verbose (предварительном) режиме. Рекомендуется всегда использовать этот инструмент в режиме предварительного просмотра, перед тем как выполнить саму операцию. Также полезно перенаправить вывод команды в лог-файл для дальнейшего анализа. Эта команда необратима. После выполнения команды запуска с флагом «-fix «, гиперссылка административного VOB изменяется, и все метаданные изменяют структуру для представления иерархических изменений. Существуют некоторые проблемы, которые могут возникнуть в процессе проведения операции, поэтому инструмент проверяет, обеспечена ли блокировка VOB-а с ключом «-nuser». Только пользователь, выполняющий команду, должны быть в состоянии получить доступ к VOB-у при запуске операции «ucmutil link_pvob». Для этого вы должны заблокировать VOB с исключением пользователя, который запустил операцию, с ключом «-nuser».

Пример блокировки проектного VOB-а с ключом «nuser»:

——————————————————————————————————————
M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
ucmutil: Error: VOB \pvobing should be locked with «-nuser» before running this tool.

M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\pvobing
Locked versioned object base «\pvobing».

M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
ucmutil: Error: VOB \commonAdminVOB should be locked with «-nuser» before running this tool.

M:\adminView>cleartool lock -nuser DOMAIN1\william vob:\commonAdminVOB
Locked versioned object base «\commonAdminVOB».
——————————————————————————————————————

В приведенном выше примере можно увидеть, что утилита проверяет блокировку обоих проектных VOB-ов. Она будет рекомендовать, чтобы вы заблокировали VOB с ключом -nuser.

Напомним, что перед запуском ucmutil link_pvob с ключом -fix, вы должны выполнить следующие операции:

  1. Заблокировать проектные VOB-ы с ключом –nuser
  2. Выполнить ucmutil link_pvob –verbose и перенаправить вывод в лог-файл для дальнейшего анализа. (Это также может быть полезно для устранения неполадок)
  3. Убедитесь, что все типы ветвей, перечисленные в режиме предварительного просмотра, имеют локальную мастер реплику на сайте выполняющему операции. (Эта тема будет рассмотрена в разделе Среда MultiSite далее)
  4. Убедитесь, что все компонентные VOB-ы, связанные с дочерним проектным VOB, НЕ заблокированы. Блокировка компонентных VOB не даст утилите доступ и возможность изменить необходимые данные (Вы можете заблокировать компонентные VOB-ы с ключом -nuser при блокировке проектных VOB-ов, чтобы избежать проблем).

Ниже приведен пример запуска утилиты для связывания проектного VOB-а «\pvobing» с общим административным VOB-ом «\commonAdminVOB»:

Вот список метаданных перед операцией:

  1. Список глобальных типов ветвей в «\commonAdminVOB»
    M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
    main
  2. Список глобальных типов ветвей в «\pvobing»
    M:\adminView>cleartool lstype -s -kind brtype -invob \pvobing
    ccrc_deliver
    composite_Integration
    deliver_Integration
    main
    william_child_deliver
    william_child2_deliver
    william_deliver
  3. Список гиперссылок на административные VOB-ы для ассоциированных компонентных VOB-ов в «\pvobing»
    M:\adminView>cleartool describe -l -ahlink -all vob:\pvobing
    Hyperlinks:
    AdminVOB@42@\brokeComp <- vob:\brokeComp
    AdminVOB@42@\cvobing <- vob:\cvobing
  4. Пример ассоциации потоков UCM с глобальными типами ветвей перед связыванием двух проектных VOB-ов
    M:\adminView>cleartool describe -l -ahlink –all stream:deliver_Integration@\pvobing
    deliver_Integration
    Hyperlinks:
    IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\pvobing
    UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
  5. Гиперссылка на административный VOB, указывающая из ассоциированного компонентного VOB-а
    M:\adminView>cleartool describe -l -ahlink -all vob:\cvobing
    \cvobing
    Hyperlinks:
    AdminVOB@42@\cvobing -> vob:\pvobing

Пример выполнения команды связывания двух VOB-ов

  1. Выполнение команды в режиме предварительность просмотра с флагом –verbose и перенаправление вывода в лог-файл:
    M:\adminView>ucmutil link_pvob -verbose -from vob:\pvobing -to vob:\commonAdminVOB > c:\link_pvob_log.txt
  2. Запуск инструмента для создания связи между VOB-ами с флагом –fix:
    M:\adminView>ucmutil link_pvob -fix -verbose -from vob:\pvobing -to vob:\commonAdminVOB
    Checking branch type ccrc_deliver.
    Moving branch type ccrc_deliver.
    Checking branch type composite_Integration.
    Moving branch type composite_Integration.
    Checking branch type deliver_Integration.
    Moving branch type deliver_Integration.
    Checking branch type william_child_deliver.
    Moving branch type william_child_deliver.
    Checking branch type william_child2_deliver.
    Moving branch type william_child2_deliver.
    Checking branch type william_deliver.
    Moving branch type william_deliver.
    Reconnecting the moved global branch types.
    There is no global type in source VOB. Do you want to redirect the AdminVOB hyperlink? [no] yes
    Redirecting AdminVOB hyperlink.Total of 6 global branch types in VOB \pvobing.
    Total of 6 UCM branch types checked.
    Total of 6 UCM branch types moved.
    Total of 6 Stream hyperlinks reconnected.
    Total of 2 VOBs has been reconnected to new Admin VOB.

    M:\adminView>

Ниже представлен список мигрированных и измененных метаданных как результат операции:

  1. Список глобальных типов ветвей, которые сейчас существуют в «\commonAdminVOB»
    M:\adminView>cleartool lstype -s -kind brtype -invob \commonAdminVOB
    ccrc_deliver
    composite_Integration
    deliver_Integration
    main
    william_child_deliver
    william_child2_deliver
    william_deliver

    (Заметьте, что все глобальные типы ветвей, которые до этого существовали в «\pvobing», мигрировали в «\commonAdminVOB»)

  2. Список гиперссылок Admin VOB в «\pvobing» после выполнения ucmutil link_pvob
    M:\adminView>cleartool desc -l -ahlink -all vob:\pvobing
    \pvobing
    Hyperlinks:
    AdminVOB@310@\pvobing -> vob:\commonAdminVOB(Заметьте, что гиперссылки Admin VOB для всех ассоциированных компонентных VOB-ах более не указывает на проектный VOB. Существует только гиперссылка Admin VOB, которая была создана утилитой ucmutil link_pvob)
  3. Пример ассоциации потоков UCM с глобальными типами ветвей после связывания двух проектных VOB-ов:
    M:\adminView>cleartool desc -l -ahlink -all stream:deliver_Integration@\pvobing
    deliver_Integration
    Hyperlinks:
    UseBaseline@114@\pvobing -> baseline:cvobing_INITIAL@\pvobing
    IndependentGuard@306@\pvobing -> brtype:deliver_Integration@\commonAdminVOB(Заметьте, что гиперссылка IndependentGuard сейчас указывает на глобальный тип ветви мигрированный в commonadministrativeVOB)
  4. Список гиперссылок Admin VOB в «commonAdminVOB» после работы утилиты ucmutil
    M:\adminView>cleartool desc -l -ahlink -all vob:\commonAdminVOB
    \commonAdminVOB
    Hyperlinks:
    AdminVOB@43@\brokeComp <- vob:\brokeComp
    AdminVOB@310@\pvobing <- vob:\pvobing
    AdminVOB@225@\cvobing <- vob:\cvobing(Заметьте, что гиперссылки Admin VOB, ранее указывающие на «\pvobing», теперь указывают на «\commonAdminVOB», который содержит все глобальные типы ветвей.)
  5. Измененная гиперссылка Admin VOB, указывающая из компонентного VOB-а ассоциированного с «\pvobing»
    M:\adminView>cleartool desc -l -ahlink -all vob:\cvobing
    \cvobing
    Hyperlinks:
    AdminVOB@225@\cvobing -> vob:\commonAdminVOB(Заметьте, что даже этот VOB, содержащий компонентные данные ассоциированные с «\pvobing», указывает на «\commonAdminVOB» для получения любых определений глобальных типов. )

MultiSite среды и общие вопросы, которые могут возникнуть

На данный момент мы рассмотрели, как работает утилита ucmutil link_pvob для создания вложенные структуры проектных VOB-ов, однако, мы не обсуждали то, что может произойти если VOB реплицирован в среде ClearCase MultiSite.

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

Ниже приводится список проблем, которые могут возникнуть, если только некоторые из VOB-ов в структуре реплицируются на альтернативные сайты. Мы будем использовать структуру, показанную на вышеприведенных примерах. Если оба проектных VOB-а и связанные с ним компонентные VOB-ы были скопированы без единого административного VOB-а:

  1. Сайт реплики не будет иметь доступ к необходимым глобальным типам ветвей связанными с потоками UCM
  2. На сайте реплики, скорее всего, будет необходимость создания потоков. Потоки не будут иметь доступ к общему административному VOB-у, где находятся связанные с ними глобальные типы ветвей.
  3. Проектный VOB и компонентный VOB будут иметь неверные гиперссылки на административный VOB, указывающие на VOB, который не существует.
    ВАЖНО: Это очень опасно. Если «cleartool checkvob –ucm или -hlinks» исполняется для VOB-а, команда увидит поврежденные гиперссылки. Checkvob фактически удалит гиперссылки для исправления. Эта операция будет реплицирована на исходный сайт. Это нарушит структуру административного VOB-а на исходном сайте и вызовет катастрофу в производственной среде. Эта ошибка не произойдет, если все VOB-ы в структуре будут реплицироваться. Как альтернатива, при необходимости, можно блокировать тип гиперссылки AdminVOB для VOB-ов с ключом -nuser. Это запретит пользователям создавать и удалять гиперссылки AdminVOB.Пример:
    cleartool lock –nuser domain\user hlink:AdminVOB@\pvobing

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

Перед запуском ucmutil link_pvob с флагом «-fix» в среде MultiSite, вы должны предусмотреть следующие.

  1. Убедитесь, что все доступные метаданные имеют мастер реплику сайта, на котором выполняется команда ucmutil.
  2. Запустите сначала программу с флагом «-verbose» и просмотрите список вовлеченных ветвей. Убедитесь, что все потоки связаны с этими типами ветвей имеют мастер реплику сайта, на котором выполняется команда. Используйте страницу помощи «cleartool chmaster» для изменения мастер реплики потока и всех его объектов.
  3. Просмотрите гиперссылки AdminVOB, связанные с существующим проектным VOB-ом, чтобы определить для каких VOB-ов должна быть установлена мастер реплика сайта, на котором выполняется команда. Гиперссылки AdminVOB связанные с каждым компонентным VOB-ом будут заново созданы, чтобы они указывали на новый связанный общий административный VOB.
  4. При запуске ucmutil link_pvob с флагом «-fix», сохраните результаты, т.к. они могут быть использованы для устранения ошибок, которые могут произойти. Для перенаправления вывода команды вы не можете быть в командной строке ucmutil. Вы должны набирать команду из контекста представления ClearCase. Вы должны отслеживать стандартные ошибки на стандартном устройстве вывода. Пример ниже покажет только стандартный поток вывода. Стандартные ошибки будут отображаться в окне командной строки.Пример:
    M:\adminView>ucmutil link_pvob –fix –from vob:\pvobing –to vob:\commonAdminVOB > c:\linkPvob_runLog.txt

Заключение

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

Ссылки

IBM Rational ClearCase Managing Software Projects manual

В тему статьи Using multiple PVOBs

Posted in ClearCase | Отмечено: , , , , , , | Leave a Comment »

Записки мистера Томпкинса из романа об управлении проектами «Deadline»

Posted by Шамрай Александр на Август 17, 2010

Роман «Deadline» можно даже назвать приключенческой историей, которая произошла с одним из сокращенных из рядов компании менеджеров проектов. По интересному стечению обстоятельств он оказывается главой организации по производству ПО в одной из стран третьего мира. При этом ему даны возможности не только руководить, но и выполнять некоторые эксперименты в области управления проектами. Каждый новый день – новая история, новый опыт, который мистер Томпкинс помечает в своей записной книжке. Эти записи приведены ниже.

Безопасность и перемены

  1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
  2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
  3. Неуверенность заставляет человека избегать риска.
  4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
  5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

Отрицательная мотивация

  1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
  2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
  3. Более того, если люди не справятся, вам придется выполнить свои обещания.

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

  1. Для руководства нужны сердце, нутро, душа и нюх
  2. Так что:
    • руководить надо сердцем;
    • чувствовать нутром;
    • вкладывать в команду и проект душу;
    • иметь нюх на всякую ерунду и бессмыслицу.

Главнокомандующий на поле битвы, как метафора управления проектами.
К началу сражения работа главнокомандующего уже закончена.
Собеседование и прием на работу.

  1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
  2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
  3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
  4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
  5. Больше слушайте, меньше говорите.
  6. И все это сработает еще лучше, если вы слегка подтасуете колоду.

Повышение производительности

  1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
  2. Повышение производительности — результат долгосрочных усилий.
  3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко» .

Управление рисками

  1. Чтобы управлять проектом, достаточно управлять его рисками.
  2. Создайте список рисков для каждого проекта.
  3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
  4. Оцените вероятность возникновения и стоимость каждого риска.
  5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
  6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
  7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите

  1. Сокращайте потери.
  2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
  3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
  4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
  5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
  6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
  7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
  8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

Моделирование процесса разработки

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

Извращенная политика

  1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
  2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
  3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
  4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
  5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
  6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных

  1. Определяйте размер каждого проекта.
  2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
  3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
  4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
  5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
  6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
  7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
  8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение

  1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
  2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
  3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
  4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
  5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
  6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
  7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по-другому

  1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
  2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
  3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
  4. Нельзя заставить людей делать что-то по-другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху

  1. Люди не начнут быстрее соображать, если руководство будет давить на них.
  2. Чем больше сверхурочной работы, тем ниже производительность.
  3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
  4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
  5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник

  1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
  2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
  3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации

  1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
  2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
  3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

Конфликт

  1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
  2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
  3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
  4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
  5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
  6. Тяжело договариваться. Гораздо легче выступать посредником.
  7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
  8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

Кто такой катализатор проекта

  1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
  2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
  3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»

Человеку свойственно ошибаться

  1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

О персонале

  1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
  2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
  3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
  4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
  5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии

  1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
  2. Каждому проекту нужна какая то церемония или ритуал.
  3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
  4. Защищайте людей от оскорблений и ругани Начальства.
  5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
  6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)

  1. Эту патологию невозможно вылечить снизу.
  2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
  3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
  4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

Злоба и скупость

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

Основы здравого смысла

  1. У проекта должно быть два срока сдачи — запланированный и желаемый.
  2. Эти сроки должны быть разными.

Posted in Книги, Разное | Отмечено: , , , | Leave a Comment »

 
%d такие блоггеры, как: