CUSTIS

Индивидуальные практики

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

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

Синтез уникального процесса разработки

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

Мы стараемся максимально осознанно использовать те ценные знания, которые десятилетиями закладывались в стандарты отрасли. Но при этом мы никогда не «перегибаем палку», избегая неэффективных бюрократических процедур, не приносящих пользы конкретному заказчикуClose Если заказчику нужна документация по ГОСТ, то мы включим ее создание в процесс. Если нет, то мы будем создавать проектную документацию в объеме, удовлетворяющем клиента и минимально необходимом для поддержки и развития проекта без каких-либо осложнений. . Наш девиз: «Нужно делать все, что необходимо для успеха, но не более того».

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

Гибкие, или Agile-методологии

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

В то же время в своем изначальном виде гибкие методологии ориентированы на проекты небольшого масштаба, с которыми в состоянии справиться команда из 5–7 человек. Для более крупных проектов Agile-методологии нужно дополнять необходимыми процедурами, регламентами и документацией, описанными в более сложных и формальных методологиях.

Стандарты и «тяжелые» методологии

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

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

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

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