Введение
Область планирования и управления программными проектами
Управление программными проектами — это процесс планирования и управления программными проектами. Это поддисциплина управления проектами, в рамках которой программные проекты планируются, разрабатываются, отслеживаются и контролируются.
Процесс разработки программного обеспечения
Процесс разработки программного обеспечения в основном касается производственного аспекта разработки программного обеспечения, в отличие от технического аспекта, такого как программные инструменты. Эти процессы существуют прежде всего для поддержки управления разработкой программного обеспечения и, как правило, ориентированы на решение бизнес-задач. Многие процессы разработки программного обеспечения могут выполняться аналогично процессам общего управления проектами. Примеры: межличностное общение, управление конфликтами и их разрешение. Активное, частое и честное общение является наиболее важным фактором для повышения вероятности успеха проекта и смягчения проблемных ситуаций. Команда разработчиков должна стремиться к вовлечению конечных пользователей и поощрять их вклад в процесс разработки. Отсутствие участия пользователей может привести к неверной интерпретации требований, нечувствительности к изменяющимся потребностям клиентов и нереалистичным ожиданиям со стороны заказчика. Разработчики программного обеспечения, пользователи, руководители проектов, клиенты и спонсоры проектов должны регулярно и часто общаться. Информация, полученная в результате этих обсуждений, позволяет команде проекта анализировать сильные и слабые стороны, возможности и угрозы (SWOT) и использовать эту информацию для извлечения выгоды из возможностей и минимизации угроз. Даже плохие новости могут быть полезными, если о них сообщается относительно рано, поскольку проблемы можно смягчить, если их не обнаружить слишком поздно. Например, непринужденные беседы с пользователями, членами команды и другими заинтересованными сторонами часто позволяют выявить потенциальные проблемы раньше, чем на формальных встречах. Все сообщения должны быть интеллектуально честными и подлинными, а регулярная, частая и качественная критика работы по разработке необходима, если она предоставляется спокойно, уважительно, конструктивно, без обвинений и гнева. Частые неформальные контакты между разработчиками и конечными пользователями, а также между руководителями проектов и клиентами необходимы для того, чтобы проект оставался актуальным, полезным и эффективным для конечных пользователей и укладывался в рамки того, что можно завершить. Эффективная межличностная коммуникация, управление конфликтами и их разрешение являются ключевыми факторами управления программными проектами. Ни одна методология или стратегия улучшения процессов не может преодолеть серьезные проблемы в общении или неэффективное управление межличностными конфликтами. Более того, результаты, связанные с такими методологиями и стратегиями улучшения процессов, улучшаются за счет улучшения коммуникации. Коммуникация должна быть сосредоточена на том, понимает ли команда устав проекта и добивается ли она прогресса в достижении этой цели. Конечные пользователи, разработчики программного обеспечения и руководители проектов должны часто задавать элементарные, простые вопросы, которые помогают выявить проблемы до того, как они перерастут в серьезные неудачи. Хотя участия конечных пользователей, эффективной коммуникации и командной работы недостаточно, они необходимы для обеспечения хорошего результата, а их отсутствие почти наверняка приведет к плохому результату. Управление рисками — это процесс измерения или оценки риска и последующей разработки стратегий управления этим риском. В общем случае используемые стратегии включают передачу риска другой стороне, избежание риска, снижение негативного воздействия риска и принятие некоторых или всех последствий конкретного риска. Управление рисками в управлении программными проектами начинается с обоснования для начала проекта, которое включает анализ затрат и выгод, а также список запасных вариантов на случай неудачи проекта, называемый планом действий в чрезвычайных ситуациях. Подмножеством управления рисками является управление возможностями, что означает то же самое, за исключением того, что потенциальный результат риска будет иметь положительное, а не отрицательное влияние. Хотя теоретически это обрабатывается одинаково, использование термина «возможность», а не несколько негативного термина «риск», помогает команде сосредоточиться на возможных положительных результатах любого данного реестра рисков в их проектах, таких как спин-офф проекты, непредвиденные выгоды и бесплатные дополнительные ресурсы. Управление требованиями — это процесс выявления, сбора, документирования, анализа, отслеживания, приоритизации и согласования требований, а также контроля изменений и информирования соответствующих заинтересованных сторон. Проблема может быть ошибкой, запрошенной функцией, задачей, отсутствующей документацией и так далее. Например, OpenOffice.org раньше называл свою модифицированную версию Bugzilla IssueZilla, а с сентября 2010 года они называют свою систему Issue Tracker.
Interpersonal communication and conflict management and resolution. Active, frequent and honest communication is the most important factor in increasing the likelihood of project success and mitigating problematic projects. The development team should seek end user involvement and encourage user input in the development process. Not having users involved can lead to misinterpretation of requirements, insensitivity to changing customer needs, and unrealistic expectations on the part of the client. Software developers, users, project managers, customers and project sponsors need to communicate regularly and frequently. The information gained from these discussions allows the project team to analyze the strengths, weaknesses, opportunities and threats (SWOT) and to act on that information to benefit from opportunities and to minimize threats. Even bad news may be good if it is communicated relatively early, because problems can be mitigated if they are not discovered too late. For example, casual conversation with users, team members, and other stakeholders may often surface potential problems sooner than formal meetings. All communications need to be intellectually honest and authentic, and regular, frequent, high quality criticism of development work is necessary, as long as it is provided in a calm, respectful, constructive, non accusatory, non angry fashion. Frequent casual communications between developers and end users, and between project managers and clients, are necessary to keep the project relevant, useful and effective for the end users, and within the bounds of what can be completed. Effective interpersonal communication and conflict management and resolution are the key to software project management. No methodology or process improvement strategy can overcome serious problems in communication or mismanagement of interpersonal conflict. Moreover, outcomes associated with such methodologies and process improvement strategies are enhanced with better communication. The communication must focus on whether the team understands the project charter and whether the team is making progress towards that goal. End users, software developers and project managers must frequently ask the elementary, simple questions that help identify problems before they fester into near disasters. While end user participation, effective communication and teamwork are not sufficient, they are necessary to ensure a good outcome, and their absence will almost surely lead to a bad outcome. Risk management is the process of measuring or assessing risk and then developing strategies to manage the risk. In general, the strategies employed include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Risk management in software project management begins with the business case for starting the project, which includes a cost benefit analysis as well as a list of fallback options for project failure, called a contingency plan. A subset of risk management is Opportunity Management, which means the same thing, except that the potential risk outcome will have a positive, rather than a negative impact. Though theoretically handled in the same way, using the term "opportunity" rather than the somewhat negative term "risk" helps to keep a team focused on possible positive outcomes of any given risk register in their projects, such as spin off projects, windfalls, and free extra resources. Requirements management is the process of identifying, eliciting, documenting, analyzing, tracing, prioritizing and agreeing on requirements and then controlling change and communicating to relevant stakeholders. New or altered computer system An issue could be a bug, a requested feature, task, missing documentation, and so forth. For example, OpenOffice. org used to call their modified version of Bugzilla IssueZilla. as of September 2010, they call their system Issue Tracker.
Управление эмиссией
В некоторых реализациях процессов разработки программного обеспечения проблемы исследуются аналитиками по обеспечению качества, система проверяется на корректность, а затем передается члену команды разработчиков для устранения выявленной проблемы. Проблемы также могут быть обнаружены пользователями системы в ходе этапа приемочного тестирования (UAT). Проблемы могут регистрироваться и передаваться с использованием систем отслеживания проблем или дефектов. Если формальная система отслеживания проблем или дефектов отсутствует, обычно используют любую форму письменной коммуникации, такую как электронная почта или мгновенные сообщения, для сообщения об обнаруженной проблеме.
Философия
Как поддисциплина управления проектами, некоторые считают управление разработкой программного обеспечения аналогичным управлению производством, которое может осуществлять человек, обладающий управленческими навыками, но не имеющий навыков программирования. Джон К. Рейнольдс возражает против этой точки зрения, утверждая, что разработка программного обеспечения – это полностью работа по проектированию, и сравнивает менеджера, не умеющего программировать, с главным редактором газеты, не умеющим писать.