Каталог решений - Основы управления распределенными программными проектами на платформе 1С:Предприятие

Особенность распределенной разработки в том, что одинаковые слайды можно по-разному показывать для разных групп потребителей. Так же как проекты распределенной программной разработки – в них можно выступать в нескольких ролях.

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

Как я пришел к этому?

Меня назначили руководителем проекта в команду одного из системных интеграторов. Мне сказали – у нас есть заказчик на 1С:Предприятие. Ты будешь руководителем проекта, но команду мы тебе не даем. Найди людей в интернете. Это случилось в 2002 году. Внедрение было связано с конфигурацией на платформе 7.7. Сам я до этого год проработал единственным программистом в достаточно крупном издательском холдинге. А тут от меня требовалось сделать что-то очень существенное за достаточно короткий срок.

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

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

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

С той поры я достаточно плотно заинтересовался именно итерационным подходом к разработке (иногда его еще называют «спиральный подход»). Теоретик организации управления программными проектами Барри Боэм описал некую структуру именно спирального подхода к разработке программных проектов.

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

За те три месяца, пока мы вели разработку, случилась ситуация, о которой я предупреждал заказчика на этапе постановки — бизнес заказчика изменился, требование, на котором настаивал заказчик, утратило актуальность.

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

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

В моем первом распределенном проекте было пять заданий. Пять человек делали эти задания и поочередно присылали мне свои решения. По мере того, как мне присылали выполненные решения, мне требовалось объединять полученные из разных источников результаты типовыми средствами сравнения и объединения конфигураций на платформе 7.7. Это заняло очень большое количество времени. Кроме того, оказалось, что в разных заданиях разных разработчиков есть пересекающиеся элементы. Например, у меня было пять разных реализаций одного справочника «Валюты». То есть, чтобы объединить решение, мне потом потребовалось два своих рабочих дня и около недели совместной работы с коллегой для приведения интерфейсов к единому стилю.

Кроме того, при полном изменении программного кода в результате такой переработки становится сложно предъявить претензию исполнителю в том, что его решение не работает (это уже не совсем его решение – к нему уже я приложился). То есть в результате могла сказаться ошибка исполнителя, ошибка при объединении или ошибка на этапе постановки задачи.

В конечном итоге оказалось, что 96 часов ушло на то, чтобы объединить 20-часовой результат труда.

Через 2 месяца в нашу команду влился Сергей Гуров – родоначальник применения средств коллективной разработки на платформе 7.7, автор почившего проекта Metabuilder.ru. Вследствие этого под наш проект были адаптированы такие средства коллективной разработки, как системы управления версиями. Также из Open Source-проекта было взято такое средство управления задачами, как Request Tracker (система контроля над выполнением задач).

Эти два решения мы адаптировали для использования в качестве средств коллективной разработки для платформы 1С:Предприятие 7.7. И в результате мы смогли получить систему, позволяющую объединять результаты труда нескольких разработчиков за ничтожно короткие сроки с минимальными усилиями. Можно сказать, что на объединение результатов 20-часового результата труда нескольких разработчиков у нас теперь требовалось 0 часов. Некоторые дополнительные усилия по объединению результатов труда, все-таки, появились при работе над  конфигурациями на платформе 1С:Предприятие 8 из-за более сложной структуры конфигурации. Например, процессы по администрированию очередей на изменения с привлечением дополнительных сотрудников. Однако, усилия были ничтожными в сравнении с ручным объединением результатов труда и, даже, в сравнении со штатным хранилищем.

Таким образом, мы смогли избавиться от лишних накладных потерь времени.

Разница между программными проектами и проектами, которые можно измерять, огромна. Когда мне задают вопрос – Сколько это будет стоить? – Откуда я могу знать, сколько это будет стоить, если мы сейчас находимся в месте, где 99% будущих трудозатрат нам неизвестно…

Но мы же можем сказать, сколько будет стоить построить дом –  строительство дома измеряется – этажи, годы, толщина стен, опыт предыдущих проектов и пр.

В нашем случае, программные проекты – это такие проекты, в которых отсутствует натуральный измеритель и критерии приемки результата субъективны (вплоть до "нравится/не нравится).

Кто-то считает, что задача проекта – это сохранение треугольника качества (в зависимости от денег, времени и функционала). Использую следующую формулировку измерения результата программных проектов для заказчика:

• Требуемая функциональность (на первом месте)
• К ожидаемому сроку (на втором месте)
• За приемлемую плату (на третьем месте)

Так как эти вещи субъективны, какой мне смысл сейчас что-то гадать, сколько это будет стоить? Поэтому – вернемся на пару слайдов. Берем короткую итерацию, даем действующий результат, проверяем, совпадают ли ожидания заказчика с этим результатом по стоимости и по срокам?

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

В типовом внедрении, которое было использовано мною в 2002, я практически действовал по технологии PMBoK (классическая схема с разработкой проектного задания). Поскольку этот проект был провальным, от использования этой технологии в следующих проектах отказался. Хотя, проблема не в том, по какой технологии делаешь, а в том, что у людей разный уровень мотивации. 

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

Сложность в том, что, приходится гадать и описывать «сферического коня в вакууме», как он будет выглядеть через 6 месяцев, а то и через год, если и сейчас непонятно, как он выглядит… Ведь, по сути, надо придумать иерархическую структуру работ, провести множество околопроектных дел (с заложенной ошибкой проектирования). А через полгода выясняется – меняется бизнес, меняются требования, и, как ни парадоксально, бизнес меняется довольно быстро!

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

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

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

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

Коллектив, средства и сложность – это множители. Процесс – это степень.

Если взять два различных проекта и сравнить их по этой формуле – то:

• Коллектив – примерно одинаковый
• Средства – примерно одинаковые
• Сложность проектов – примерно одинаковая
• А вот процесс – организация – сложности или проблемы или наоборот, вызванные именно взаимодействием среди участников этого проекта.

Когда участник действует относительно самостоятельно (принимая решения в одиночку) процесс в этом случае равен 1. На усилия это особо не влияет.

Как только одному разработчику нужно решение руководителя, да еще и согласовать с каким-то из финансовых директоров, то тогда усилия по проекту возрастают в степени — Процесс>=2. (вспомните бюрократию).

А если специалист может использовать результаты труда другого специалиста, то тогда Процесс < 1, и, с точки зрения организации самого взаимодействия в коллективе, если приложиться именно к оптимизации процесса, то окупается сразу. Как только в коллективе специалисты начинают действовать относительно самостоятельно, при этом имеют возможность пользоваться результатами труда других специалистов (получают определенный фронт работы, который может выполнить самостоятельно за разумный срок и за разумную плату), то сразу производительность труда резко возрастает. Мы снижаем усилия по проекту. Это один из принципов, который положен в основу именно организации коллективного взаимодействия и использования инструментов в системе управления требованиями и технологии «Управляемое внедрение».

Мы используем процессный подход к проектной деятельности.

Согласно стандартной модели CMMI есть категории процессов:

• Потребитель – поставщик
• Инженерная категория
• Вспомогательная категория
• Управленческая категория
• Организационная категория

Категория «Потребитель – поставщик»:

• Выявление требований
• Эксплуатационное использование
• Поддержка потребителя
• Совместные проверки

Инженерная категория:

• Анализ, достижение понимания, модель без доработок
• Проектирование
• Разработка
• Тестирование программных средств
• Интеграция и тестирование
• Сопровождение системы и программных средств

Вспомогательная категория

• Документирование
• Конфигурационное управление
• Верификация
• Контроль соответствия
• Совместные проверки
• Аудит
• Разрешение проблем

Организационная категория:

• Административное управление
• Управление проектами
• Управление качеством
• Управление рисками
• Организационные установки
• Управление кадрами
• Усовершенствование
• Повторное использование

Есть три большие группы процессов, пять категорий и у каждого процесса есть несколько степеней зрелости: Уровни зрелости процессов:

• Неполный
• Выполняемый
• Управляемый
• Устоявшийся
• Предсказуемый
• Оптимизируемый

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

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

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

Дальше у нас включается процесс «Анализ и достижение понимания требований», у которого должен быть результат – мы его называем «Воспроизводимый пользовательский пример (согласованный с заказчиком)». А потом включаются другие процессы – процесс «Конкурс концепции сроков и времени», процесс «Разработка», «Тестирование», «Передача результатов заказчику».

Если взять только инженерные процессы – мы получим картину «Лебедь, рак и щука». Мы можем все разработать, но у нас отсутствует процесс выявления требований, отсутствует процесс организации совместных проверок… 

  Если мы добавляем к инженерным процессам организационные – у нас уже есть какой-то успех.

  А если мы добавим все остальные группы процессов — процесс организации совместных проверок, процесс организации совместных испытаний, тестирование, валидация и пр., то получаем комплексный подход – и семья сыта и репка цела.

Что такое «Управляемое внедрение»?

Это три компоненты:

• Люди
• Программные средства
• Философия

Люди:

• Разработчики из числа внешних
• Руководители проектов внешние
• Внедрение, работа с потребителями – штатные сотрудники
• Тестеры внешние, штатные
• Со стороны Заказчика – хотя бы один представитель с навыками конструктивного письменного общения

Программные средства:

• CVS – управление изменениями
• Средства разборки/сборки конфигураций (GComp для 7.7, V8Parser для 8)
• RMS – управление требованиями (самописная система, блок управления задачами с блоком вступительного тестирования и блоком работы со взаиморасчетами)

Философия:

Джон Форбс Нэш (фильм «Игры разума»). Суть в том, что нобелевский лауреат по экономике много внимания уделил теории «Игр с ненулевой суммой». Нулевая сумма – это когда один выиграл, другой проиграл. Игры на Forex – это игры с отрицательной суммой – не важно, выиграл ты или проиграл, ты все равно платишь комиссию. А есть игры с положительной суммой. Сумма выигрыша может быть больше, чем сумма проигрыша. Простейший пример этой теории – это забастовка профсоюзов с требованием повышения заработной платы специалистам перед работодателям. Если они не договорятся – проиграют обе стороны. Если же каждая из этих двух групп действует чуть-чуть в интересах другой группы, то выиграют все (они могут договориться).

Эта философия заложена в RMS. Я делаю, проверяю, работает. А потом где-то нахожу объяснение, почему это работает. «Все уже украдено до нас». Все идеи уже давно объяснены математически и научно. Суть в том, что сотрудник, который выполняет определенные требования в системе управления требованиями – действует в своих интересах. Но система – прежде всего, построена в интересах заказчиков (для достижения требуемой функциональности к ожидаемому сроку за приемлемую плату). И вот, если сотрудник, сдавая свое решение, думает именно об этом – успех. Выигрывают все – сотрудник, руководитель, заказчик и я. Если вдруг сотрудник начинает действовать только в своих интересах, то – увы, проигрывают все. Сотрудник, например, не выполнил требование о технологии по оформлению сдачи решения. В этом случае руководитель потерял много времени на анализ, тестировщик много времени на тестирование, заказчик недоволен – прозевали сроки и, в конечном итоге, результат не достигнут. Заказчик уходит, с сотрудником прощаемся, сами исправляем эти ошибки на будущих проектах.

 *******

Статья написана на основе доклада, прочитанного на Конференции IE 2012 (15-16 ноября 2012 года). Также она опубликована в журнале Инфостарта №1

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.