Методики управления развитием ИС на базе

1С

Олег Демиденко

В момент внедрения системы и добавления функционала• Делают не то

• Делают одно, другое ломают

• Работы выполненные разными специалистами оказываются во взаимном противоречии

Причины проблемы: плохие коммуникации

• Каждый понял по своему что ему надо делать. Заказчик ждёт одно, программист может очень хорошо сделать но не то, что нужно

• Бизнес-заказчики и программисты не знают над чем работают их коллеги.

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

В чем проблема? Зачем какие-то методики?

В чем проблема? Зачем какие-то методики?

При развитии системы• Забывается что и зачем было сделано. Появляется священный страх

делать изменения (а вдруг что-нибудь сломается)

• Стоимость добавления нового функционала растёт, т.к. внедрить его учтя все взаимосвязи становится всё сложнее

Причины проблемы:• Отсутствие документации проектных решений

• Плохая архитектура – сложно разобраться в клубке разных программных функций непонятно как и зачем связанных между собой

В чем проблема? Зачем какие-то методики?

При смене системы • Никто не помнит зачем старая система так работала. Поэтому

выбирают один из двух путей: делают новую систему как копию старой, сохраняя груз проблем. Или делают новую систему с нуля, с огромными повторными затратами на бизнес-анализ.

Причины проблемы:• Отсутствие документации проектных решений

В чем проблема? Зачем какие-то методики?

• Некачественная передача информации между людьми, или вообще отсутствие коммуникации.

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

• Некоторые проектные решения иногда неоптимально влияют на ИС, делаются наспех, в виде заплаток. Копится груз проблем.

• Бывает что и в тепличных условиях технари дают плохой результат

Итого:• 2,5 проблемы имеют организационную причину.

• 1,5 проблемы имеют техническую причину (недостаток тех.квалификации)

В чем корень проблемы

• Нужно чтобы Заказчик и Исполнитель смогли точно понять друг друга, чтобы Исполнитель сделал то, что нужно Заказчику

• Разработчики должны общаться между собой, чтобы не ломать работу друг друга

• Архитектор системы должен вовремя и понятно сообщить о критическом числе заплаток и необходимости провести рефакторинг, приводящий систему в божеский вид

Методики решения:• Обсуждение требований в виде максимально исключающим

взаимонепонимание: простой язык, наглядные примеры

• Разработчики должны регулярно общаться, на стадии проектирования своих доработок, чтобы не оказалось что что-то было сделано зря

• Учет «Технического долга» накопленного при проектировании системы

Задача – наладить коммуникации

Пойдем от обратного:

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

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

• Не используйте графические картинки и схемы

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

• Не показывайте заказчику промежуточный прототип, всё равно не поймет. Только время зря потратим.

Как однозначно понять друг друга?

• Разработчик и заказчик должны провести достаточное время в обсуждении сути задачи и выработки эффективного подхода к её решению. Они должны придти к однозначному общему пониманию задачи

• Договоренности должны быть задокументированы простым и достаточно исчерпывающим способом. Сценарии использования, схемы бизнес-процессов, графические схемы.

• До реализации полного функционала должен быть разработан интерфейсный прототип. Данный прототип должен быть обязательно согласован с заказчиком, чтобы убедиться что разработка ведётся в верном направлении.

Как однозначно понять друг друга?

• Необходимо чтобы программисты согласовывали друг с другом проекты на предмет выявления нестыковок

• Необходимо чтобы программисты обменивались информацией о работе друг друга, чтобы итоговый результат было более унифицированным в подходах и за счет этого, более эффективным в использовании.

Не продуктивные варианты:

• Схема «звезда» не работает. Один человек не способен проконтролировать полную стыковку всех блоков уже в команде от 5 человек. Особенно если он играющий тренер и одновременно сам отвечает за самый сложный блок работ.

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

Как согласовать работу разработчиков

• Необходимо чтобы программисты согласовывали друг с другом проекты на предмет выявления нестыковок

• Необходимо чтобы программисты обменивались информацией о работе друг друга, чтобы итоговый результат было более унифицированным в подходах и за счет этого, более эффективным в использовании.

Не продуктивные варианты:

• Схема «звезда» не работает. Один человек не способен проконтролировать полную стыковку всех блоков даже в небольшой команде.

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

Как согласовать работу разработчиков

Организация совместной разработки в фирме 1С

с использованием «Системы проектирования прикладных

решений»

• Описание всего в IDEF 0.Бывает полезно при согласовании и объяснении верхнеуровневой архитектуры, на уровне руководства. Внутри отделов разработки используется редко

Что вообще умеет СППР

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

• «Память» проекта – кто что и зачем сделал

• Контроль формальных правил выполнения проекта: контрольные точки и контрольные вопросы

«Технический проект»

• Способ формализации подхода к выполнению задач

«Технический проект»

• Контроль выполненных изменений

«Технический проект»

• Средство подготовки встроенной справки и документации к релизам

• История изменений в разрезе объектов метаданных

• Реестр требований, с указанием источников, ответственных и приоритетов; возможностью группировки по тематикам

• Баг-трекер

• Система постановки задач друг другу

• Интеграция с документооборотом

• Поддержка работы с несколькими хранилищами/ветками разработки

Что еще есть в СППР

СППР – не самоцель. И, возможно, не самый удобный инструмент.

Преимущества СППР:

• Однообразно по всей компании

• На платформе 1С, можно дорабатывать под свои нужды

• Есть положительный опыт из фирмы 1С по разработке сложных систем

• У нас есть тоже положительный опыт

• Это технология, которую активно рекламирует сама фирма «1С» на всех своих бизнес-форумах, посвященных ERP.

• Технологию СППР фирма 1С обязывает использовать на VIP-проектах, которые проходят под её надзором

Почему именно СППР?

Спасибо за внимание