Распределение ролей в группе разработчиков программного обеспечения реферат
Обновлено: 03.07.2024
Часто Иногда при обсуждении недостатков приложений пользователи говорят, что разработчики поленились сделать хорошо. Но кто такие разработчики приложений? Давайте попробуем разобраться, какие роли есть в команде разработки.
А точно все они есть?
В принципе, для того, чтобы сделать простейшее приложение, достаточно одного-единственного программиста. Но при возрастании сложности и увеличении сроков разработки кому-то волей-неволей придется исполнять те или иные роли, даже если они явно не выделены (в виде должностей или как-то еще).
Проект
Важный момент разработки программного обеспечения (ПО) заключается в том, что эта самая разработка ведется в рамках проектов. Т.е. очерчиваются сроки, желаемый результат и бюджет проекта (сюда же обычно включаются и людские ресурсы, ведь людей нанимают за деньги и от количества денег зависит, сколько разработчиков и какой квалификации можно нанять). А теперь давайте попробуем рассмотреть, кто же участвует в проектах разработки ПО.
Команда программистов
Собственно, те люди, которые придумывают и реализовывают приложение. Они:
- придумывают архитектуру приложения;
- пишут код;
- консультируют других, как писать код;
- рецензируют код за другими;
- пишут автоматические тесты (по крайней мере, их часть — модульные тесты);
Без написанного и скомпилированного кода приложения не будет. Именно поэтому совсем исключить программистов нельзя. Даже если какие-то приложения создаются в простом визуальном конструкторе, то это тоже своего рода программирование.
Именно программисты зачастую принимают решение, как конкретно будет реализована та или иная функциональность в приложении. И если функциональность реализована плохо, то значительная часть вины может лежать на программистах. А может и нет, поскольку финальное слово в принятии решений принадлежит не им.
Тестировщики
Это те люди, которые проверяют, корректно ли приложение работает. Причем корректно — не значит удобно для пользователя. Тестировщик может написать замечание к удобству использования, но его первоочередная задача — убедиться в том, что приложение работает согласно требованиям и спецификациям.
Тестировать приложения можно как вручную, так и при помощи автотестов (например, программно нажимать кнопки и проверять, какие экраны открываются).
Если в приложении есть явная и незамысловатая ошибка (кнопки в калькуляторе иногда не нажимаются), то часть вины в ней лежит на тестировщиках (они что-то не проверили).
Дизайнер
Это человек, который определяет, как будет выглядеть и как будет вести себя приложение. Взаимное расположение элементов, схема перемещения по экранам, анимации — все это должен продумать дизайнер. Если приложение большое и сложное, то дизайнер может быть и не один. Или, например, один из дизайнеров может только рисовать интерфейс, а другой — глобально продумывать всю концепцию взаимодействия с пользователем.
Заказчик или владелец продукта
Разница в названиях роли проистекает из типа компании. В продуктовой компании (которая разрабатывает свой внутренний продукт) назначается владелец продукта. При заказной разработке выделяется представитель заказчика, который будет взаимодействовать с разработчиками.
Может ли проект разработки обойтись без этого человека? Проект — может, а продукт (приложение) — нет. Кто-то все равно должен понимать, для чего это приложение разрабатывается и как оно должно существовать и развиваться в дальнейшем.
Руководитель проекта
По статистике, только малая часть проектов по разработке ПО завершается в срок с установленным уровнем качества и в рамках первоначального бюджета. Если что-то пошло не так, именно руководитель проекта в конечном счете принимает ответственность за то, чем придется жертвовать: выпустить продукт позднее, исправлять ошибки при помощи обновлений или выбить побольше денег (например, чтобы отдать часть разработки другой команде за отдельные деньги).
В небольших проектах с опытной командой программистов и тестировщиков можно обойтись и без явно выделенного руководителя проекта. Тогда обычно его роль исполняет ведущий программист — тимлид (калька с английского teamlead — лидер команды).
Заинтересованный топ-менеджер
Заключение
Теперь вы знаете, кто есть кто в команде разработки приложений. И если вам придет в голову мысль разработать приложение под Android или iOS, вы будете знать не только о том, что для этого надо, но и о том, каких людей нужно найти.
Сегодня предлагаю разобраться с устройством команды, создающей программное обеспечение. Кто за что отвечает, какие задачи решают различные участники команды?
Стоит сразу уточнить, что мы не рассматриваем специфику команд, придерживающихся разных методологий разработки ПО, и соответственно состоящих из специализированных ролей типа Scrum muster.
Владелец продукта (Product Owner)
Позиционирование и продвижение продукта на рынке, достижение бизнес целей.
Определение концепции продукта;
Создание Go To Market стратегии;
Сегментация и анализ рынка, определение ценности;
Управление списком задач (бэклогом) и пиритизация требований;
Контроль статуса разработки;
Выбор продуктовой стратегии и методов монетизации;
Генерация гипотез по улучшению бизнес показателей;
Оценка достижения бизнес показателей;
Построение процесса / цикла обратной связи от пользователей и оценки качества продуктаю
Управляющий проектом (Project Manager)
Разработка продукта в срок, не превышая выбранный бюджет и с надлежащим качеством.
Управление командой (формирование, мотивация, контроль);
Создание RoadMap (плана разработки);
Оценка стоимости разработки;
Создание и распределение задач, контроль выполнения;
Организация командных активностей;
Проведение интервью и встреч с заказчиком;
Решение организационных вопросов;
Участие в приемке продукта;
Прием решений по сложным вопросам (всем);
Прием решений о публикации новой версии системы (совместно с Техническим лидером);
Бизнес-аналитик (Business Analyst)
Создание и оптимизация бизнес процессов для достижения целей бизнеса
Разработка концепции программного продукта;
Определение ролей пользователей и их потребностей;
Описание предметной области (в т.ч. основных объектов и связей между ними), создание и оптимизация бизнес процессов
Управление требованиями к ПО;
Проведение интервью с заказчиками и конечными пользователями;
Консультация команды разработки;
Участие в приемке продукта и анализ поведения пользователей;
Оценка стоимости разработки (совместно с PM);
Системный аналитик (System Analyst)
Обеспечение эффективной работы системы для успешного выполнения целей пользователей.
Определение ролей пользователей и их потребностей (если этого не делает BA);
Описание предметной области (в т.ч. основных объектов, их атрибутов, связей между ними), бизнес процессов, потоков данных;
Управление требованиями к ПО;
Разработка прототипов и UX (совместно с дизайнером);
Проведение интервью с заказчиками и конечными пользователями;
Формирование стека задач (бэклога) (если этого не делает PM);
Консультация команды разработки;
Аналитик данных (Data Scientist)
Выявление скрытых закономерностей в данных для оптимизации бизнес процессов.
Фиксация бизнес показателей;
Организация сбора данных и мониторинга показателей;
Проверка гипотез по улучшению бизнес показателей;
Системный архитектор (System Architect)
Проектирование архитектуры системы, удовлетворяющей требованиям (как к функциям системы, так и нагрузкам на систему)
Разработка архитектуры системы и выбор стека технологий;
Контроль за соблюдением рекомендаций по архитектуре;
Прием сложных технических решений;
Консультация команды разработки;
Технический лидер (TechLead)
Координация технической команды.
Создание и распределение технических задач, контроль выполнения;
Консультация программистов по узкотехническим вопросам;
Прием решений о публикации новой версии системы (совместно с ПМ);
Публикация системы в сторах;
Оценка стоимости разработки (совместно с PM);
Программист (Programmer)
Разработка программной системы в соответствии с поставленными требованиями.
Разработка программной системы (написание кода, разработка структуры базы данных и т.д.);
Подготовка специалистов для действий в составе команды является одной из современных задач подготовки кадров высшей квалификации. В обычной практике, разработка дипломных и курсовых проектов осуществляется выпускником и студентом единолично, под руководством научного руководителя, при этом не формируются навыки работы в команде, не приобретается опыт работы с инструментальными средствами коллективной разработки проектов, не формируются навыки руководства проектами. На производстве же молодой специалист сразу получает задание в составе группы. Особенно ярко это проявляется при реализации крупных проектов в области создания программного обеспечения. Отсутствие навыков работы в команде сказывается на производительности молодого сотрудника и его адаптации в рабочем процессе. Важным фактором является целостность ведения всего проекта и контроля над его реализацией. Как часто бывает в реальной работе, увольнение одного из разработчиков приводит к потере целых фрагментов проекта, так как при работе в простой студии, всё находится в компьютере программиста.
Другой не менее важный вопрос - наличие методики реализации проекта, очень важно для любого дела. Привить все эти навыки очень важно со студенческой скамьи.
Современные средства разработки программного обеспечения частично позволяют решить данные проблемы.
Вообще, идея управления циклом создания программного обеспечения командой разработчиков не нова. Зачастую участники проекта разделены территориально, но даже находясь рядом, крайне неэффективно контактируют между собой, в то время как для успешного проекта необходимо постоянное согласование действий. Можно использовать телефонные переговоры, почту, и другие современные средства коммуникации, но гораздо эффективнее использовать специальный инструментарий, разработанный для этих нужд. Осознавая эту потребность, компания Microsoft представила новейший пакет инструментальных средств - Microsoft Visual Studio Team System. Это не методика, это просто инструмент. Данный пакет тесно интегрирован с другими программными продуктами этой компании, такими как Microsoft Office, Windows SharePoint и др. Необходимость создания единого хранилища и управляющего инструментария для всей информации касаемо разрабатываемого проекта назревала давно. Иначе, в ситуации какого-либо сбоя у одного из участников проекта неизбежны потери информации, ценной для всей команды. В новом продукте Microsoft роль хранилища и автоматизированного координатора играет Team Foundation Server. Сервер визуализирует всю информацию посредством интерактивного web-сайта использующего Windows SharePoint Server.
Итак, при использовании Visual Studio Team System решаются следующие задачи:
Повышение предсказуемости успеха проекта.
Рост производительности труда команды разработчиков за счет понижения сложности процессов проектирования и реализации современных сервисно-ориентированных решений.
Обеспечение сотрудничества команды путем интеграции коммуникационных и прочих средств, используемых ее членами.
Расширение возможностей командной работы за счет обеспечения удаленным пользователям доступа к надежному, защищенному и масштабируемому окружению.
Предоставление команде разработчиков гибкого и расширяемого коммуникационного решения с настраиваемыми сервисами.
Ключевыми членами проектной команды являются: руководитель проекта, архитектор, разработчик и тестировщик. Каждую из этих ролей может исполнять как один человек, так и несколько. Второстепенные участники проекта, являющиеся профессионалами в области информационных технологии, также по достоинству оценят использование Team System, так как эта система облегчит им взаимодействие с остальными членами команды.
Научному руководителю курсовых и дипломных проектов, выполняемых в составе команды, необходимо также решать следующие задачи:
Методы подбора групп.
Сроки введения группового проектирования, первоначальная подготовка.
Распределение ролей, ротация ролей.
Другой не менее важный вопрос - наличие методики реализации проекта, что очень важно для любого дела..
В первой части данного проекта, авторы излагают основные принципы методологии Microsoft, при реализации программных проектов. При формировании методики реализации курсовых и дипломных проектов авторы опираются на опыт компании Microsoft
Во второй части рассматривается применение Visual Studio Team System для реализации проектов в составе команды.
Авторы данного пособия, постараются изложить свой небольшой опыт реализации курсовых и дипломных работ в составе команды.
Основные постулаты и принципы работы в команде
Сегодня основным ресурсом эффективного ведения хозяйственной деятельности предприятия является корпус специалистов. Резко возрастает роль личностей. От их квалификации, деловой активности, умения взаимодействовать друг с другом и достигать результата зависят перспективы развития предприятия. Одним из наиболее востребованных качеств, наряду с профессионализмом, является способность работать в команде. Ключевым фактором эффективной работы команды является способность каждого ее члена "работать на результат". Однако на практике иногда случается так, что психологический аспект смещается с результатов деятельности на межличностную конкуренцию, проявляющуюся в скрытой или явной конфронтации.
В вопросе формирования команды важным элементом является "численность". Пять - подходящее количество людей, двенадцать - слишком много. " " является магическим числом и идеальной численностью команды. В случае если в Вашем коллективе 12 и более человек, рано или поздно естественным образом он поделится на "неформальные команды по интересам", представляя в общем виде разрозненную и неконсолидированную психологически массу. Этот процесс может быть предупрежден руководителем: нужно осознанно объединить сотрудников в команды вокруг определенных профессиональных целей. Когда одна цель будет достигнута, важно вновь и вновь объединять сотрудников в команды, создавая и поддерживая, таким образом, командный дух в коллективе и поддерживая, повышая мотивационный уровень сотрудников.
Состав команды является самой важной предпосылкой высокой производительности компании. При подборе персонала нужно учитывать три фактора.
Фактор первый: профессиональная квалификация. Профессиональные требования зависят от конкретных задач той или иной команды, поэтому до начала формирования команды следует составить список требований, связанных с конкретной задачей.
Фактор второй: личностные характеристики.
Фактор третий: способность работать в команде! Это может быть как предпосылкой, так и результатом развития команды. Без базовой способности сотрудничества с другими членами команды, ориентируясь на результат, ничего не получится. Следовательно, при формировании команды требование к способности работать в ней выдвигается в первую очередь. Необходимо определить хочет ли и может ли кандидат работать в команде, и в какой степени.
Обзор существующих инструментальных средств для командной работы
Наряду с VSTS существуют другие решения для организации командной работы, одним из них является IBM Rational Suite.
Rational Suite - интегрированный набор продуктов, предназначенный для поддержки командной работы над проектом на каждой фазе жизненного цикла разработки информационной системы. Продукт выпущен компанией Rational Software.
IBM Rational Suite является уникальным семейством продуктов, которое позволяет поднять на новый уровень разработку программного обеспечения. Пользователи Rational Suite получают следующие преимущества:
Объединение - Rational Suite объединяет усилия аналитиков, разработчиков и тестировщиков, снимая барьеры, которые обычно существуют между группами сотрудников, работающих над одним проектом.
Оптимизацию - Rational Suite оптимизирует работу сотрудников, предоставляя нужный набор инструментальных средств для выполнения специфических задач каждого члена команды.
Упрощение - Rational Suite упрощает установку, поддержку и совместное использование продуктов, входящих в Rational Suite, снижается их общая стоимость (общая стоимость комплекта значительно ниже стоимости приобретения аналогичных отдельных продуктов).
IBM Rational Suite обеспечивает ускорение разработки на основе функций визуального моделирования, генерации кода и реинжиниринга, обеспечивает поиск и устранение ошибок времени исполнения, проблем с недостатком памяти и производительности.
Программные продукты, составляющие Rational Suite:
IBM Rational Functional Tester for Java and Web - решение, обеспечивающее расширенное автоматизированное функциональное и регрессионное тестирование Java- и Web -приложений из сред разработки Eclipse IDE, IBM WSAD.
IBM Rational Team Unifying Platform - платформа, предназначенная для обеспечения разработчиков инфраструктурными инструментами, процессами и интеграцией - элементами, необходимыми для более эффективной организации совместной работы. Данное решение объединяет коллектив разработчиков, предоставляя общий доступ к ресурсами разработки, коммуникационным оповещениям и процессам, что необходимо для отслеживания динамики и текущего состояния проекта.
IBM Rational Developer Network - дополнительный ресурс, доступный для всех клиентов Rational, - сеть Rational Developer Network (RDN) , откуда в любой момент времени можно получить учебную информацию, сведения о решениях и советы экспертов.
IBM Rational Suite for Technical Developers - представляет собой полное решение поддержки жизненного цикла ПО, предназначенное для написания очень сложного кода для некоторых наиболее проблемных продуктов и систем, таких, как встроенные приложения и приложения реального времени.
IBM Rational Suite Development Studio for UNIX - представляет собой решение по поддержке всего жизненного цикла ПО, предназначенное для аналитиков, разработчиков и тестировщиков, что позволяет объединить многофункциональные группы разработчиков и поддерживать программные проекты для UNIX, начиная от формулирования требований и до выпуска финального ПО.
Для создания ИС могут применяться два подхода: создание своими силами или заказ стороннему изготовителю. Аргументом в пользу первого подхода является то, что свои специалисты лучше знают условия и традиции конкретного предприятия, они всегда рядом и могут непосредственно контактировать с любым работником, за их работу не нужно платить тех больших денег, которые требуют за готовую систему сторонние изготовители, и т. д. Последний аргумент является исключительно весомым, поскольку оплата труда на предприятии обычно уступает оплате труда в специализированных фирмах.
Однако полная стоимость владения ИС во втором варианте может оказаться ниже.
Информационная система как изделие в разных вариантах тоже имеет существенные отличия.
Следует отметить, что в настоящее время преобладающим является создание ИС путем адаптации типовых программных продуктов, выпускаемых профессиональными изготовителями.
Анализ вариантов создания и развития ИС
Функции, выполняемые разработчиками в проекте подразделяются на организационные и производственные. Первые создают условия для выполнения проектных заданий, вторые непосредственно связаны с этими заданиями.
Согласно концепции Microsoft Solution Framework (MSF) выделяются следующие группы функций – так называемые области функциональной специализации (functional area). Определено шесть ролевых кластеров, которые соответствующим образом структурируют проектные функции разработчиков (рис. 2.1).
• Управление продуктом(product management). Ключевая цель кластера – обеспечивать удовлетворение интересов заказчика. Для ее достижения кластер должен содержать следующие области компетенции:
– представление интересов заказчика;
• Управление программой(program management). Задача – обеспечить реализацию решения в рамках ограничений проекта, что может рассматриваться как удовлетворение требований к бюджету проекта и к его результату. Области компетенции кластера:
– выработка архитектуры решения;
– контроль производственного процесса;
• Разработка(development). Первостепенной задачей кластера является построение решения в соответствии со спецификацией. Области компетенции кластера:
– проектирование и осуществление реализации;
• Тестирование(test). Задача кластера – одобрение выпуска продукта только после того, как все дефекты выявлены и устранены. Области компетенции кластера:
– отчетность о тестах;
• Удовлетворение потребителя(user experience). Цель кластера – повышение эффективности использования продукта. Области компетенции кластера:
– общедоступность (возможности работы для людей с недостатками зрения, слуха и др.);
– интернационализация (эксплуатация в иноязычных средах);
– обеспечение технической поддержки;
– удобство эксплуатации (эргономика);
• Управление выпуском(release management). Задача кластера – беспрепятственное внедрение и сопровождение продукта. Области компетенции кластера:
– управление выпуском готового продукта (commercial release management).
Центр объектно-ориентированной технологии компании IBM предлагает свою ролевую структуру проекта. Эта структура включает достаточно полный перечень типичных ролей, согласованный со многими реальными дисциплинами развития программных проектов. В то же время она представляет роли разработчиков в организационном контексте, т. е. рассматривает не только разработчиков, но и тех, кто, не участвуя в проекте в качестве исполнителей, оказывает влияние на постановку задач проекта, на выделение ресурсов и обеспечение осуществимости развития работ. В представленном перечне характеристика каждой роли, по сути, задает круг родственных организационных и производственных функций, которые объединяются с целью определить роль.
• Заказчик(Customer) – реально существующий (в организации, которой подчинена команда, или вне ее) инициатор разработки или кто-либо иной, уполномоченный принимать результаты (как текущие, так и окончательные) разработки.
• Планировщик ресурсов(Planner) – выдвигает и координирует требования к проектам в организации, осуществляющей данную разработку, а также развивает и направляет план выполнения проекта с точки зрения организации.
• Менеджер проекта(Project Manager) – отвечает за развитие проекта в целом, гарантирует, что распределение заданий и ресурсов позволяет выполнить проект, что работы и предъявление результатов идут по графику, что результаты соответствуют требованиям. В рамках этих функций менеджер проекта взаимодействует с заказчиком и планировщиком ресурсов.
• Руководитель команды(Team Leader) – производит техническое руководство командой в процессе выполнения проекта. Для больших проектов возможно привлечение нескольких руководителей подкоманд, отвечающих за решение частных задач.
• Архитектор(Architect) – отвечает за проектирование архитектуры системы, согласовывает развитие работ, связанных с проектом.
• Проектировщик подсистемы(Designer) – отвечает за проектирование подсистемы или категории классов, определяет реализацию и интерфейсы с другими подсистемами.
• Эксперт предметной области(Domain Expert) – отвечает за изучение сферы приложения, поддерживает направленность проекта на решение задач данной области.
• Разработчик(Developer) – реализует проектируемые компоненты, владеет и создает специфичные классы и методы, осуществляет кодирование и автономное тестирование, строит продукт. Это широкое понятие, которое может подразделяться на специальные роли (например, разработчик классов). В зависимости от сложности проекта команда может включать различное число разработчиков.
• Разработчик информационной поддержки(Information Developer) – создает документацию, сопровождающую продукт, когда выпускается версия.
Включаемые в нее инсталляционные материалы, равно как ссылочные и учебные, а также материалы помощи предоставляются на бумажных и машинных носителях. Для сложных проектов возможно распределение этих задач между несколькими разработчиками информационной поддержки.
• Специалист по пользовательскому интерфейсу(Human Factors Engineer) – отвечает за удобство применения системы. Работает с заказчиком, чтобы удостовериться, что пользовательский интерфейс удовлетворяет требованиям.
• Тестировщик(Tester) – проверяет функциональность, качество и эффективность продукта. Строит и исполняет тесты для каждой фазы развития проекта.
• Библиотекарь(Librarian) – отвечает за создание и ведение общей библиотеки проекта, которая содержит все проектные рабочие продукты, а также за соответствие рабочих продуктов стандартам.
Первые две позиции в приведенном перечне отведены заказчику и планировщику ресурсов, которые имеют лишь внешнее отношение к разработке проекта, – они не являются членами команды. Заказчик – это лицо, заинтересованное в получении результатов. Планировщик решает задачи распределения финансовых, трудовых и технических ресурсов для разных проектов внутри фирмы. При правильной организации разработки с этими действующими лицами приходится сталкиваться лишь менеджеру проекта.
В заключение приведем перечень ключевых ролей, характеризующих наиболее типичные ситуации для программных проектов:
Читайте также: