Хочу поделиться опытом разработки и введения ай-ти процессов в проекте. Зачем нужны процессы? Они, отвечают многим разным целям, но в нашем случае основной целью было разграничение ответственности.
Многие программисты согласятся, что когда находят баг в уже работающей системе, вина сваливается на них. А кого же ещё? Ведь они его допустили! В итоге, мотивация понижается, имидж портится, и вообще — те, кто больше всех работает, получает больше всех пинков. А признание получают менеджеры, отдел продаж и прочие…
Месяцев 9 назад меня попросили ввести в один проект процессы. Проект очень большой и стратегический для организации — система собирает, обрабатыет и производит расчёты по всем оценкам всех учеников страны. Каждый год в сентябре начинается операционный цикл, который должен работать как часы, без ошибок и задержек. С января начинаются планирование изменения системы, а операционный цикл тем временем продолжается.
Я — не эксперт в процессах, поэтому всё рассказаное дальше основано на личном опыте. Однако опыт весьма положительный — количество дефектов, с которым система вошла в UAT было равно 0, и, в первый раз за 3 года, UAT началась во время и прошла с sign-off.
Шаг первый — где проблемы?
Первый этап в разработке процесса — установить, что плохого сейчас, и как этого избежать.
С этим вопросом я приставала ко всем — программистам, тестерам, аналитикам, менеджерам и прохожим на улицах. Оказалось что плохо — всё. Непротестированый код приходит в систему когда не надо, что невозможно отследить историю изменений, что непонятно кто за что ответственный, что базы постоянно переполняются, и многое другое.
Выводом этого этапа стал факт, что нужно точное распределение ответственности. Например:
— Когда программист внедряет код, он ответственный за его юнит-тестинг, и за то, что внедрение ничего не испортит
— Когда тестер говорит, что всё работает — ответственность за это решение уже на нём
— Когда аналитик подтверждает, что система годна для UAT — он ответсвенен за функционал
И т.д.
Шаг второй — определить процессы
Дальше я определила процессы, которые буду описывать. Так как система уже разработана, нам понадобился процесс для «изменения» (change request) и бага (defect).
Каждый процесс имеет начальные условия (precondition), шаги (steps) и конечное условие (post-condition). Шагом процессы может быть как простой шаг, так и разветвление, или другой процесс. Каждый процесс и шаг будут иметь свои inputs и outputs.
В процессе «Изменение» начальным условием стало «изменение и бизнесс-спецификация утверждены клиентом ». Это — гарантия того, что изменение нужно, и спецификация соответствует требованию клиента. Что клиент потом не скажет, что мы сделали совсем не то, что он просил, как это часто случалось раньше. Ниже — полная диаграмма процесса «Изменение» и описание его основных под-процессов.
Первым шагом в «изменении» — спецификация. Её готовит программист, ответственный за изменение, и она должна гарантировать ему, что его понимание требования — правильно. Когда аналитик подтверждает спецификацию — это зелёный свет для начала непосредственной разработки. Если по мнению аналитика спецификация неполна или неправильна, она отправляется на правку к программисту. В итоге повышается мотивация программиста и уверенность в том, что он удовлитворит пользовательские требования. Раньше часто случалось, что требования «понятны и так», и программист, сам того не замечая, делает допущения, которые не оправдывют ожидания аналитика и клиента. А теперь мы знаем, что и как мы будем делать.
Следующий шаг — программирование, которое заканчивается юнит тестом. Все объекты хранятся в SVN, при добавлении обязательны комментарии, места изменения кода прокомментированы хотя бы номером версии, и т.д. Так же была введена рекомендация по использованию SVN — когда создаётся новая ветка, когда она сливается с главной и так далее.
После него — внедрение. Как артефакт из него выходит Release Notes, в котором будет весь список изменённых объектов, советы по тестированию и так далее. Перед непосредственным внедрением в живую систему программист должен получить формальное разрешение от аналитика, чтобы изменение не нарушило «операционного цикла». Аналитик должен удостоверится, что код правильный — иногда просто постояв за спиной программиста, демонстрирующего функционал, или просматривая выход данных. После того, как внедрение разрешено, ответственность за влияние на систему на аналитике.
Процессы тестирования и дефекта детализоровать не буду — они есть, наверное, у всех, и всегда очень похоже. В моём случае был сделан акцент на разграничение ответственности, разрешение на внедрение.
Шаг третий — внедрение процессов
Это самое сложное. Тут надо убедить всех и каждого, что эти процессы — серебряная пуля. Потому что если хоть один не будет им следовать — всё насмарку!
Я делала презентации. Сначала главному начальству. Тут без проблем. Потом — аналитикам, которые постоянно задают каверзные вопросы и приходится править, снова и снова. Потом программистам, с которыми ещё хуже — приходиться доказывать, что спецификация нужна, и она совсем коротенькая, а от release notes толку больше, чем затрат.
После того как все убеждены, надо срочно переходить к действию. Я подготовила шаблоны документов, создала библиотеки в sharepoint, чтоб всем сразу было понятно, какой квадратик на диаграме в каком меню сайта.
Заработало!
Шаг четвертый — усовершенствования
По мере использования процесса, появляются новые идеи, как его оптимизировать, что где добавить. Документ процесса — живой документ и надо воодушевлять коллег на внесение изменений — важно, чтоб процесс всех устраивал и подходил для своей цели!
Выводы
Немного бюрократии внесло нужные изменения за эти 9 месяцев. Каждый член команды чувствует себя в относительной безопасности, потому что появилось больше точек проверки и подтверждения. С другой стороны, каждый чувствует ответственность за свою работу, потому что знает, что её качество будет проверено, проверено скоро, и поэтому больше старается. Кроме того, работать в организованой команде, где каждый знает, что он должен и чего нет повышает мотивацию.
Надеюсь, кому-нибудь пригодится мой опыт, а я с удовольствием отвечу на Ваши вопросы!
Многие программисты согласятся, что когда находят баг в уже работающей системе, вина сваливается на них. А кого же ещё? Ведь они его допустили! В итоге, мотивация понижается, имидж портится, и вообще — те, кто больше всех работает, получает больше всех пинков. А признание получают менеджеры, отдел продаж и прочие…
Месяцев 9 назад меня попросили ввести в один проект процессы. Проект очень большой и стратегический для организации — система собирает, обрабатыет и производит расчёты по всем оценкам всех учеников страны. Каждый год в сентябре начинается операционный цикл, который должен работать как часы, без ошибок и задержек. С января начинаются планирование изменения системы, а операционный цикл тем временем продолжается.
Я — не эксперт в процессах, поэтому всё рассказаное дальше основано на личном опыте. Однако опыт весьма положительный — количество дефектов, с которым система вошла в UAT было равно 0, и, в первый раз за 3 года, UAT началась во время и прошла с sign-off.
Шаг первый — где проблемы?
Первый этап в разработке процесса — установить, что плохого сейчас, и как этого избежать.
С этим вопросом я приставала ко всем — программистам, тестерам, аналитикам, менеджерам
Выводом этого этапа стал факт, что нужно точное распределение ответственности. Например:
— Когда программист внедряет код, он ответственный за его юнит-тестинг, и за то, что внедрение ничего не испортит
— Когда тестер говорит, что всё работает — ответственность за это решение уже на нём
— Когда аналитик подтверждает, что система годна для UAT — он ответсвенен за функционал
И т.д.
Шаг второй — определить процессы
Дальше я определила процессы, которые буду описывать. Так как система уже разработана, нам понадобился процесс для «изменения» (change request) и бага (defect).
Каждый процесс имеет начальные условия (precondition), шаги (steps) и конечное условие (post-condition). Шагом процессы может быть как простой шаг, так и разветвление, или другой процесс. Каждый процесс и шаг будут иметь свои inputs и outputs.
В процессе «Изменение» начальным условием стало «изменение и бизнесс-спецификация утверждены клиентом ». Это — гарантия того, что изменение нужно, и спецификация соответствует требованию клиента. Что клиент потом не скажет, что мы сделали совсем не то, что он просил, как это часто случалось раньше. Ниже — полная диаграмма процесса «Изменение» и описание его основных под-процессов.
Первым шагом в «изменении» — спецификация. Её готовит программист, ответственный за изменение, и она должна гарантировать ему, что его понимание требования — правильно. Когда аналитик подтверждает спецификацию — это зелёный свет для начала непосредственной разработки. Если по мнению аналитика спецификация неполна или неправильна, она отправляется на правку к программисту. В итоге повышается мотивация программиста и уверенность в том, что он удовлитворит пользовательские требования. Раньше часто случалось, что требования «понятны и так», и программист, сам того не замечая, делает допущения, которые не оправдывют ожидания аналитика и клиента. А теперь мы знаем, что и как мы будем делать.
Следующий шаг — программирование, которое заканчивается юнит тестом. Все объекты хранятся в SVN, при добавлении обязательны комментарии, места изменения кода прокомментированы хотя бы номером версии, и т.д. Так же была введена рекомендация по использованию SVN — когда создаётся новая ветка, когда она сливается с главной и так далее.
После него — внедрение. Как артефакт из него выходит Release Notes, в котором будет весь список изменённых объектов, советы по тестированию и так далее. Перед непосредственным внедрением в живую систему программист должен получить формальное разрешение от аналитика, чтобы изменение не нарушило «операционного цикла». Аналитик должен удостоверится, что код правильный — иногда просто постояв за спиной программиста, демонстрирующего функционал, или просматривая выход данных. После того, как внедрение разрешено, ответственность за влияние на систему на аналитике.
Процессы тестирования и дефекта детализоровать не буду — они есть, наверное, у всех, и всегда очень похоже. В моём случае был сделан акцент на разграничение ответственности, разрешение на внедрение.
Шаг третий — внедрение процессов
Это самое сложное. Тут надо убедить всех и каждого, что эти процессы — серебряная пуля. Потому что если хоть один не будет им следовать — всё насмарку!
Я делала презентации. Сначала главному начальству. Тут без проблем. Потом — аналитикам, которые постоянно задают каверзные вопросы и приходится править, снова и снова. Потом программистам, с которыми ещё хуже — приходиться доказывать, что спецификация нужна, и она совсем коротенькая, а от release notes толку больше, чем затрат.
После того как все убеждены, надо срочно переходить к действию. Я подготовила шаблоны документов, создала библиотеки в sharepoint, чтоб всем сразу было понятно, какой квадратик на диаграме в каком меню сайта.
Заработало!
Шаг четвертый — усовершенствования
По мере использования процесса, появляются новые идеи, как его оптимизировать, что где добавить. Документ процесса — живой документ и надо воодушевлять коллег на внесение изменений — важно, чтоб процесс всех устраивал и подходил для своей цели!
Выводы
Немного бюрократии внесло нужные изменения за эти 9 месяцев. Каждый член команды чувствует себя в относительной безопасности, потому что появилось больше точек проверки и подтверждения. С другой стороны, каждый чувствует ответственность за свою работу, потому что знает, что её качество будет проверено, проверено скоро, и поэтому больше старается. Кроме того, работать в организованой команде, где каждый знает, что он должен и чего нет повышает мотивацию.
Надеюсь, кому-нибудь пригодится мой опыт, а я с удовольствием отвечу на Ваши вопросы!
