Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Save anonymous/f6a1a2e83695f42fa8e2ea6268a46b3a to your computer and use it in GitHub Desktop.
Save anonymous/f6a1a2e83695f42fa8e2ea6268a46b3a to your computer and use it in GitHub Desktop.
Управление программными проектами

Управление программными проектами


Управление программными проектами



Адаптивный стиль управления программными проектами
Управление программными проектами. Достижение оптимального качества при минимуме затрат (+ CD-ROM)
Система управления















Вход для зарегистрированных пользователей. Менеджеры программных проектов смогут добиться большего, если будут применять методы управления, характерные для киноиндустрии. Впрочем, прежде чем с гневом отвергнуть данное заявление, полезно рассмотреть следующие соображения. Эти тезисы, вероятно, звучат противоестественно для менеджеров проектов с инженерным складом ума, занятых производством самолетов, мостов, искусственных сердечных клапанов, ядерных реакторов, небоскребов и спутников — если только их проекты не требуют больших объемов программирования и не являются первыми в своем классе. Однако подобные рассуждения вполне правомочны по отношению к профессиональным кинопродюсерам, которые создают уникальные интеллектуальные продукты, ограниченные лишь замыслом и творческим потенциалом. Ежедневные решения, принимаемые менеджером проекта как и кинопродюсером , складываются под влиянием суждений о потребительской стоимости, ценовых компромиссов, человеческих факторов, макроэкономических и технологических тенденций, рыночной конъюнктуры и временных ограничений. Грамотно принимать эти субъективные решения позволяет адаптивный стиль руководства, подразумевающий активную вовлеченность в производственный процесс и регулярные коррекции курса. Экономическую эффективность программных продуктов трудно измерить одним простым показателем, но за последние пять лет лишь каждый третий проект укладывался в рамки бюджета и графика с той или иной степенью предсказуемости [2]. Похоже, что-то подобное можно сказать и об экономической эффективности кинопроизводства. В традиционных подходах к руководству крупными программными проектами не поощряются корректировки, необходимые для адаптации к высоким уровням неопределенности:. Нужны более динамичные и адаптивные способы принятия решений о развитии программного продукта и управлении качеством, основанные на примерах успешных проектов. Современные подходы к управлению программными проектами известны как итеративные методы разработки []. Они не подразумевают строгого следования детальному долгосрочному плану и ведут программные проекты через минные поля неопределенностей, свойственных разработке современных программных приложений, продуктов и услуг. Для успешной реализации проектов в рамках графика и бюджета требуется сочетание творчества, продуктивности, трезвой оценки и адаптивного стиля руководства. А для этого, в свою очередь, необходимы активная вовлеченность в производственный процесс, частые корректировки курса, направленные на получение наилучших результатов, и сотрудничество всех заинтересованных лиц для достижения изменяющихся целей. IBM Rational Unified Process RUP , признанный эталон итеративного процесса разработки, создает основу сбалансированного развития, способствующую управлению неопределенностями и рисками [6]. Он состоит из четырех фаз, каждая из которых завершается ощутимым результатом. Итеративный стиль управления ориентирован на результаты, а не на действия для их достижения. А в мире программного обеспечения реальными результатами являются исполняемые программы. Все остальные артефакты требования, сценарии использования, модели проектирования, тестовые примеры, планы, процессы, документы и ревизии — это просто средства достижения цели. Как в киноиндустрии, где главные усилия направлены на производство фильмов, в области создания программных продуктов нужно материализовать этапы разработки в исполнимой форме, чтобы оценить прогресс и качество. При этом придется, отбрасывая заведомо неудачные варианты, неоднократно переделывать оставшиеся, прежде чем удастся найти работоспособное решение и свести вклады многих людей в единый интеллектуальный продукт. Вспомните свое программистское прошлое: Оно становилось материальным лишь после компиляции, компоновки и выполнения, и уж тогда вы могли рассуждать о его качестве, производительности, полезности и законченности. Точно так же кинопродюсеры относятся к сценариям, раскадровкам, декорациям и эскизам костюмов. Они собирают отдельные сцены в фильм, делая его представление достаточно материальным для суждения о качестве. И то же самое относится к менеджерам проектов. Оценивая достоинства плана, модели, документа или другого неисполняемого представления, вы занимаетесь лишь досужей болтовней о качестве и прогрессе в работе. По мере продвижения успешного программного проекта его участники все лучше понимают планы, спецификации и все ближе подходят к искомому решению. Каждый из них способствует последовательной реализации исполняемых функций и вносит свой вклад в коллективное понимание целей. В любой фазе проекта степень детализации артефактов должна отражать это понимание и увеличиваться по мере его углубления. В управлении проектами полно белых пятен, ситуативных зависимостей и альтернатив, и менеджеры должны уметь прогнозировать риски и последствия изменений. Необоснованно большая степень детализации требований или планов — препятствие весьма существенное, но трудноуловимое. Длительные усилия по детализации требований или плана только отдаляют достижение более точного понимания важных архитектурных проблем. Над сколькими пугающе толстыми томами требований или продуманными до мельчайших деталей планами вы корпели, совершенствуя их и без конца пересматривая? И сколько из них приходилось полностью переделывать всего через несколько месяцев, когда проект давал первые осязаемые результаты, проливающие свет на реальные противоречия и проблемы? Итеративные процессы развиваются благодаря потребности лучше справляться с неопределенностью и лучше управлять рисками, связанными с разработкой программного обеспечения. Такие процессы требуют динамичного управления и промежуточных контрольных точек, в которых все заинтересованные лица могут оценить достижения, идентифицировать новые цели и внести изменения в проект для достижения этих целей самым экономным способом. Далее приведены четыре схемы, характерные для успешных программных проектов и помогающие создавать подобные контрольные точки. Можно предположить, что большинство менеджеров, прошедших традиционную подготовку, будут отрицательно реагировать на эти схемы, поскольку они находятся в некотором противоречии с обычным здравым смыслом. Конечно, их легче сформулировать, чем применить в реальном программном проекте, и, разумеется, нужно учитывать особенности предметной области. Реализация таких схем в группе разработки Web-приложений будет отличаться от реализации в группе разработки встроенных систем, но их суть сохранится. Написать книгу или статью о методах, схемах и технических приемах относительно легко, но большинство из нас ищет не лучшие мысли, а лучшие практики. Управление проектами нацелено на практическое применение этих идей, что в реальных условиях оказывается невероятно трудным делом. Мы должны холить и лелеять менеджеров проектов, доказавших свою состоятельность на практике; вероятно, они являются самым дефицитным ресурсом любой компании. Как и в киноиндустрии, нам нужны квалифицированные архитекторы директоры , аналитики сценаристы и художники-декораторы , программисты съемочные группы, редакторы, постановщики спецэффектов, актеры и каскадеры и особенно менеджеры проектов продюсеры. Успешные проекты в какой-то мере реализуют эту последовательность, но границы между отдельными этапами являются довольно размытыми, и все участники процесса именно так их и воспринимают. В неудачных проектах менеджеры борются за четкие границы между этапами — например, настаивают на полном замораживании базовых требований до перехода к проектированию или на завершении детальной проработки проектной документации до перехода к кодированию. Внимание к мелочам замедляет или даже полностью останавливает прогресс в принятии важных технических решений. Когда мы строим совершенно новые программные решения, последовательная детализация спецификаций от требований до проектной документации имеет некоторый смысл. Но обычно мы модернизируем существующую систему или создаем новые системы из имеющихся компонентов операционных систем, Web-сервисов, сетей, графических интерфейсов пользователя, систем управления данными, программных средств общего назначения, программного обеспечения промежуточного слоя, вычислительных платформ, унаследованных систем и т. Измененное требование подвергается тщательной ревизии, поскольку оно обычно является частью контракта между заинтересованными лицами. Существуют два типа пользовательских спецификаций. Первый из них — внешнее представление потребность пользователя. Такая спецификация оказывает серьезное влияние на контракт группы разработчиков с покупателем. Разработчики должны представить входящую в нее информацию в понятной для пользователя форме она специально создается для конкретного случая и может включать в себя текст, имитационные модели, сценарии применения, электронные таблицы. Модель сценария использования, которая поддерживает внешнее представление, отображает принципы работы и ожидаемое поведение в терминах, понятных покупателю. Спецификация второго типа весьма значительно отличается от требований. Ее можно назвать критерием оценки промежуточной контрольной точки проекта, например очередной рабочей версии системы. Критерий оценки — это промежуточная цель адаптивного управления, полученная из внешнего представления и многих других источников сравнительный анализ целесообразности закупки готового решения, адаптации имеющегося или построения нового своими силами; вопросы управления рисками; архитектурные соображения; случайные догадки; ограничения реализации; пороги качества и т. Наряду со сценариями использования критерии оценки создают более мощные предпосылки для раннего тестирования, чем обычные формы представления требований. Предложение о содержании последовательных рабочих версий и критериях оценки, высказанное на ранних стадиях проекта служит прекрасной формой для планирования рисков. В течение многих лет предпринимались попытки привести к согласию сторонников гибкой разработки и приверженцев зрелых процессов. Оба лагеря имеют полезные взгляды и методы, но пока нет ясного представления о диапазонах их применения. Чрезвычайно важен контекст, и в любом нетривиальном проекте следует выбирать методы разработки, опираясь на здравый смысл и знание предметной области. Большинство менеджеров проектов согласятся с тем, что достаточно строгая регламентация процессов необходима в следующих случаях:. В последнем случае речь идет о выборе между скоростью и свободой гибких методов, с одной стороны, и качеством и последовательностью строго регламентированных методов, с другой. Регламентированность процесса должна действовать подобно гравитации: И чем вы дальше от даты выпуска, тем слабее такое влияние. В специальной литературе эта аксиома сильно недооценивается или даже вовсе опускается. В удачно организованных процессах разработки программного обеспечения прослеживается хорошо определенный переход от творческой стадии к стадии производства. Ранние стадии нацелены на достижение определенной функциональности, более поздние — на реализацию продукта и, таким образом, на надежность и производительность. На ранних стадиях программного проекта зачастую чрезмерно прорабатываются детали. Однако вам нужны маневренные процессы, которые могут легко адаптироваться к озарениям разработчиков и позволяют компенсировать неопределенность , атакующих рискованные направления или создающих прототипы решений и первые, черновые артефакты. Вы можете себе представить творческую дисциплину, в которой повышение уровня регламентированности процесса помогает думать? А вот на стадии производства недостаточная проработка обычно становится проблемой. Для изготовления высококачественного продукта необходим процесс проектирования, подразумевающий тщательную проработку деталей и особое внимание к согласованности и законченности. А теперь — о другом, не менее важном аспекте успешного перехода от творчества к производству. Регламентированность процесса, внимание к деталям, преждевременные уточнения обычно вызывают неприязнь у хороших проектировщиков, а грубые, расплывчатые результаты, как правило, раздражают хороших производственников. Менеджер проекта должен сбалансировать деятельность разных групп так, чтобы в ходе реализации проекта центр влияния перемещался от группы управления начальная фаза к архитектурной группе фаза проработки , затем к группе разработки фаза построения и, наконец, к группе испытаний фаза передачи. Человеческие аспекты управления программным проектом часто недооцениваются в том числе на большинстве курсов менеджмента , хотя они заслуживают внимательного отношения. Многие особенности классического процесса разработки становятся причиной ухудшения отношений его участников — вплоть до взаимного недоверия. Доверие очень важно для управления и достижения баланса между планами, потребностями пользователей и функциями продукта. Итеративная модель, подразумевающая эффективное общение, позволяет всем заинтересованным лицам достигать компромиссов на основе единого понимания цели. Заказчики, пользователи и инспекторы по контрактам могут сосредоточиться на поставке работоспособной системы, а не на отслеживании соответствия стандартам и неукоснительного соблюдения оговоренных условий. Организация-разработчик должна помнить и о создании потребительской стоимости с выгодой для себя. Итеративный процесс требует последовательного построения все более и более полной системы, которая позволяет предметно обсуждать требования, устранять ключевые риски, демонстрирует на практике достоинства своей архитектуры и технического подхода. В идеале все заинтересованные лица уделяют основное внимание последовательности работоспособных решений с возрастающей функциональностью, а не спекулятивным бумажным описаниям конечного продукта. Переход к процессу с наглядными промежуточными результатами в корне меняет график готовности проекта. Вместо линейно растущего объема освоенных средств что часто служит признаком недостаточной добротности успешный проект демонстрирует череду продвижений и отступлений. Программный проект, которому присущ последовательный рост объема освоенных средств, неминуемо провалится. В успешных программных проектах увеличивающиеся продвижения чередуются с уменьшающимися отступлениями по мере того, как разработчики справляются с неопределенностями и приближаются к приемлемому решению. Амбициозные демонстрации — превосходные вехи на пути продвижения успешного проекта. Цель демонстраций на ранних стадиях проекта состоит в том, чтобы выявить его недостатки, а не в том, чтобы декорировать фасад. Заинтересованные лица не должны слишком остро реагировать на ранние ошибки, отступления или незрелые замыслы. Если ранние технические стадии слишком ограничены по времени, организация-разработчик может установить не столь амбициозные контрольные точки. Клиенты и пользователи не должны ожидать, что первые варианты будут полностью соответствовать спецификациям конечного продукта, то есть окажутся законченными, абсолютно надежными, будут характеризоваться соответствующими уровнями качества или производительности. Тем не менее разработчик должен взять на себя ответственность в каждой следующей версии демонстрировать осязаемые усовершенствования. Объективная количественная оценка изменений, поправок и модернизаций обеспечивает подлинные индикаторы прогресса и качества. Для разрешения проблем в дальнейшем необходима открытая и тщательная систематическая работа. При адаптивном стиле руководства успех порождает успех. На основе цепочки ощутимых промежуточных результатов вы можете точнее спрогнозировать конечный результат. Постоянное отсутствие прогресса или застойная последовательность результатов — признак того, что нужно пересмотреть ресурсы проекта, его содержание или целесообразность. Поскольку ранние стадии могут стать решающими для успеха или провала проекта, на этапах планирования и разработки архитектуры должна действовать очень маленькая и очень компетентная стартовая группа. Если первые шаги сделаны в правильном направлении, проект окажется успешным даже при условии того, что превращать приложения в конечный продукт будут группы специалистов средней квалификации. Если же стадии планирования и разработки архитектуры не реализованы должным образом, на последующих этапах не помогут даже самые опытные в мире программисты и тестировщики. Если вы успешно управляете проектом в духе итеративной разработки, то большая часть комплексных испытаний будет предшествовать тестированию компонентов. В ходе выполнения проекта комплексное и покомпонентное тестирование осуществляются параллельно, но все же разработку и тестирование компонентов следует рассматривать в интегрированном контексте системной среды. После успешного тестирования интерфейса и взаимодействия с системой можно проверить полноту и законченность компонента. Ключевым следствием ранней интеграции становится превращение тестировщиков в полноправных участников процесса разработки. При обычных подходах тестировщики создают умозрительные планы, процедуры и документы, вторичные по отношению к артефактам процессов анализа и проектирования. Первые артефакты, являющиеся малозначимыми индикаторами успешности проекта, обычно привлекают игроков второго плана не показавших себя первоклассными аналитиками и разработчиками. В успешных итеративных проектах ранний выпуск промежуточных рабочих версий требует существенных усилий по тестированию. Результаты деятельности многих групп тестировщиков являются весьма эффективными. Аналитики слишком часто замыкаются в рамках абстрактной модели и ее жестких ограничений. Тестировщики же должны создавать контрольные примеры — реальные представления сценариев использования, критериев оценки или ожидаемого поведения. Они ставят перед собой другие вопросы и рассматривают мир с другой точки зрения, поскольку трансформируют абстрактные понятия в нечто, поддающееся проверке. В связи с широкой коммерческой доступностью компонентов и приложений сегодня часто приходится делать выбор: Если первая ориентированная на результат веха проекта нацелена на то, чтобы на основе демонстрации помочь в таком выборе, то вы ставите перед своими группами следующие задачи. Рассматривая тестирование как равноправную составляющую начальных стадий проекта, вы можете привлечь лучших тестировщиков и выполнить более качественный анализ. Обычные подходы к тестированию программного обеспечения повторяют документальный подход к его разработке. Группы разработки готовят документы с требованиями, а также высокоуровневые и детальные документы проекта до начала составления исходных кодов и исполняемых программ. В свою очередь, группы тестирования готовят документы, содержащие план и процедуры испытаний системы, план комплексных испытаний, план и процедуры испытаний компонентов, прежде чем приступить к построению тестовых драйверов, заглушек или инструментов. В результате подход на основе руководящих документов порождает при испытаниях, как и при разработке, много дурной работы, которая впоследствии переделывается. Для поощрения комплексных испытаний на ранних стадиях проекта организуйте последовательность тестирований по итерациям, а не по компонентам. Постройте с ее помощью набор сценариев использования и других текстуально представленных целей, которые могут быть наглядно продемонстрированы пользователю:. В итеративном процессе для испытаний используются те же основные инструменты, языки, нотации и артефакты, что и для разработки продукта. Под испытанием подразумевается детальная оценка на основе выполнения некоторого набора компонентов в рамках заданного сценария с ожидаемым объективным результатом. Успех испытания определяется путем сравнения ожидаемого и фактического результатов — обычно с применением хорошо определенной метрики успеха. Сами испытания и анализ их результатов могут быть в значительной степени автоматизированы. Представления о наилучшем способе превратить время в деньги показаны на рисунке в виде графиков готовности трех проектов. Степень завершенности проекта определяется процентом готового исполняемого кода. Оно лишь означает, что программу можно тестировать. Современный стиль управления подразумевает интеграцию на стадии проектирования. Благодаря выпуску последовательных рабочих версий можно раньше выявлять недостатки архитектуры и устранять их в ходе реализации проекта. Это позволяет на завершающих стадиях избежать кошмаров интеграции, запоздалых исправлений и пагубных заплат. Результат — поставленный в срок, надежный и удобный в обслуживании продукт, характеризуемый высокой вероятностью экономического успеха. График готовности обычного проекта, представленный на рисунке, все еще является нормой и характерен более чем для половины сегодняшних проектов. Хотя разработчики порой претендуют на использование современных итеративных методов, большинство из них применяют традиционный технический подход к управлению. Однако без адаптивного стиля руководства они не в состоянии выдать ожидаемые бизнес-результаты. Примерно к одному из четырех проектов применим современный график готовности и лишь к одному из восьми — перспективный график. Действительно ли управление программным проектом больше похоже на управление кинопроизводством, чем на управление строительством моста? Видимо, нет, особенно на завершающих стадиях, но эта аналогия может побудить вас к рассмотрению методов управления программными проектами в другой системе координат. Данные схемы не новы: Однако хочется подчеркнуть, что организации, принимающие адаптивный стиль управления, с большей вероятностью могут достичь экономического успеха. Уолкер Ройс weroyce us. Автор книги Software Project Management: Внес ключевой вклад в философию управления, являющуюся основой процесса RUP. Successful Software Management Style: IEEE Computer Society, , All rights reserved. Процессы разработки и использования программ становятся все более итеративными и эволюционными, что сопровождается интенсификацией взаимодействия участников программных проектов. Методология agile-программирования позволяет упорядочить реализацию эволюционирующих Нарушения работы ИТ-инфраструктуры становятся все более критичными для организаций, поэтому к качеству управления ею предъявляют все более серьезные требования. Многие российские компании переходят к сервисному управлению информационными технологиями, которое Сценарии - полезный инструмент, но неумение с ними обращаться вынуждает менеджеров запоздало реагировать на события, а не встречать их с упреждением. ИТ-проекты печально известны срывами сроков, перерасходом бюджетов, низким качеством результатов, и перемен к Несмотря на устойчивые архитектурные аналогии, SOA корректнее воспринимать как живой организм, способный адаптироваться к изменениям в бизнесе. В системах, построенных на принципах SOA, высокоуровневые прикладные компоненты, сервисы, взаимодействуют друг с другом и Computerworld LAN Директор ИС Открытые системы Windows IT Pro Мир ПК DGL. Тема номера Текущий номер Current Issue Архив Об издании About Issue. Адаптивный стиль управления программными проектами Руководителю проекта Менеджмент ИТ. ИТ-инфраструктура для вашего предприятия. Перспективы ретивого программирования Процессы разработки и использования программ становятся все более итеративными и эволюционными, что сопровождается интенсификацией взаимодействия участников программных проектов. Технологии внедрения ITSM Нарушения работы ИТ-инфраструктуры становятся все более критичными для организаций, поэтому к качеству управления ею предъявляют все более серьезные требования. Средства управления сервисами Несмотря на устойчивые архитектурные аналогии, SOA корректнее воспринимать как живой организм, способный адаптироваться к изменениям в бизнесе. Разное Платформы Академия ОС Современные архитектуры Тема номера Безопасность Руководителю проекта Менеджмент ИТ Alt. Об издательстве Об издании Обратная связь Как нас найти Контакты О републикации Теги Архив изданий Политика обработки персональных данных. RU Windows IT Pro Мир ПК DGL. RU Лечащий врач Publish What Hi-Fi Классный журнал Понимашка Мир ЦОД BIG DATA RUS. Средство массовой информации - www. Свидетельство о регистрации СМИ сетевого издания Эл. Выдано Федеральной службой по надзору в сфере связи, информационных технологий и массовых коммуникаций Роскомнадзором.


Акции в гипермаркетах спб каталог сегодня лента
Супер клей контакт инструкция
Стихи про марину о любви короткие
Стих из кинофильма брат 2
Forum стихи любимой дочке
Состав и полномочия арбитражных судов рф
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment