Продолжаю серию заметок о различиях заказного ПО и программного продукта. Я уже упоминал о том, что причиной долго времени внесения изменений в ИТ системы может являться сам процесс внесения изменений. Все мы учились на унифицированном процессе разработки ПО. Потому верим в цикл разработки, включающий сбор и анализ требований, проектирование, разработку, тестирование и развертывание решения. Большинство попыток оптимизации этого цикла сводятся к сокращению времени этих фаз. Гибкие методологии, такие как SCRUM предлагают зафиксировать вместо объема работ длительность итерации, т.е. цикл (sprint) разработки составляет всегда X недель (2 или 4), а объем требований для каждого цикла разработки определяется исходя из их сложности. В любом случае, внесение изменений в систему осуществляется только посредством разработки.
Готовые программные продукты должны отказаться от идеи внесения изменений только посредством доработок. Иначе не очень понятно, зачем покупать дорогие лицензии, если любое изменение потребует программирования. Впрочем, в продуктах зачастую и программирования никакого не требуется. Разработчик в красивом редакторе рисует бизнес-процессы, пишет бизнес-правила, создает модели данных и т.п. Довольно расточительно использовать для управления такой деятельностью традиционный цикл разработки ПО. Программный продукт кроме непосредственно кода и документации должен предоставлять документированный и принимаемый заказчиком процесс внесения таких изменений. Не следует путать этот процесс с [software] configuration management. Это разные процессы.
Как должен выглядеть этот процесс? Сохраняются ли в нем работы из unified process. Некоторые, безусловно, сохраняются. Например, требования собирать надо. Но делать это следует не формате IEEE 830 или SRS в стиле RUP. Требования следует формулировать на языке программного продукта, в специализированных шаблонах. А еще лучше это делать внутри самого программного продукта (Social BPM – это как раз об этом). Возьмем, кстати, BPMS для примера. Очевидно, что изменение в BPMS может включать в себя: появление новых ролей, добавление или изменение непосредственно процессов, появление новых типов активностей, как пользовательских (новый тип задачи), так и автоматических (вызов нового web-сервиса). Если мы даже не используем BPMS для сбора и согласования требований, то несложно сделать простой шаблон документа, с соответствующими полями и просить заполнить его в запросе на изменение. Нет никакого смысла писать функциональные требования в формате русскоязычной прозы или техническое задание по ГОСТу.
То же самое относится к повторно-используемым компонентам. Компонент не станет повторно-используемым, если вы не сопроводите его процедурой повторного использования. Администраторы давно придумали чек-листы для управления подключениями к своим системам. Выдача connection string для доступа к базе данных, заведение учетной записи для технологического подключения по HTTР к web-сервису у хорошего администратора сопровождается заполнением такого чек-листа. В нем, кроме функциональных характеристик взаимодействия указываются и нефункциональные: количество обращений, ожидаемое время отклика и т.п. У программиста другая логика. В его картине мире новое подключение к базе данных почти наверняка будет сопровождаться написанием новой процедуры или view. А это, автоматически, новая итерация разработки, со всеми сопровождающими её активностями
Настройка готовых программных продуктов и повторно-используемых компонент должна осуществляться по специальным процедурам, отличающимся от процедуры девелопмента. Согласование требований, тестирование, развертывание(лучше сказать внесение изменений в продуктивную среду) должны вести по другому процессу, основанному на других документах нежели процесс разработки ПО.
>> Довольно расточительно использовать для управления такой деятельностью традиционный цикл разработки ПО
А в чем собственно отличия? Есть бизнес-требование, его надо решить. Можно запрограммировать решение с нуля, а можно запрограммировать решение в готовом продукте путем конфигурации этого продукта (нарисовали бизнес-процессы в редакторе BPMS).
Иногда для программирования будет достаточно простых карточек с историями пользователей (Scrum). Иногда для программирования будет необходимо согласовать ТЗ. Ровно тоже самое можно сказать и про конфигурацию (или кастомизацию, кому как больше нравится).
Выбор той или иной структуры процесса (разработки, поддержки или внедрения), а равно и формата внутренних артефактов, зависит далеко не от объема будущей кодовой базы, а скорее от окружения, представителей бизнеса, формата взаимодействия, возможностей исполнителя и т.п.
На мой взгляд, хороший программист должен заниматься разработкой хороших программ, а не «допиливать» решение под сиюминутные требования пользователя. Решение от этого пострадает, да и изменения могут оказаться невостребованными. Я понимаю, что в свое время в нашей стране было много хороших и дешевых разработчиков. Сейчас я регулярно слышу о том, услуги по разработке ПО слишком дороги для заказчика и слишком дешевы для разработчика. А заказчики еще и сроками доработок недовольны. А разработчики в ответ говорят о том, что заказчик сам не знает что хочет, требования дает плохие, долго согласует ТЗ и утверждает бюджет.
Решение в том, чтоб делать настройки силами менее дорогостоящих специалистов. Можно назвать их аналитиками, можно, для поднятия их самооценки — архитекторами.
Но для того, чтоб все это заработало нужно, чтоб вместе с программным продуктом поставлялся процесс для таких людей. А программисты пусть «эпохалку» ваяют в комфортных условиях.
И пользователю будет спокойней не слышать слова про абстрагирование, инкапсуляцию, наследование и полиморфизм. А то у пользователей от таких слов в голове разрыв между бизнесом и ИТ происходит. Надо их жалеть!
Ну, если рассуждать с позиции того, что программистов необходимо холить и лелеять, то конечно же, их нужно отгородить от всякого рода неопределенностей и «допиливаний» путем использования «правильных» процессов… Только это тупиковый путь.
Поскольку очевидно, что есть различные уровни адаптируемости софта (что не само по себе, а во имя экономии, качества и др. преимуществ реюза), не менее очевидна необходимость в различных способах «программирования» этого софта.
Как называть этих людей? А, что ABAP или 1C — это не языки программирования?
А почему тупиковый? Разработчики будут лишены обратной связи или причина тупиковости в чем-то другом?
На мой взгляд, тупик состоит в том, что кодеры (а именно они будут созданы в условиях изоляции от реальности) индустрии практически не нужны, а нужны специалисты широкого профиля, на чем собственно и базируются легковесные методологии типа Scrum.
Безусловно, найдутся места, где востребованными будут именно узкоспециализированные специалисты, слабо владеющие смежными дисциплинами. Это самостоятельная ниша, про нее конечно же речь не идет.
Что до современного программиста, то он просто обязан быть немного менеджером, продавцом (или маркетологом), аналитиком, архитектором, тестировщиком и даже писателем технической документации. Не надо быть экспертом в каждой области, надо понимать основы, цели и задачи каждой дисциплины… Тогда и формализовывать процесс не потребуется.
Макс, а ты сталкивался с инструментарием для оформления ФТ в виде изменений бизнес процессов? Я не могу подобрать нужный инструмент.