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

Компания, разрабатывающая программное обеспечение

A софтверная компания — это компания, основными продуктами которой являются различные формы программного обеспечения, программные технологии, распространение и разработка программных продуктов. Они составляют индустрию программного обеспечения.

Содержание

• 1 Типы
• 2 Общие роли в компании-разработчике программного обеспечения
• 3 Структура
• 4 Методологии
• 5 Жизненный цикл продукта
• 6 Системы и процедуры
  • 6.1 Бизнес-аналитики
  • 6.2 Программисты
  • 6.3 Тестировщики
  • 6.4 Менеджеры проектов / продуктов
• 7 Аудиты эффективности
• 8 См. также
• 9 Ссылки

Типы

Существует несколько различных типов компаний-разработчиков программного обеспечения:

• Крупные и известные компании, производящие готовые коммерческие продукты (COTS), такие как Microsoft, SAP AG, Oracle Corporation, HP, Adobe Systems и Red Hat
• Мелкие компании, которые производят индивидуальное программное обеспечение для другие компании и предприниматели
• Компании, производящие специализированное коммерческое готовое программное обеспечение, такое как Panorama, Hyperion и Siebel Systems
• Компании, производящие программное обеспечение как услуга SaaS, например Google, Facebook и LinkedIn
• Компании pr производство программных компонентов, таких как Dundas
• Application Service Provider, например Salesforce
• Компании, производящие программное обеспечение на заказ для вертикальных отраслей или определенного географического региона регионы
• Независимые поставщики программного обеспечения (ISV), которые создают, разрабатывают и продают потребительское или корпоративное программное обеспечение, которое используется конечными пользователями

Все они могут быть отнесены к одной или многие из следующего:

• договорный — когда компания-разработчик программного обеспечения получает контракт на поставку определенного программного обеспечения извне (программное обеспечение аутсорсинг )
• разработка продукта — когда она производит готовое к использованию упакованное программное обеспечение; Готовый коммерческий продукт

Общие роли в компании-разработчике программного обеспечения

Организация компании по разработке программного обеспечения — это очень специализированный вид управленческих навыков, при котором опытные люди могут изменить организационные проблема в уникальное преимущество. Например, если подгруппы расположены в разных часовых поясах, может быть обеспечен 24-часовой рабочий день компании, если команды, системы и процедуры хорошо отработаны. Хорошим примером является группа тестирования, работающая в часовом поясе на 8 часов вперед или назад группа разработчиков, которая исправляет программные ошибки, обнаруженные тестировщиками.

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

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

В более крупных компаниях-разработчиках программного обеспечения используется более высокая специализация, и довольно часто :

• Технические писатели, которые пишут всю документацию, такую ​​как руководства пользователя
• Специалисты по выпуску, которые отвечают за сборку всего продукта и контроль версий программного обеспечения
• Пользователь опытные дизайнеры, которые создают архитектуру дизайна на основе бизнес-требований, исследований пользователей и опыта юзабилити
• Графические дизайнеры, которые обычно отвечают за дизайн графического пользовательского интерфейса.
• Инженеры по техническому обслуживанию, которые стоят за двумя, тремя или более линиями поддержки
• Con Султанты несут ответственность за приведение решения в действие, особенно если необходимы некоторые специальные знания. Примеры этого включают: встраивание программного обеспечения бизнес-аналитики, интеграцию с существующими решениями и реализацию бизнес-сценариев в программном обеспечении Business Process Management.

Структура

Менеджер компании-разработчика программного обеспечения обычно называют главой разработки (HOD) и отчитывается перед заинтересованными сторонами. Он или она возглавляет подгруппы напрямую или через менеджеров / лидеров в зависимости от размера организации. Обычно наиболее оперативными являются бригады до 10 человек. В более крупных организациях, как правило, существуют две модели иерархии:

Типичная структура компании-разработчика программного обеспечения

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

Матричная структура

В этой модели есть выделенные менеджеры / лидеры для каждой основной специализации, «арендующие» своих людей для конкретных проектов, возглавляемых менеджерами продуктов / проектов, которые формально или неформально покупают людей и платят за их время. Это приводит к тому, что у каждого частного сотрудника есть два начальника — менеджер по продукту / проекту и специализированный менеджер по ресурсам. С одной стороны, это оптимизирует использование человеческих ресурсов, с другой — может вызвать конфликты по поводу того, какой из менеджеров имеет приоритет в структуре.

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

Методологии

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

• водопадная модель, включая методологии управления проектами, такие как PRINCE2 или PMBoK
• гибкая разработка программного обеспечения, например Extreme Программирование и SCRUM

Существуют также некоторые методологии, которые объединяют оба, например, спиральная модель, Rational Unified Process (RUP) или MSF..

Жизненный цикл продукта

Независимо от используемой методологии, жизненный цикл продукта всегда состоит как минимум из трех этапов:

• Дизайн — включая бизнес-спецификацию и техническую спецификацию
• C — сама разработка
• Тестирование — управление качеством

Каждый этап в идеале занимает 30% общего времени, а оставшиеся 10% остаются в резерве.

UML диаграмма последовательности взаимодействия между этими группами может выглядеть так:

Общее взаимодействие между четырьмя основными группами

На каждом этапе разные group играет ключевую роль, однако каждый тип ролей должен быть задействован на протяжении всего процесса разработки:

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

Системы и процедуры

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

Бизнес-аналитики

• Инструменты моделирования, такие как Sparx Systems Enterprise Architect или IBM Rational Rose

Программисты

• Системы контроля версий и версии программного обеспечения процедуры
• Инструменты анализа кода и стандарты кодирования, проверены вручную или автоматически
• Механизмы развертывания

Тестировщики

• Системы отслеживания ошибок
• Автоматизация тестирования инструменты
• Инструменты производительности и стресс-тестирования

Менеджеры проектов / продуктов

• Управление корпоративными проектами (EPM) системы и процедуры
• Управление портфелем продуктов (PPM)
• Управление изменениями системы и процедуры

Есть также Управление жизненным циклом приложений (ALM), которые объединяют некоторые из этих функций в одном пакете и используются во всех группах. Они поставляются различными поставщиками, такими как Borland, ECM или Compuware.

Аудит эффективности

Хорошо зарекомендовавшие себя компании-разработчики программного обеспечения обычно имеют какой-то способ измерения собственной эффективности. Обычно это делается путем определения набора ключевых показателей эффективности (KPI), таких как

• Среднее количество ошибок, совершаемых разработчиком за единицу времени, или строк исходного кода
• Количество ошибок, обнаруженных тестером за цикл тестирования
• Среднее количество циклов тестирования до Zero Bug Bounce (ZBB)
• Среднее время цикла тестирования
• Расчетное время выполнения задачи по сравнению с реальным временем выполнения задачи (точность планирования)
• Количество корректировок к исходному уровню

Ряд организаций ориентированы на достижение оптимального уровня Модель зрелости возможностей (CMM), где «оптимальный» не обязательно означает наивысший. Существуют также другие системы, такие как SEMA Университета Карнеги-Меллона или отдельные стандарты ISO. Небольшие софтверные компании иногда используют менее формализованные подходы. Каждая организация вырабатывает свой собственный стиль, который находится где-то между тотальной технократией (где все определяется числами) и тотальной анархией (где чисел вообще нет). Каким бы путем ни пошла организация, они рассматривают пирамиду, описывающую стоимость и риск внесения изменений в уже начатые процессы разработки:

пирамида, показывающая риск и временные затраты на изменение

См. Также

• Список крупнейших компаний-разработчиков программного обеспечения

Ссылки

1. ^«Что такое компания-разработчик программного обеспечения сегодня?». RedMonk. 2014. Получено 2 июня 2017 г.
2. ^Независимый поставщик программного обеспечения — что такое ISV? 10duke.com
3. ^Процесс разработки программного обеспечения: принципы, методология и технология Автор: Жан Клод Дерниям, Бадара Али Каба, Дэвид Уастелл стр.166
4. ^Greenlit: разработка телевизионных идей, основанных на фактах и ​​реальности, от концепции до презентации стр.12
5. ^Управление успешными проектами с помощью PRINCE2
6. ^Руководство пользователя к PMBOK Guide
7. ^Планирование экстремального программирования
8. ^Agile Project Управление с помощью Scrum
9. ^Упрощение рационального унифицированного процесса: практическое руководство по RUP
10. ^Microsoft Solutions Framework (MSF): карманное руководство

Лучше всего рассматривать структуру команды в компаниях от 10 человек. В ней, как правило, также есть и второстепенные функции (бухгалтерия, юристы, клининг и т. д.). Их чаще всего отдают на аутсорс. Кроме того, в компании должны быть продавцы, маркетологи и HR, — пишет в статье на tproger.ru Станислав Триерс, эксперт программы для студентов Moove от бизнес-школы «Сколково» и МТС, гендиректор компании Tess Technology

На начальном этапе директор может справляться с частью функций сам (продавать, продвигать услуги, искать и нанимать сотрудников). Такая ситуация характерна, прежде всего, для стартапов, где команда может брать на себя все функции сразу. Так как это недавно запущенный проект, и его цель – окупить инвестиции и получить прибыль в максимально короткие сроки, директор может быть и продавцом, и разработчиком, и курьером. Однако чаще всего там уже есть деление на сферы ответственности. Например, в команде LICA (разрабатывают ИТ-продукт по подбору станков и тканей для текстильной промышленности), которую я курирую на программе Moove, кто-то взял на себя роль CEO, кто-то — CTO, а кто-то занялся продажами и общением с клиентами.

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

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

Этапы создания ПО:

• создание концепции/ТЗ;
• проработка архитектуры программного обеспечения;
• создание технической документации;
• реализация проекта;
• тестирование и приемка;
• внедрение;
• техническая поддержка.

На каждом этапе должен быть свой отдел со своими задачами:

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

Основной состав группы — это специалисты, полностью занятые в создании нового программного продукта:

• менеджеры проекта;
• программисты;
• тестировщики;
• разработчики документации;
• инженерные психологи;
• технологи по разработке ПО.

Вспомогательная группа — это специалисты, не занимающиеся созданием программ, но, тем не менее, играющие важную роль в реализации проекта:

• группа менеджмента и маркетинга продукта;
• специалисты по технической поддержке ПО;
• администраторы бета-тестирования.

По сути в любой команде, занимающейся разработкой продукта, можно выделить следующие роли в команде:

Developer

Занимается производством программных продуктов.

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

по разделению ответственности:

• Backend developer — разработчик программно-аппаратной части комплексного ПО;
• Frontend developer — разработчик клиентской стороны пользовательского интерфейса к программно-аппаратной части.

по платформам:

• Web;
• Mobile;
• Server-Side;
• и так далее.

User Experience Designer (UX)

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

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

Эту роль ошибочно путают, а порою и совмещают с ролью UI Designer. UX и UI Designer отличаются не только предметной областью, но и спецификой мышления. UX Designer больше про аналитику и систематизацию, чем про эргономику и эстетику.

User Interface Designer (UI)

Занимается производством графической составляющей интерфейсов.

Этот человек разрабатывает визуальную часть пользовательского интерфейса. Основными целями работы UI дизайнера являются: интуитивность восприятия, простота, юзабилити и эстетика интерфейса ПО.

Quality Assurance (QA)

Занимается проверкой результата.

QA занимается тестированием всего, как бы странно это ни звучало.

Системный подход специалиста QA позволяет тестировать как программный код, так и продуманность карт пользовательского опыта.

Human Resource (HR)

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

Он обеспечивает прозрачное прохождение всех этапов собеседований при трудоустройстве.

Team Leader

Отвечает за работу группы специалистов.

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

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

Tech Leader

Отвечает за грамотный аргументированный выбор технических решений:

1. Ответственный выбор стороннего ПО для проекта;
2. Рекомендация по выбору конкретного алгоритма или архитектурного решения при производстве ПО;
3. Определение технических особенностей в процессах производства.

Scrum Master

Scrum, Agile, KanBan, гибкие методологии, и прочие теоретические знания, которые крайне бесполезны без практики и опыта.

Scrum Master — это специалист, который помогает команде применять методологию Scrum правильно, объясняет правила методологии, контролирует их выполнение. Сейчас к командам разработки стали прикреплять роль Scram Master. Он отвечает за грамотное применение той или иной гибкой методологии (бывает, что даже той, которая не касается Scrum вообще).

Project Manager (PjM)

Отвечает за старт, ведение и сдачу проектных работ.

Эта роль классического управленца процессами. Работа над проектом начинается с Project Manager’а, ведётся (ставит задачи), контролируется (контроль качества и эффективности) и сдаётся тоже им. В большинстве компаний Project Manager управляет проектным фондом.

Архитектор (Architect)

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

Бизнес Аналитик (Business Analyst)

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

Системный аналитик (System Analyst)

Занимается, в основном, анализом данных и принятием решений о том, как будет работать система, какие методы будут использоваться, а также написанием основных технических документов (техническое задание или ТЗ, спецификации). Важная часть работы — функциональный анализ, в результате которого выделяется перечень функций, которые должна выполнять система, а также определение требований к системе.

Технический писатель (Technical writer)

Специалист, который занимается составлением документации в рамках разработки различных программ. Это люди, которые призваны помогать нам овладевать новыми технологиями, будь то модное устройство или новая программа. От них отчасти зависит успех новинки, ведь именно им нужно убедить потенциального покупателя в пользе этой новинки и объяснить, как ей пользоваться.

Разработка
ПС обычно производится в организации,
в которой одновременно могут вестись
разработки ряда других программных
средств. Для управления всеми этими
программными проектами используется
иерархическая структура управления.
Традиционная структура такого рода
обсуждена в работе [14.1].
Она представлена на рис. 14.1.

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

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

Рис. 14.1. Структура
управления разработкой программных
средств.

По
каждому программному проекту назначается
свой менеджер, который управляет
развитием этого проекта. Ему непосредственно
подчинены лидеры бригад разработчиков.
Менеджер
проекта
осуществляет планирование и составление
расписаний работы этих бригад по
разработке соответствующего ПС (см.
следующий раздел).

Считается
крайне нецелесообразным разработка
большого ПС (программной системы) одной
большой единой бригадой разработчиков.
Для этого имеется ряд серьезных причин.
В частности, в большой бригаде время,
затрачиваемое на общение между ее
членами, может быть больше времени,
затрачиваемого на собственно разработку.
Отрицательное влияние оказывает большая
бригада на строение ПС и на интерфейс
между отдельными его частями. Все это
приводит к снижению надежности ПС.
Поэтому обычно большой проект разбивается
на несколько относительно независимых
подпроектов таким образом, чтобы каждый
подпроект мог быть выполнен отдельной
небольшой бригадой разработчиков
(обычно считается, что в бригаде не
должно быть больше 8-10 членов). При этом
архитектура ПС должна быть такой, чтобы
между программными подсистемами,
разрабатываемыми независимыми бригадами,
был достаточно простой и хорошо
определенный системный интерфейс.

Наиболее
употребительны три подхода к организации
бригад разработчиков [14.1,
14.3, 14.4]:

• обычные
  бригады,

• неформальные
  демократические бригады,

• бригады
  ведущего программиста.

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

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

В
бригаде
ведущего программиста
за разработку порученной программной
подсистемы несет полную ответственность
один человек, называемый ведущим
программистом (chief
programmer)
и являющийся
лидером
бригады:
он сам
конструирует эту подсистему, составляет
и отлаживает необходимые программы,
пишет документацию к подсистеме. Ведущий
программист выбирается из числа опытных
и одаренных программистов. Все остальные
члены такой бригады, в основном, создают
условия для наиболее продуктивной
работы ведущего программиста. Организацию
такой бригады обычно сравнивают с
хирургической бригадой [14.1,
14.4]. Ядро бригады ведущего программиста
составляют три члена бригады: помимо
ведущего программиста в него входит
дублер ведущего программиста и
администратор базы данных разработки.
Дублер
ведущего программиста (backup
programmer)
также
является
квалифицированным и опытным программистом,
способным выполнить любую работу
ведущего программиста, но сам он эту
работу не делает. Главная его обязанность
– быть в курсе всего, что делает ведущий
программист. Он выступает в роли оппонента
ведущего программиста при обсуждении
его идей и предложений, но решения по
всем обсуждаемым вопросам принимает
единолично ведущий программист.
Администратор
базы данных разработки (librarian)
отвечает за сопровождение всей
документации (включая версии программ),
возникающей в процессе разработки
программной подсистемы, и снабжает
членов бригады информацией о текущем
состоянии разработки. Эта работа
выполняется с помощью соответствующей
инструментальной компьютерной поддержки
(см. лекцию 16). В зависимости от объема
и характера порученной работы в бригаду
могут быть включены дополнительные
члены, такие как

• распорядитель
  бригады, выполняющий административные
  функции;

• технический
  редактор, осуществляющий доработку и
  техническое редактирование документов,
  написанных ведущим программистом;

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

• тестовик,
  готовящий подходящий набор тестов для
  отладки разрабатываемой программной
  подсистемы;

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

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

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

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

Существенную
роль в управлении качеством ПС играют
программные (софтверные) стандарты
[14.1,
14.2]. Они фиксируют удачный опыт высоко
квалифицированных специалистов по
разработке ПС для различных их классов
и для разных моделей их качества.
Следование подходящим стандартам может
существенно облегчить достижение
поставленных целей относительно качества
ПС, а также упростить смотр по контролю
качества. Кроме того, стандарты
способствуют формированию взаимопонимания
внутри коллектива разработчиков и
упрощают процесс обучения новых членов
этого коллектива.

Различают
два вида таких стандартов:

• стандарты ПС
  (программного продукта),

• стандарты процесса
  создания и использования ПС.

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

Стандарты
процесса создания и использования ПСопределяют, как должен проводится этот
процесс, т.е. подход к разработке ПС,
структуру жизненного цикла ПС и его
технологические процессы. Хотя эти
стандарты непосредственно не определяют
качества ПС, однако считается, что
качество ПС существенно зависит от
качества процесса его разработки. Эти
стандарты проще контролировать, поэтому
повсеместно используются для управления
качеством ПС.

В
лекции 13 уже отмечалось, что эти стандарты
могут быть как международными или
национальными, так и специально созданными
для организации, в которой ведется
разработка ПС. Разработка последних
стандартов является одной из функций
управления обеспечением качества ПС.

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

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

Соседние файлы в папке Лекции по ООП 15шт

• #
• #
• #
• #
• #
• #
• #

Новый формат отдела разработки ПО

В начале зафиксируем, что имеем сейчас по разработке ПО, какие есть проблемы и к чему необходимо прийти.

Классическая схема отдела такая — народ сидит в офисе (ну или как сейчас на удалёнке) за повременную оплату (8 часов в день) или в бодишопах на почасовке. Добираются на работу в течении 30 — 120 минут. Найм человека происходит через hh или похожие сайты, кандидат проходит hr’а, техсобес где пытаются составить матрицу компетенций. В Москве кандидатов много с любым уровнем знаний, в регионах с этим проблема. Если нет технического вуза поблизости, а бизнес вести хочется, едь в ближайший миллионник и плати местные зарплаты. Последнее для стартапа особенно неприятно. Хорошо если на проекте куда взяли человека существует и ведётся документация по решениям с описанием схем движения данных и т.д., но я такого не встречал ни разу. Бывают обрывки, хаотично ведущиеся записи, протоколы собраний с обоснованиями принятых решений, но систематически ведущаяся документация по разработке — это как двойное затмение луны. Зачем нужна документация со схемами и обоснованиями? Когда архитектор набрасывает макет будущего проекта, то он является носителем уникальных знаний которых нет больше ни у кого. Это серьёзная проблема, если спец заболеет, погибнет, уйдёт — то с ним уйдут и компетенции. Восстановление компетенций без документации и носителя знаний настолько нетривиальная задача, что проще переписать всё заново (и то и другое большие деньги). Ввод в проект нового бойца или старого с другого проекта — это полгода наставничества и отвлечения внимания уже работающих. При этом новая единица тоже ограниченно функциональна по большему счёту. Система постановки задачи может ветвиться, разделяться на подзадачи и сливаться вновь возвращаясь из неожиданных мест. Задача может не проходить через лидов или архитекторов, что добавляет треша и угара в попытках расширить архитектуру или впихнуть непвихуемое.

Проблемы при классической схеме

Человеческие ресурсы ограничены наличным количеством и оперативному изменению практически не поддаются. Отсюда проблема простоев и переработок.

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

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

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

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

Проблема расширения функционала без глубокого анализа такой возможности, а такой анализ возможен только носителем широких компетенций в проекте — архитектором.

Проблема выбывания носителей уникальных знаний по проекту.

Проблема моральной атмосферы в коллективе и личных отношений влияющих на принятие важных решений.

Проблема непрозрачности финансов для заказчика и исполнителей по оплате труда.

Проблема повышения статуса исполнителя и типа выполняемых задач.

Можно ли как-то нивелировать указанные проблемы не меняя парадигму(модель) управления разработкой? Короткий ответ — нет! В дальнейшем такая модель будет тормозить работу, а при увеличении бизнеса и бюрократизации процессов вообще может вынудить к переводу разработки на аутсорс. Хорошо ли это — вынос разработки на аутсорс? — Короткий ответ — да, если это ускорит и облегчит развитие продукта! Может ли быть аутсорс — внутренним для компании? — Легко. А внешним? — тут сложнее, права, безопасность это всё… но возможно! А внутренним и внешним? — Можно и вот как это сделать.

Сервис представляет собой

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

Вертикальная иерархия ролей специалистов в сервисе

• Менеджеры проектов. Роль осуществляет общее управление старшими специалистами, коммуникации между ними, разрешение спорных ситуаций, утверждает решения или обосновывает отказ.
• Лидеры направлений. Роль формирует декомпозиционное дерево подзадач и установку их в пул для нижестоящих ролей данной ветви компетенций. “Графика, анимация, дизайн, эффекты” — решает задачи по разработке общих концепций по всему что касается графики и звука. “Экономика и маркетинг” — маркетинговое исследование про спросу на продукт, таргет группы, инвестирование в проект, аналоги, примерные сметы расходов на этапы. “Разработка” — создание программной версии продукта на всех этапах его жизненного цикла, архитектура, сборки пакетов, платформы. “Тестирование” — ручное и автоматизированное. “Юридическое обеспечение” — защита авторских прав и патентные исследования, проверки чистоты сделок с средствами заказчика, обоснование выплат исполнителям в автоматическом режиме. “Игровой дизайн и сценарии” — относится в основном к игровой индустрии, занимаются механиками, фичами, сценами и монетизацией.
• Старший специалист. Роль получает из пула специализированную но всё ещё общую задачу созданную лидерами. Имеет опыт в решении подобных задач, широкую компетенцию в специализации. Может решить задачу сам или оценив сложность исполнения декомпозировать в пул задач для следующей роли.
• Специалист. Роль получает из пула подготовленную задачу не требующую дальнейшей декомпозиции. Задача точно поставлена, оговорены сроки исполнения, необходимые технологии и критерии успешного результата.

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

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

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

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

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

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

За выполненное ревью с обоснованным указанием об ошибке или отступлении от критериев ревьюиру начисляются балы, а у ревьюируемого они списываются. Споры по результатам ревью решаются автоматически общим голосованием ролей участвовавший в ревью.

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

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

Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков.
Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов.

Набор определённого отрицательного уровня балов ведёт к автоматической блокировке исполнителя по выбранной компетенции.

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

При снижении бала ниже порогового уровня роли происходит переход статуса исполнителя на нижестоящую роль.

Схема движения заказа от заказчика до готового продукта

Заказчик заводит в сервисе проект описывая бизнес задачу (это является первичной информацией). Вносит на свой счёт в сервисе объём средств минимально необходимый для экономико-маркетинговой экспертизы или если она уже есть, то для составления технического задания лидером(разработки, архитектором). Экономическая экспертиза и техническое обоснование включает в себя заключения экспертов о экономической целесообразности данного продукта. Экономическая целесообразность — это исследование аналогов, спроса, доступных ресурсов, практической реализуемости представленное в виде документа с рекомендациями. На следующий этап задача переходит при достаточности средств на счету заказчика в сервисе. Заказчик может предоставить свою экспертизу или ТЗ(техническое задание, архитектуру проекта) на согласование. Если согласование не пройдено, то задача(проект) не может быть взята в разработку. Заказчик может выйти из сервиса на любом шаге или заморозить его в сервисе за отдельную плату. Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсов, к прогрессу выполнения проекта и задач, ведомостям по оплате исполнителям.

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

Ввод исполнителей в сервис возможен после получения матрицы компетенций. Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме. Аккредитованные сервисы предоставляют API с помощью которого можно получить матрицу по соискателю. В зависимости от полученных результатов для аккаунта исполнителя устанавливаются стартовые роли и компетенции для которых будут видны специализированные задачи. Резюмируя, исполнитель регистрируется в сервисе и получает ссылку на сервис тестирования компетенций и проходит их. Результаты тестирования заполняют матрицу компетенций и аккаунту открывается возможность брать задачи, проводить ревью, читать документацию доступную для своей роли.

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

Вопросы требующие отдельной проработки

• Безопасносность.
• Оплата и расчёты с заказчиком и исполнителями.
• Юридические вопросы до договорам с заказчиком и сдельной оплате исполнителям, трансграничные переводы.
• Защита авторского права.

ВикиЧтение

Время — деньги. Создание команды разработчиков программного обеспечения
Салливан Эд

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

Генрик Мкртчян — сооснователь и генеральный директор агентства веб-разработки «Кодеры», рассказал, как под ключ организовать процесс разработки в компании: от постановки задач до релиза продукта.

У нас есть два основных принципа:

1. Команда делает проекты качественно, в срок и с прибылью для компании;
2. Большинство решений, связанных с реализацией проектов, команда принимает самостоятельно, так как основные процессы в компании автоматизированы и прозрачны.

Проект любого масштаба мы разделяем на семь обязательных этапов.

1. Выбираем методологию

От этого зависит состав команды, порядок и даже график работы. Можно выбрать классическую (waterfall) или гибкую (agile). 

При классической методологии:

Команда будет работать строго по ТЗ. Результат, который вы получите в итоге, будет ровно таким, каким вы его запланировали в самом начале.

При гибкой методологии:

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

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

2. Определяем роли и состав команды

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

Классический отдел разработки состоит из следующих сотрудников:

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

• frontend- и backend-разработчик/fullstack-разработчик: первые занимаются визуальной и вычислительной частью проекта, а второй, как универсальный солдат, владеет знаниями разных технологий;

• тестировщик: обеспечивает качество программного продукта с самого начала разработки и до его финальной сдачи;

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

• дизайнер: определяет внешний вид продукта, его интерфейс и юзабилити;

• аналитик: проектирует и оптимизирует процессы, руководит внедрением новых IT-систем и адаптирует систему работы к новым задачам;

• системный администратор: осуществляет бесперебойную работу серверов, настраивает площадки для разработчиков и обеспечивает техническую инфраструктуру.

В некоторых из них нет необходимости, если проект небольшой – например, в архитекторе или аналитике. Главное: берите профессионалов, на которых сможете положиться и которые в состоянии принять решение по специфичным вопросам. 

3. Проводим CustDev, собираем требования с клиентов, пишем техническое задание

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

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

• оценить задачу по бюджету, срокам и объему человеко-часов;
• упростить сдачу-приемку проекта;
• объяснить специалисту, как устроена работа проекта и какую документацию нужно готовить «на выходе».

4. Обеспечиваем команду техническими инструментами

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

Настройте:

• репозиторий для кодовой базы проекта;
• общие инструменты организации процесса разработки, если они нужны – например, таск-трекер (Jira, Redmine, Trello и другие);
• рабочее окружение: сервисы и приложения, от которых будет зависеть ваш продукт (например, Swagger для документации API).

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

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

Читайте также:
Разработка мобильного приложения: как создать прототип и зачем нужен MVP
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
12 шагов к успешному запуску детского приложения

5. Планируем работу команды

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

Составляя график, учитывайте сдвиг сроков задач (например, увеличение сроков из-за исправлений ошибок) и продумайте, как одна задача зависит от другой.

Здесь же декомпозируйте по задачам техническое задание. Разбейте его на небольшие задачи и распределите трудовые ресурсы так, чтобы каждый сотрудник был полностью загружен задачами.