В рамках доклада рассмотрим вопросы формирования команды с помощью модели МакКинси 7с (McKinsey 7s), поговорим о процессах разработки программного продукта, системе релизов, системном инжиниринге и рекомендациях по системе управления процессами. Выступление будет интересно руководителям команд разработчиков, особенно тем, кто фокусируется на предсказуемости сроков и качестве создаваемого решения.

1. Организация работы
распределенной команды
разработчиков программного
обеспечения
Сергей Смирнов
Altair Engineering Inc.
Director of Software Development

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

3. Непосредственный
запуск задач
Workload manager
Поток задач

4. Workload Manager Policy Manager
Job Submission & Control Visualization Analytics

5. Строительство команды
Этап 1:
Бизнес стратегия была ориентирована на активный рост каждого компонента пакета программ с целью
максимально быстрого удовлетворения требований пользователей.
Для строительства команды мы воспользоались популярной моделью McKinsey 7S

6. McKinsey 7S Model
Hard Elements
Strategy
Structure
Systems
Soft Elements
Shared Values
Skills
Style
Staff

7. Взаимодействие элементов модели McKinsey 7S
Бизнес стратегия наибольшее влияние оказала на:
- Структуру команды
- Системы: ИТ инфраструктуру и рабочие процессы
- Стиль работы

8. Director
Job Submission & Control
Visualization
Workload Manager
Policy Manager
QA
SPM
Analytics
Documentation
Структура команды - 1

9. Стиль Работы
- Быстрое и независимое принятие решений каждой командой
- Координация и интеграция изменений как дополнительный этап
- Координация интерфейсов как дополнительный этап
- Формируются параллельные островки экспертизы по идентичным аспектам, но обмен знаниями часто не
происходит

10. S/W-1 Development QA
ReleaseQA
. . .
Integration
Development QA
Development QA
S/W-2
S/W-N
Engineering Model

11. Строительство команды
Этап 2:
Бизнес стратегия сфокусирована на удовлетворене требований более широкой клиентуры. Повысились
требования к стабильности продукта, к более гомогенному прораммному интерфейсу интерфейсу,
критически важным стала практичность (usability) и тщательно проработанный опыт взаимодействия
пользователя (User Experience). Изменение стратегии наиболее сильно повлияло на:
Структуру
-- команды
-- продукта
Систему работы: ИТ инфраструктуру и рабочие процессы
– тестирование всего продукта целиком на одной системе
– процессы разработки и тестирования всего пакета программ а не отдельных компонентов.
Стиль работы: тщательное планирование пакета программ и опыта работы пользователя
Знания: выделенная команда опыта работы пользователя (UX)

12. Director
QA
UX
GUI
Services
Framework
S/W-1
S/W-2
S/W-N
. . .
Documentation
Структура команды - 2

13. UX GU ReleaseQAServices
S/W-1
S/W-2
S/W-N
. . .
Engineering Model

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

15. Анализ:
- Изменение первоначального способа работы в более интегрированный заметно способствовало
созданию более слаженного пользовательского интерфейса и хорошо согласованной
функциональности.
- Рекомендации по организации работы полученные из модели McKinsey 7S для 1 и 2 этапов
практически совпадают с рекоммендациями которые были получены с помющью других популярных
моделе, например модели Burke-Litwin
- Без структурного подхода базирующегося на модели легко упустить планирование одного или
нескольких из ключевых аспектов. В то же время, без подхода базирующегося на модели,
необходимые изменеия в способе работы кажутся слишком радикальными и встречают недостаточную
поддержку.
- Реструктурирование дает возможность лучше позиционировать уже имеющихся членов команды

16. Release Planning: Roadmap
Обсуждается с клиентами в каждом регионе
Обсуждаются и корректируются планы группы инфраструктуры и группы контроля качества
Обсуждается с командами разработчиков в каждом регионе
Общая картина дает разработчикам контекст для работы над конкретными проектами
20162015 2017 2018
v.10 v.10.1 v.11 v.11.1 v.12 v.12.1 v.13
F1
F3F2
F5
F6
F4
F7 . . .

17. 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"

18. Feature Development
1. Use Cases & Requirements
2. Архитектура
3. Функциональный дизайн
3. Детальный дизайн
4. Тест планы и автоматизация тестов
5. implementation
6. Матрица Аудита
Use Cases &
Requirements
Тест планы и
автоматизация
Архитектура Функ. Дизайн Дет. Дизайн Implementation
комментарии
sign-off
комментарии комментарии комментарии Code Review

19. Project Audit Sheet
Criteria Task Status Remarks
Use Case and Requirements (UCR) document signed-off Not Started
External design document (EDD) signed off Not Started
QA test scenarios developed and signed off Not Started
Internal design document (IDD) signed off Not Started
Coding is complete and checked into dev branch Not Started
Traceability matrix and reverse matrix developed along with test scenarios Not Started
QA test cases out for review (test case sign-off not necessary at this point) Not Started
Developer checkin test cases are signed off by QA Not Started
Code has been reviewed and signed off for checkin Not Started
Code is synced with mainline and reviewed again Not Started
Developer checkin test cases executed on Windows 7 or Server 2008r2 platform Not Started
Developer checkin test cases executed on at least one Unix platform Not Started
Developer checkin test cases executed on at least one Linux platform Not Started
Developer addresses any Critical or High priority bugs that arise from above testing Not Started
Developer reports all developer checkin test failures for review Not Started
Developer branch placed on nightly build list without additional errors Not Started
QA test cases reviewed and signed off Not Started
Code checked in to mainline Not Started
Mainline passes nightly build process Not Started
QA test added in TMS (after sign-off) Not Started
QA test executed on at least one Linux platform Not Started
QA test executed on at least one Unix platform Not Started
QA test executed on Windows 7 or Server 2008r2 platform Not Started
PROJECT COMPLETE Not Started

20. Feature Development
Анализ:
- Технические требования:
– сбор и обсуждение тех. требований должна осуществляется командой из того же региона / страны
– технические требования, реальные тех. требования, и что действительно требуется заказчикам
– недостающие технические требования
– избыточные технические требования, часто неосознанные. Проблемы которые они вызывают
- Тенденция некоторых программистов недооценивать важность архитектуры и дизайна и стремление
поскорее заняться кодированием. Первоначальная реализация всего 15% расходов в жизненном цикле
ПО. Важность sign-off на дизайн документах
- Тенденция программистов недооценивать “TDD", важность тест-планов и регулярного тестирования.
Авто-тесты, анализаторы исполняемого кода, статические анализаторы кода.
- Инспекции кода (code review), правила их проведения
- Тренировка разработчиков для лучшего понимания менталитета пользователя:
– dogfooding
– участие в установке и настройке ПО для заказчика
– внутренняя конференция разработчиков и настройщиков ПО
- Недооценка времени и нарушение сроков. “Agile” технологии разработки, transparency.

21. Bug Fixing
Распределенная команда ведет учет дефектов в общей системе отслеживания дефектов
Потенциальные проблемы:
- Устранение дефекта вызывает проявление уже существующих дефектов
- Исправление дефекта приводит к возникновению новых дефектов
- Задержка работы над дефектом высокого приоритета из-за работы над исправлением дефектов для
партнерской команды по их просьбе.
- Создание сервисного билета для мельчайших деталей. Перерасход времени менеджмента дефектов и
задержка технической работы.

22. Source Control and Branching Strategy

23. Комментарии:
- Стратегия ветвления определена во всех деталях в документе которому следуют все команды
– Когда, Кто и Как создает ветви исходного кода для каждой отдельной функциональности
– Когда, Кто и Как создает ветви для каждого релиза
– порядок и требования к code merge

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

25. Краткое Описание процесса
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

26. Комментарии:
Важность процесса:
- документ с описанием процесса, роли, и необходимые действия опубликован на Wiki где к нему
имеют доступ все команды
- перед началом каждого релиз цикла проводится обзор существующего процесса и проводятся
необходимые модификации
- тренинг всех команд с тем чтобы все ключевые лица знали кто и что именно должен делать на
каждом шаге. Дебаты "что делать дальше" как правило признак недрстаточного планирования
- для кажждой роли назначаются главный испольнитель и его последовательные заместители
Важность инновации и неструктурированного творчества:
- В течение 10% рабочего времени поощряется работа над собственными проектами не имеющими
отношения к релизу
- Идеи по созданию новых продуктов и новых функций регистрирутся разработчиками на специальном
портале
- Выдаются призы наиболее активным генераторам идей

27. - тесты как часть процесса разработки (TDD)
- ежедневная автоматическая сборка и полный авто-тест функциональности
- Performance Tests
- Scalability Tests
- Longevity Tests: симуляция среды нескольких клиентов с максимально различными условиями
- Security Review & Tests
Тесты функциональности
- Базирующиеся на сценарях (Use cases, traceability matrix)
- Базирующиеся на HBT
Контроль Качества (QA)

28. 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 методология

29. Data related Issues

30. Анализ:
- Оба подхода (Use Case driven & HBT driven) хорошо дополняют друг друга с тем чтобы полнее покрыть
пространство дефектов
- полнота покрытия, равномерность покрытия и ROI
- Scalability test, реалистические бенчмарки и стресс тестирование

31. - В последние годы резко усилился фокус на безопасность
- покомпонентный обзор безопасности
-- coding practices
-- file system permissions
-- SEC advisories
- тестирование с помощью инструментов проникновения (penetration tools)
- bounty hunts силами разработчиков
Security Review

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