release management что это

Release management: 5 steps of a successful process

If you’ve ever experienced a software release, you know just how complicated things can get. From managing project timelines to keeping track of due dates and scope, it’s a lot for one person to handle. That’s where release management comes in. With the right process in place, you’ll be able to manage even the most complicated of tasks.

Release management is a technique used to manage, plan, and control a software update to improve quality, speed, and efficiency.

We’ll go over what a release management process includes in more detail and provide a checklist to help you get started with your own release plan.

What is release management?

Release management is a technique used to manage, plan, and control a software update through different stages. The purpose of it is to improve the quality, speed, and efficiency of the software delivery. This ensures your team is prepared with the correct information at the right time, increasing the likelihood of a successful launch.

The release management lifecycle consists of five steps, which include planning, building, testing, preparing, and deploying a software update. Each stage is important for properly organizing and executing a successful release.

1. Release planning

The first step to launching software is to kick off planning with stakeholders in your development team. While there are several ways you can execute this step, common initiatives include running an initial meeting, writing a business case, and creating a work breakdown structure to outline project dependencies.

Each of these tasks will help you, the release manager, execute a system development lifecycle. In the planning phase, you should also connect with operations teams and leadership to get the software build approved and ready for development.

Here’s a release management planning checklist to use when starting this process:

Connect with stakeholders: Create a project summary report and send out in advance for stakeholders to review prior to your initial meeting.

Run an initial project kickoff meeting: Outline key details about the project, including the objective and success metrics.

Write a business case: Explain the value of the project and the impact it will have on your organization, along with long-term benefits.

Create a work breakdown structure: Visualize your project by breaking down dependencies into small tasks that are easy to understand.

Submit software for approval: Get approval from stakeholders and make project changes before your team gets started.

Plan your release schedule: Map, assign, and track project tasks in order to keep the software release moving forward.

Once you’ve completed this checklist, you’re ready for the next stage: building the software.

2. Release building

Step two of a release process is the most time-intensive as team members actually begin developing the software. In this stage, tasks should be assigned to stakeholders, and project information should have already been communicated.

Once the information is clear, team members can begin building the software while simultaneously testing and improving necessary features. It’s a good idea to begin tracking any potential risks or bugs within the production environment so you’re prepared for the testing phase.

Here’s a release management building checklist to use when starting this process:

Assign tasks to stakeholders

Execute project dependencies

Document software risks using a risk register

Roll out new features within a production environment

Automate initial testing

While teamwork and testing are necessary while building the software, the real testing will begin during the next phase.

3. Release testing

Perhaps even more important than building the software, the testing phase is incredibly important in order to make sure the software is running properly and ready for launch.

It’s helpful to have team members help identify and resolve any bugs that arise, but it’s also important to begin user testing in this step. While this will depend on how complex your software release is, user testing is an opportunity for consumers to test your software, usually in exchange for some type of reward.

You’ll also want to perform regression testing, which involves double-checking already approved functionality to verify it’s still working correctly.

Here’s a release management testing checklist to use when starting this process:

Begin end user acceptance testing (UAT)

Resolve or mitigate software risks

Identify software bugs

Perform regression testing

With software, testing is a large part of any release plan and can be time-consuming if numerous changes are needed.

4. Release preparing

In the preparation stage of a software release, your team will need to finish making necessary changes and optimizing the functionality within the staging environment. This ensures that every part of the software is working properly and ready to be pushed live.

It’s a good idea to have a final quality assurance check, if not multiple, to ensure all functionality is working properly. This can be done by you and your team, though it’s helpful to get help from team members who aren’t involved as they’ll be able to see the software with fresh eyes.

Here’s a release management preparation checklist to use when starting this process:

Replicate each software scenario

Optimize software integrations

Solve software bugs

Once you have given the software a final review and it’s been approved, you can begin deploying it in a live environment.

5. Release deployment

The final stage of a software release involves the use of deployment management. This is the process of executing the initial software idea and involves moving the functionality to a live environment.

In order to deploy the software release, more testing is required to ensure functionality is preserved in the live environment. Once that has been completed, it’s a good idea to continuously evaluate integrations and make necessary changes to improve functionality.

Here’s a release management deployment checklist to use when starting this process:

Deploy in a live environment

Test in a live environment

Employ continuous integrations

It’s also a good idea to close project tasks once the software is live and any needed changes to integrations have been made.

Release management vs. change management

While there are some similarities between release management and change management, the two differ quite significantly. Release management is the process of implementing a software product, while change management is the process of coordinating project or business changes using a change control process.

Here are some other key differences:

Release management focuses on configuring, planning, releasing, and testing a project.

Change management focuses on assessing, authorizing, requesting, and reviewing project changes.

So while release management mainly focuses on tasks around planning and scheduling projects, change management focuses on coordinating changes while a plan is being carried out.

Now that you understand what release management is and how it differs from change management, let’s look at which methodology is right for you.

Release management methodologies

While your software release should follow the five steps above no matter the method you use, there are a couple of different ways you can go about executing your release. These include Agile development and waterfall development.

While different, they offer a similar result. The method you use will depend on the complexity of the software itself and the size of your team. Let’s look at the features of each of these methods.

Agile development

Agile development is a project management method that involves planning a software release in small increments. These increments are often called sprints or iterations. The basic features of Agile management are:

Creating a roadmap

Prioritizing your product backlog

Setting logical goals

Breaking tasks down into smaller sprints

Agile development helps teams manage and execute a complex project like a software release more easily. It’s best suited for teams that need tasks broken down into small goals. This is usually the case with smaller teams that have large projects to tackle.

Waterfall development

While somewhat similar to Agile development in the sense that tasks are broken up, waterfall development is organized in a linear path. This means that each task is tied to a dependency and tasks that follow won’t be started until the previous dependency is complete. Other features of waterfall development include:

Planning and scheduling milestones

Implementing the plan

Verifying and testing

Maintaining and improving the plan

Waterfall development is best for larger projects and tends to be more detailed, though either method should result in a successful software launch if implemented correctly. The waterfall development process is best for teams looking for phase-specific tasks. This is usually the case for larger teams that have the required resources but need an organized method of execution.

The type of methodology that’s right for your team will depend on the size of your team and your preferred organizational style. When in doubt, try them both to find out which best fits your team’s needs.

Release management tools

Release management is important for a multitude of reasons. The simplest being that it helps to manage individual phases of a software release, creating a more manageable process overall. That’s why it’s so important to have the right work management software in place.

Helpful features of work management tools could include anything from task organization to automation to tracking bug reports. The right ones for you will depend on the IT services you need help with.

The right tool can help your team with the following:

Create a work breakdown structure

Make expectations clear

File and track bug reports

Prioritize project changes

All of these can not only help with a successful software release but also help to improve your overall team dynamic.

Use release management for future releases

Release management is a great process for software developers and DevOps teams to use when releasing a new software product. Not only can it help you catch new release errors in real time, but it can also ensure your IT infrastructure is ready for any updates that come your way.

Improve your IT operations one step further with our IT project templates.

Источник

Релиз-менеджмент: как подготовить проект к запуску за семь шагов

Релиз-менеджмент — это подготовка сайта или приложения к передаче пользователю. Рассказываем, что нужно сделать перед запуском проекта.

Первый шаг.
Планирование и критерии проверки

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

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

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

Выберите методы, которые будете использовать. Это может быть ручное или автоматическое тестирование, или, например, заранее написанные тесты. Релиз-менеджмент — это подготовка сайта или приложения к передаче пользователю. Рассказываем, что нужно сделать перед запуском проекта, чтобы все работало правильно.

Пишет про управление в Skillbox. Работала координатором проектов в Русском музее, писала для блога агентства
CRM-маркетинга Out of Cloud.

Второй шаг.
Проверка макета

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

Уже на этапе прототипа или макета можно проверить юзабилити, посмотреть, насколько ваш продукт удобен пользователю. В конце проекта лучше повторить этот тест еще раз.

Что почитать о юзабилити:

Третий шаг.
Проверка верстки

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

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

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

Четвертый шаг.
Проверка кода

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

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

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

Если у вас маленький проект, можно проводить тестирование дважды — когда будет готова вёрстка и потом проект целиком — либо вообще один раз, в финале разработки.

Пятый шаг.
Проверка функций

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

Для этого можно использовать ручное тестирование или софт, который проводит автоматическую проверку, например, SeleniumHQ.

Шестой шаг.
Проверка производительности и безопасности

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

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

Но один из параметров, прямо влияющий на доступность сайта пользователям, можно измерить просто. Речь идёт о скорости загрузки — как быстро загружаются ваши страницы у пользователя в браузере. Скорость загрузки сайта можно проверить автоматически, например, с помощью PageSpeed Insights от Google.

Ещё на этом этапе сайт проверяется на различные уязвимости. Для этого также есть разные сервисы, например, Metascan, которые делают это автоматически.

Седьмой шаг.
Мнение пользователя

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

Заключение

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

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

Источник

Управление релизами (Release management) по ITIL

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

Обычно работа над программным обеспечением, ИТ-системами и сервисами не заканчивается после этапа внедрения. Ведь улучшение и наращивание возможностей с учетом потребностей пользователей и roadmap продукта − неотъемлемая часть его жизненного цикла.

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

Что такое управление релизами

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

Управление релизами по ITIL − это комплексный процесс, объединяющий планирование, реализацию, тестирование и внедрение изменений в ИТ-продукт, а также контроль их качества при дальнейшем использовании.

Зачем автоматизировать процесс управления релизами

Внедрение процесса управления релизами позволяет:

Из каких этапов состоит процесс управления релизами

Ключевые этапы процесса управления релизами

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

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

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

Проводится тестирование доработок в собственной ИТ-среде. При необходимости формируются группы пользователей, которым предоставляется доступ к бета-версии для выявления критичных багов и первичной «обкатки» новых возможностей. По итогам тестирований производится финальная подготовка релиза с исправлением всех ошибок.

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

5. Контроль качества

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

Как ITSM 365 решает проблему управления релизами

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

Управление релизами с помощью сервис деск дает возможность быстрее выпускать качественные обновления ПО, отслеживать выполнение намеченных планов по продуктовому развитию, оценивать загрузку и корректировать объем работ, соблюдая дедлайны. Как результат − структурированный подход к реализации изменений делает процессы развития ИТ-систем и приложений прозрачными и понятными.

Источник

Процесс «Управление релизами» — для постпроектной поддержки или развития продукта

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

Процесс «управление релизами», один из стека процессов ITSM, как раз и предлагает решение для формальной приоритизации и группировки запросов пользователей (запросов на изменения, инцидентов) в общие пакеты доставки — «релизы».

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

Применимость процесса

Когда целесообразно применять процесс, в дополнение к управлению инцидентами и управлению изменениями? Разумеется, в каждом случае набор критериев разный, но перечисленные ниже сценарии — хороший повод задуматься о релизах:

Этапы процесса

Процесс состоит из последовательности этапов. В разных реализациях процесса некоторые этапы могут быть объединены, или могут называться по другому — но общий принцип сохраняется

1. Draft

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

Результат:
Все требования содержат высокоуровневую оценку сложности и рекомендации по группировке в релиз на основании области изменений и/или технических зависимостей.

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

2. Scope

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

Результат:
Полностью проанализированные запросы на изменения подготавливаются к финальному подтверждению содержания релиза. Запросы, для которых анализ или согласование не завершено — возвращаются в общий пул. Они — кандидаты на анализ (окончание анализа) в рамках следующего релиза

3. Approval

Активности:
Получение подтверждение ресурсов от исполнителей (для разработки) и заказчиков (дляд тестирования). Оценка общего бюджета релиза (если применимо). Финальное согласование с заказчиком содержания релиза, исходя из готовности отдельных запросов, приоритетов, оценённого бюджета, доступных ресурсов.

Результат:
Сформировано финальное содержание релиза.

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

4. Work in progress

Активности:
Разработка и исправление дефектов для всех заявок, вошедших в финальное содержимое релизов. Внутреннее тестирование и подготовка к приемочному тестированию.

Результат:
Заявки, включенные в содержание релиза — разработаны. Передача заказчику на приемочное тестирование.

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

5. Testing

Активности:
Проведение приемочного тестирования заказчиком, исправление выявленных ошибок, проведение необходимых доработок (по согласованию)

Результат:
Содержимое релиза протестировано, принято заказчиком, и готово к распространению.

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

6. Deployment

Активности:
Пакет изменений передается в эксплуатацию. Публикация новой версии продукта в продуктивной среде.

Результат:
Изменения перенесены в продуктивную среду и доступны заказчику

7. Closure

Активности:
Завершение работ над пакетом изменений: необходимые формальные шаги (документы, акты, счета ), обсуждение внутри команды результатов релиза.

Результат:
Формальное завершение работ. Улучшения процесса.

Планирование релизов

Как и любую активность, релизы нужно планировать. К счастью, управление релизами — это процесс, и поэтому при планировании можно рассчитывать на то что этапы, их взаимосвязь не меняются. Однако для планирования расписания релиза необходимо принципиально определиться с подходом к доставке:

Планирование релизов с фиксированной длительностью

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

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

Что будет меняться определенно — это ресурсы, доступные на каждом из этапов, в разных релизах (люди болеют, ходят в отпуск). Но с учетом перечисленных ограничений планирования это будет сказываться только на объем доставляемых изменений, а не на календарный план.

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

Планирование релизов от объема доставки

В случае, когда релизы планируются исходя из заданного объема изменений зафиксированных перед началом стадии анализа, а сроки сдачи оцениваются от сложности и ресурсов — от менеджера релизов требуется детальное планирование длительности каждого этапа. В этом смысле, релизы соответствуют стандартной «водопадной» модели разработки, планирование не отличается от планирования проекта.

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

Относительно сроков доставки, релизы, планируемые от объемов, также не предлагают заказчику большую определенность по сравнению с проектным подходом:

В дальнейшем будем обсуждать только детали, касающиеся релизов с фиксированной длительностью.

Календарное планирование релиза

Поскольку этапы определены, их взаимосвязи зафиксированы, и длительность каждого этапа будет неизменной, календарное планирование одно релиза не представляет сложности. Основной вопрос, с которыми необходимо определиться — длительность каждого из этапов.

Для этого можно попробовать использовать следующие данные, которые у вас могут быть на основании завершенного проекта:

Длительность этапов «Deployment» и «Closure» обычно устанавливается фиксированной, поскольку они на прямую не зависят от объема изменений. Разумеется, если зависимость в вашем случае существует — она должна учитываться.

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

В любом случае — используйте инструменты, предназначенные для календарного планирования (как, например MS Project). Особенно это важно при создании календаря с пересекающимися во времени релизами, поскольку нужно будет тщательно контролировать загрузку ресурсов.

Одновременное выполнение нескольких релизов

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

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

В случае, если вы строите процесс управления релизами с параллельными этапами — календарный план релиза должен учитывать перекрытия и загрузку ресурсов. Вполне возможно, что качественное расписание параллельно выполняемых релизов будет накладывать дополнительные требования на состав команды — так чтобы общая «выработка» Аналитиков и Разработчиков с учетом длительности этапов были равны.

Определение содержимого поставки при фиксированной длительности релиза

Посмотрим, из чего складывается ожидаемый объем содержимого релиза.

Фаза анализа требований

Объем заявок на изменения, которые могут быть проанализированы к рамках этапа «Scope» представляют максимальную неопределенность. Действительно — пока аналитик не начнет анализировать заявку, не поймет о чем идет речь, сказать сколько займет полный анализ очень сложно. Конечно, предварительный анализ заявок на стадии «Draft» поможет дать первую оценку, но ее можно использовать для распределения заявок между аналитиками — в зависимости от их специализации и опыта. Кроме того, необходимо учитывать, что аналитик вовлечен в приемочное тестирование — так что, анализом требований и передачей в разработку нагрузка на аналитика в рамках релиза не заканчивается.

Таким образом, первая оценка содержимого релиза может быть дана в терминах «количество заявок на аналитика в релиз». Наиболее пессимистичная оценка «1 заявка на изменение на аналитика в релиз» — с нее и стоит начинать. После того, как статистика по «производительности» аналитиков набрана — оценка содержимого станет более точной.

Подготовка технического решения

Работа по анализу технической реализации, на основании собранных требований, также требует времени и усилий — от группы разработки. Как правило, лидер группы отвечает за подготовку технической спецификации и оценки затрат на разработку.

Может случиться, что подготовка спецификаций занимает больше положенного времени и не укладывается в рамки стадии «Scope» — тогда запрос на изменение автоматически «выбывает» из содержимого текущего релиза.

Оценить сложность на подготовку технического решения можно только после завершения анализа. В качестве оптимистичной оценки можно всегда держать «все что было подготовлено аналитиком — будет проработано техническим лидером», хотя, конечно, это не всегда так.

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

Фиксация содержимого проекта

Оценка затрат на разработку, доступные ресурсы Разработчиков, доступность Заказчика для участия в приемочном тестировании — все это определяет финальное содержание релиза.

Итак, без учета переноса готовых запросов с предыдущих релизов — объем содержимого релиза ограничен сверху количеством проанализированных заявок (определяется ресурсами Аналитиков). Ограничения по ресурсам Разработчиков могут дополнительно сокращать объем релиза.

Известные проблемы

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

Переключение контекста при параллельных релизах

При планировании параллельных релизов возникает ситуация, когда все ресурсы — Аналитики, Заказчики и Разработчики должны «переключаться» между релизами. В частности, сценарии переключения следующие:

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

Ресурсные конфликты при нарушении календаря релиза

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

Исходя из конструкции этапов релиза и перехода между ними — наибольший негативный эффект имеет задержка этапов разработки и тестирования. Фазы анализа («Draft», «Scope», «Approval») имеют возможность понизить содержание релиза за счет переноса неоконченных заявок на следующий релиз — и это воспринимается заказчиком, обычно, легче, чем перенос из после утверждения содержания релиза.

Взятие «повышенных обязательств»

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

В качестве меры по можно использовать пессимистичную оценку объема ресурсов при фиксации содержимого релиза на этапе «Approval». Вообще тема «недооценки задачи/переоценки собственных сил и как с этим бороться» — очень дискуссионная. И решение очень сильно зависит от организационного окружения, в котором работает команда.

Реализация «больших» задач

Довольно часто в ходе анализа выясняется, что объем задачи не помещается во временные рамки этапа «Work in progress» — требуемый объем не получается разработать и доставить в рамках одного релиза.

Если увеличить ресурсы Разработчиков не представляется возможным, остается два возможных путей решения этой проблемы:

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

Устранение дефектов в контексте релизов

Обработка инцидентов и устранение дефектов, очевидно, занимают ресурсы команды (в большей мере — Разработчиков, но иногда и Аналитиков). Кроме того, нередко устранение некритических дефектов, имеющих известные способы обхода (workarounds) могут иметь меньшую ценность для бизнеса, по сравнению с требуемыми изменениями. Отсюда — очевидное желание рассматривать задачи устранения дефектов (или предоставления дополнительных сервисов) в общем контексте планирования содержания релиза — делать то, что важно.

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

В любом случае, необходимо учитывать наличие дефектов при оценке доступных ресурсов, которые можно выделить на содержимое релизов.

Заключение

Серьезным преимуществом процесса релизов (особенно, при релизах с фиксированной длительностью) в глазах заказчика является заранее объявленное дата выпуска, обычно привязанная к определённым календарным точкам (например — ежемесячно, ежеквартально). Это позволяет строить прозрачный и ритмичный процесс, с ожидаемыми по срокам контрольными точками (переходами между этапами) и ожидаемыми результатами на каждой точке. Кроме того, заказчик непосредственно вовлечён в определение содержимого релиза путём определения приоритетов.

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

Источник