апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

12.04.2024

На RIGF 2024 обсудили ключевые вопросы цифрового развития России

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2015 / Выпуск №5 (48) / Не меняйте проекты, как перчатки. Часть 3. Типы методик управления проектами ИТ. Гибкие и строгие методики

Рубрика: Управление проектами

 Марина Аншина, председатель Комитета по стандартам, Российский Союз ИТ-директоров

Не меняйте проекты, как перчатки
Часть 3. Типы методик управления проектами ИТ. Гибкие и строгие методики

Для устранения проблем была придумана технология Гибкой разработки ПО – Agile Programming – метод ведения проекта разработки, при котором можно учесть все влияющие на проект изменения

Да здравствует Agile!

В предыдущих статьях [1, 2] я неоднократно останавливалась на основной, с моей точки зрения, сложности, присущей ИТ-проектам, – высокой изменчивости.

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

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

Очевидно, чем раньше в последовательности этапов находится стадия, в которую требуется внести изменения, тем сложнее, дороже и рискованнее это делать. Поэтому самое опасное – это вносить изменения в требования.

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

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

В приложении к проектам разработки ПО классическую проектную модель, выросшую из проектов строительства зданий и сооружений, обычно называют каскадной или моделью водопада, и состоит она из следующих этапов:

• Определение требований. На этом этапе определяется, что именно надо сделать.
• Проектирование. В соответствии с подготовленными на предыдущем этапе требованиями выполняется технический проект (по ГОСТ 34 этому может предшествовать создание эскизного проекта, в котором определяются основные проектные решения).
• Конструирование, воплощение (также «реализация» или «кодирование»), выполнение на практике технического проекта.
• Тестирование и отладка (также «верификация») – проверка того, что программное обеспечение соответствует требованиям.
• Инсталляция и валидация – установка ПО в тестовую или рабочую среду, проверка его работоспособности в этой среде в сочетании с другими ее компонентами.
• Тестовая эксплуатация – период пробной эксплуатации, обычно на этом этапе старое ПО и новое ПО эксплуатируются одновременно. Заканчивается тестовая эксплуатация передачей ПО на сопровождение, выполнением завершающих проект действий, в частности, подписанием необходимых актов.
• Эксплуатация и поддержка – использование ПО для получения выгод, в расчете на которые оно создавалось.

Рисунок 1. Водопадная модель разработки ПО

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

• Сложность, а иногда и невозможность внесения изменений в требования. Заказчик и Исполнитель проекта часто обвиняют друг друга в том, что требования становятся неактуальными, упрекая партнера в низкой профессиональной квалификации. Однако в большинстве случаев потребность в изменении требований бывает продиктована объективными событиями внешней или внутренней среды компании-заказчика. Поэтому не стоит упрекать друг друга. Ведьне станете же вы требовать от партнера, чтобы он был провидцем или хорошим предсказателем. Все предугадать невозможно, а любое ПО гибко только в тех границах, которые в него заложили разработчики.
• Требования устаревают до окончания разработки продукта, поскольку в водопадной модели к ним не возвращаются, и каждое изменение требований – это большая проблема.
• Результат проекта отвечает прошлым, а не будущим потребностям организации-заказчика, а ведь потребности современных организаций подчас стремительно меняются, даже наперекор их желаниям.
• Строгое следование такой модели довольно часто приводит к полной бесполезности результата.

Все эти проблемы возникли не вчера и серьезно угнетали всех, кто имел отношение к разработке ПО. Для их устранения была придумана технология Гибкой разработки ПО – Agile Programming – в дословном переводе означает не только гибкий, но и живой. То есть это такой метод ведения проекта разработки, при котором можно учесть все влияющие на проект изменения.

Существует множество вполне конкретных, подробно описанных методов, относящихся к этой методологии, среди которых мне хочется выделить Extreme Programming и Scrum, как наиболее популярные в нашей стране.

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

«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

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

То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева» [3].

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

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

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

А когда такие, с позволения сказать, «Agile»-проекты заканчиваются неудачей (а ничего иного от них и ожидать нельзя), винят во всем сам принцип. Те, кто потратил немного времени, чтобы ознакомиться с одним из методов Agile, например, Extreme Programming (XP) или Scrum, прекрасно понимают, что это не так.

В манифесте были сформулированы также 12 основных принципов Agile-разработки:

Удовлетворение клиента за счет ранней и бесперебойной поставки ценного программного обеспечения

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

Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта)

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

Частая поставка рабочего программного обеспечения (каждый месяц или неделю или еще чаще)

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

Тесное ежедневное общение заказчика с разработчиками на протяжении всего проекта

Это позволяет своевременно выявлять необходимые изменения.

Проектом занимаются мотивированные личности, обеспеченные нужными условиями работы, поддержкой и доверием

Совершенно очевидный принцип, который, к сожалению, далеко не всегда выполняется. Внутренний пиар проектов ИТ оставляет желать лучшего.

Рекомендуемый метод передачи информации – личный разговор (лицом к лицу)

Бюрократия, обмен письмами и регламентами не поощряются в Agile-разработке, хотя в начале века ВКС и скайп были менее популярны. Я знаю множество случаев, когда эти методы успешно использовали для ХР и скрама.

Работающее программное обеспечение – лучший измеритель прогресса

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

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

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

Постоянное внимание улучшению технического мастерства и удобному дизайну

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

Простота – искусство не делать лишней работы

Давно известно, что чем ПО проще, тем оно лучше: надежнее, безопаснее, легче в обслуживании и гибче.

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

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

Постоянная адаптация к изменяющимся обстоятельствам

В Agile предполагается отслеживание, выяснение, вытягивание таких изменяющихся обстоятельств.

На рис. 2 графически отражены основные принципы Agile. Вы можете видеть, какое значение придается изменениям, роли непрерывного взаимодействия с пользователями и клиентами компании (в случае, если в выполняемом проекте ониявляются заинтересованными лицами), постоянной смене стадий разработки и расширению функционала ПО.

Рисунок 2. Основные стадии гибкой методологии

Agile-методы, в особенности Extreme Programming и ХР, постепенно заняли главенствующее место в разработке ПО. Современные международные стандарты процессов жизненного цикла систем (ISO/IEC 15288) и программного обеспечения (ISO/IEC 12207) учитывают эти методы, и их можно применять для таких проектов. Соответственно инструменты ведения проектов, такие, например, как Rational Rose также приспособлены для них.

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

А с учетом того, что изменений становится все больше и они учащаются, будущее за Agile.

1. Аншина М. Не меняйте проекты, как перчатки. Часть 1. Определение проектов ИТ, их особенности и место в деятельности организаций. // «БИТ. Бизнес&Информационные технологии», №3, 2015 г. – С.46-49 (http://bit.samag.ru/archive/article/1472).
2. Аншина М. Не меняйте проекты, как перчатки. Часть 2. Ландшафт современных стандартов, связанных с управлением проектами ИТ. // «БИТ. Бизнес&Информационные технологии», №4, 2015 г. – С.41-45 (http://bit.samag.ru/archive/article/1491).
3. Манифест гибкой разработки ПО (Agile Manifesto), февраль 2001 года, «Agile Alliance».

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи