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

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

Один из основополагающих принципов, который можно использовать для устранения таких трудностей, можно взять в методологии «Scrum». Незавершенный элемент работы (можно представить его в виде элементарной единицы работы) можно считать выполненным, если он соответствует т.н. «условиям выполнения». Условия выполнения могут разниться от проекта к проекту. Для некоторых команд это может означать, что выполняется условие регрессии. Однако одним из наиболее показательных условий выполнения является то, что элемент работы завершен и выполняется на производственной системе. Если учесть, что рывок не может длиться более 3 недель, получается, что каждые 3 недели необходимо внедрять все завершенные элементы в целевую среду. В результате в процессе завершения проекта не будет «финишных рывков». Не будет коренных изменений и перестроек системы. Будет лишь спокойное завершение последних элементов и введение их в производство.

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

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

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

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

Помодульная миграция также может быть не лучшим решением. Одновременное использование двух компоновок в одной системе в течение месяцев может вызвать большие трудности у разработчиков и привести к дополнительной ежедневной нагрузке на них. Для того, чтобы применить принцип маленьких шагов, необходимо старую систему «завернуть» в новую. Что это означает? В качестве первого шага используется принцип обращения новой системы к старой. Затем, шаг за шагом, функционал перемещается на систему новой компоновки, что происходит под наблюдением разработчиков и CI. Все малые изменения внедряются сразу по их завершению. Результат: отсутствуют резкие изменения в конце проекта.

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

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

Автор: Irina_Ua

Источник