Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной команды разработчиков ПО
Download as PPTX, PDF2 likes598 views
Документ описывает организацию и стратегию работы распределенной команды разработчиков программного обеспечения, акцентируя внимание на модели McKinsey 7S для построения команд и управления процессами. Рассматриваются два этапа бизнеса: первый фокусируется на росте компонентов пакета программ, в то время как второй акцентирует внимание на стабильности продукта и пользовательском опыте. Документ также затрагивает важность процессов тестирования, управления дефектами и методологии разработки, включая Agile и подход TDD.
Сергей Смирнов (Altair Engineering Inc.) | Организация работы распределенной команды разработчиков ПО
- 1. Организация работы распределенной команды разработчиков программного обеспечения Сергей Смирнов Altair Engineering Inc. Director of Software Development
- 2. Кто мы и чем мы занимаемся? Управление Высокопроизводительными Вычислениями (HPC)
- 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
- 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 методология
- 30. Анализ: - Оба подхода (Use Case driven & HBT driven) хорошо дополняют друг друга с тем чтобы полнее покрыть пространство дефектов - полнота покрытия, равномерность покрытия и ROI - Scalability test, реалистические бенчмарки и стресс тестирование
- 31. - В последние годы резко усилился фокус на безопасность - покомпонентный обзор безопасности -- coding practices -- file system permissions -- SEC advisories - тестирование с помощью инструментов проникновения (penetration tools) - bounty hunts силами разработчиков Security Review