Организация работы распределенной

команды разработчиков программного обеспечения

Сергей СмирновAltair Engineering Inc.

Director of Software Development

Кто мы и чем мы занимаемся?

Управление Высокопроизводительными Вычислениями (HPC)

Непосредственный запуск задач

Workload manager

Поток задач

Workload Manager Policy Manager

Job Submission & Control Visualization Analytics

Строительство команды

Этап 1:

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

Для строительства команды мы воспользоались популярной моделью McKinsey 7S

McKinsey 7S Model

Hard Elements

Strategy

Structure

Systems

Soft Elements

Shared Values

Skills

Style

Staff

Взаимодействие элементов модели McKinsey 7S

Бизнес стратегия наибольшее влияние оказала на:

- Структуру команды

- Системы: ИТ инфраструктуру и рабочие процессы

- Стиль работы

Director

Job Submission & Control

Visualization

Workload Manager

Policy Manager

QA

SPM

Analytics

Documentation

Структура команды - 1

Стиль Работы

- Быстрое и независимое принятие решений каждой командой

- Координация и интеграция изменений как дополнительный этап

- Координация интерфейсов как дополнительный этап

- Формируются параллельные островки экспертизы по идентичным аспектам, но обмен знаниями часто не происходит

S/W-1 Development QA

ReleaseQA

. . .In

tegr

atio

n

Development QA

Development QA

S/W-2

S/W-N

Engineering Model

Строительство команды

Этап 2:

Бизнес стратегия сфокусирована на удовлетворене требований более широкой клиентуры. Повысились требования к стабильности продукта, к более гомогенному прораммному интерфейсу интерфейсу, критически важным стала практичность (usability) и тщательно проработанный опыт взаимодействия пользователя (User Experience). Изменение стратегии наиболее сильно повлияло на:

Структуру

-- команды

-- продукта

Систему работы: ИТ инфраструктуру и рабочие процессы

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

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

Стиль работы: тщательное планирование пакета программ и опыта работы пользователя

Знания: выделенная команда опыта работы пользователя (UX)

Director

QAUX

GU

I

Ser

vice

s

Fram

ewor

k

S/W-1

S/W-2

S/W-N

. . . Doc

umen

tatio

n

Структура команды - 2

UX GU ReleaseQAServices

S/W-1

S/W-2

S/W-N

. . .

Engineering Model

распределенная команда

• Скорость: Разработка ПО продолжается круглые сутки, каждый день, по очереди, в нескольких временных зонах

• Покрытие: Поддержка пользователей по всему миру круглые сутки

• Региональные особенности: технические, культурные, юридические особенности ведут к необходимости локальных команд в разных странах.

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

• Стоимость проведения работ в разных странах

Анализ:

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

- Рекомендации по организации работы полученные из модели McKinsey 7S для 1 и 2 этапов практически совпадают с рекоммендациями которые были получены с помющью других популярных моделе, например модели Burke-Litwin

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

- Реструктурирование дает возможность лучше позиционировать уже имеющихся членов команды

Release Planning: Roadmap

Обсуждается с клиентами в каждом регионе

Обсуждаются и корректируются планы группы инфраструктуры и группы контроля качества

Обсуждается с командами разработчиков в каждом регионе

Общая картина дает разработчикам контекст для работы над конкретными проектами

20162015 2017 2018

v.10 v.10.1 v.11 v.11.1 v.12 v.12.1 v.13

F1F3F2

F5F6

F4

F7 . . .

Release Planning: 1-N List

Релизы “time-based" и “feature-based"

"Обязательный Список" и "Желательный Список"

"Обязательный Список" обсуждается с важнейшими клиентами в каждом регионе

Оценка ROI

"менталитет разработчика" vs. "менталитет пользователя"

1. Feature"X"

2. Feature "Y"

3. Feature "W"

4. Feature "Z"

5. Feature "B"

. . .

N. Feature "D"

Feature Development

1. Use Cases & Requirements

2. Архитектура

3. Функциональный дизайн

3. Детальный дизайн

4. Тест планы и автоматизация тестов

5. implementation

6. Матрица Аудита

Use Cases &

Requirements

Тест планы и

автоматизация

Архитектура Функ. Дизайн Дет. Дизайн Implementation

комментарии

sign-off

комментарии комментарии комментарии Code Review

Project Audit SheetCriteria Task Status RemarksUse Case and Requirements (UCR) document signed-off Not StartedExternal design document (EDD) signed off Not StartedQA test scenarios developed and signed off Not StartedInternal design document (IDD) signed off Not StartedCoding is complete and checked into dev branch Not StartedTraceability matrix and reverse matrix developed along with test scenarios Not StartedQA test cases out for review (test case sign-off not necessary at this point) Not StartedDeveloper checkin test cases are signed off by QA Not StartedCode has been reviewed and signed off for checkin Not StartedCode is synced with mainline and reviewed again Not StartedDeveloper checkin test cases executed on Windows 7 or Server 2008r2 platform Not StartedDeveloper checkin test cases executed on at least one Unix platform Not StartedDeveloper checkin test cases executed on at least one Linux platform Not StartedDeveloper addresses any Critical or High priority bugs that arise from above testing Not StartedDeveloper reports all developer checkin test failures for review Not StartedDeveloper branch placed on nightly build list without additional errors Not StartedQA test cases reviewed and signed off Not StartedCode checked in to mainline Not StartedMainline passes nightly build process Not StartedQA test added in TMS (after sign-off) Not StartedQA test executed on at least one Linux platform Not StartedQA test executed on at least one Unix platform Not StartedQA test executed on Windows 7 or Server 2008r2 platform Not StartedPROJECT COMPLETE Not Started

Feature DevelopmentАнализ:

- Технические требования:

– сбор и обсуждение тех. требований должна осуществляется командой из того же региона / страны

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

– недостающие технические требования

– избыточные технические требования, часто неосознанные. Проблемы которые они вызывают

- Тенденция некоторых программистов недооценивать важность архитектуры и дизайна и стремление поскорее заняться кодированием. Первоначальная реализация всего 15% расходов в жизненном цикле ПО. Важность sign-off на дизайн документах

- Тенденция программистов недооценивать “TDD", важность тест-планов и регулярного тестирования. Авто-тесты, анализаторы исполняемого кода, статические анализаторы кода.

- Инспекции кода (code review), правила их проведения

- Тренировка разработчиков для лучшего понимания менталитета пользователя:

– dogfooding

– участие в установке и настройке ПО для заказчика

– внутренняя конференция разработчиков и настройщиков ПО

- Недооценка времени и нарушение сроков. “Agile” технологии разработки, transparency.

Bug Fixing

Распределенная команда ведет учет дефектов в общей системе отслеживания дефектов

Потенциальные проблемы:

- Устранение дефекта вызывает проявление уже существующих дефектов

- Исправление дефекта приводит к возникновению новых дефектов

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

- Создание сервисного билета для мельчайших деталей. Перерасход времени менеджмента дефектов и задержка технической работы.

Source Control and Branching Strategy

Комментарии:

- Стратегия ветвления определена во всех деталях в документе которому следуют все команды

– Когда, Кто и Как создает ветви исходного кода для каждой отдельной функциональности

– Когда, Кто и Как создает ветви для каждого релиза

– порядок и требования к code merge

Процесс сертификации релиз-кандидата

Краткое Описание процесса

Actions Descriptions Outcome

Nightly Build This action will initiate the nightly build on the mainline/integration branch.

Packages are available in the nightly build area.

Sanity Test Test the packages from the build area for core functionality

Promoting the packages to the IP Area

Promote to IP The Engineering team representative copies the packages to the IP area after the sanity tests are successful

Integration Test Integration tests should test the packages for functionality that other dependent products rely on

Continue with the Next Action which is Complete QA Testing

Complete QA Tests QA continues testing the packages for RC qualification

Promote to RC The QA Team representative will promote/copy the packages to the RC area after QA deems that the packages are RC qualified.

promoting the packages to the RC Area

Комментарии:

Важность процесса:

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

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

- тренинг всех команд с тем чтобы все ключевые лица знали кто и что именно должен делать на каждом шаге. Дебаты "что делать дальше" как правило признак недрстаточного планирования

- для кажждой роли назначаются главный испольнитель и его последовательные заместители

Важность инновации и неструктурированного творчества:

- В течение 10% рабочего времени поощряется работа над собственными проектами не имеющими отношения к релизу

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

- Выдаются призы наиболее активным генераторам идей

- тесты как часть процесса разработки (TDD)

- ежедневная автоматическая сборка и полный авто-тест функциональности

- Performance Tests

- Scalability Tests

- Longevity Tests: симуляция среды нескольких клиентов с максимально различными условиями

- Security Review & Tests

Тесты функциональности

- Базирующиеся на сценарях (Use cases, traceability matrix)

- Базирующиеся на HBT

Контроль Качества (QA)

Aspect of Defects General Description

Data Incorrect defaults, Transformation, data loss

Structure Code issues, concurrency issues, deployment issues

Environment Insufficient resources, incorrect S/W versions, incorrect configuration

Business Logic Incorrect conditions, missing conditions, incorrect sequencing

Usage Difficulty in usage, unable to recover from mistakes, progress not shown

HBT методология

Data related Issues

Анализ:

- Оба подхода (Use Case driven & HBT driven) хорошо дополняют друг друга с тем чтобы полнее покрыть пространство дефектов

- полнота покрытия, равномерность покрытия и ROI

- Scalability test, реалистические бенчмарки и стресс тестирование

- В последние годы резко усилился фокус на безопасность

- покомпонентный обзор безопасности

-- coding practices

-- file system permissions

-- SEC advisories

- тестирование с помощью инструментов проникновения (penetration tools)

- bounty hunts силами разработчиков

Security Review

Спасибо!Вопросы?