Изменения

Перейти к: навигация, поиск
Нет описания правки
<big>'''Аналитик и Тестировщик в одном лице – путь к качеству'''</big>
Доклад [[:Категория:Максим Цепков|Максима Цепкова]] на Перед конференцией [http://it-conf.ru/ru/sqadays_main/sqadays_10/sqa10_agenda/ 10-й конференции SQA Days-10] 2-3.12.2011 [http://www.slideshare.net/custisppt/ss-10442641 Презентация на slideshare] Статья опубликована на software-testing.ruбыла опубликована статья по докладу, которая вызвала непростое [http://software-testing.ru/forum/topic/21066/ обсуждение на форуме]. Сам доклад [[Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQADays-2011)]]
= Краткие тезисы = Рассматривается различное содержание ролей в традиционной водопадной и современной Agile методологиях разработки ПО. Для сравнения использованы диаграммы на основе V-модели (http://ru.wikipedia.org/wiki/V-Model): по нисходящей ветви идет конструирование и создание программного артефакта, а по восходящей – его тестирование и внедрение.  Для «водопада» характерно разделение ролей по стадиям жизненного цикла: аналитики выполняют сбор требований и конструирование, затем разработчики реализуют программный продукт и передают его тестировщикам и внедренцам. При этом обсуждают требования одни, а проверяют и внедряют готовый продукт — другие, что представляет проблему из-за искажений и потерь при передаче информации. Agile стремится к кросс-функциональности внутри команды. На практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Аналитик общается с заказчиком и формулирует задание на разработку, и он же проводит тестирование и внедрение. Такой процесс позволяет избежать потери информации и повышает качество продукта, а также обеспечивает большую скорость и гибкость разработки. Схемы на базе V-модели, использованные в докладе, могут применяться для визуализации разделения ролей в реальных проектах разработки и их динамики в ходе проекта. = Статья по докладу = == От водопада к Agile ==
[[Файл:Waterfall model.svg|right|thumb|300px|Рис.1. Водопадная модель, из [http://en.wikipedia.org/wiki/Waterfall_model википедии] ]]
Даже при сохранении ролей в рамках одной команды, границы между ролями могут быть проведены по-другому, нежели в водопадной модели.
==V-модель==
[[Файл:Systems Engineering Process II.svg|right|thumb|300px|Рис.2. V-модель, из [http://en.wikipedia.org/wiki/V-Model_(software_development) википедии] ]]
V-модель интересна тем, что дает достаточно общий взгляд на процесс как таковой, не сосредотачиваясь на его отдельных стадиях. Поэтому она удобна для сравнения различных моделей разработки.
== Классические роли ==
[[Файл:Systems Engineering Process 3 roles.svg|thumb|400px|Рис.3. Классические роли на V-модели]]
Основной недостаток такого процесса состоит в том, что требования с заказчиком обсуждают одни специалисты, а проверяют и внедряют готовый продукт — другие. В ходе передачи информация искажается и теряется, и, как показывает опыт, никакие спецификации не позволяют этого исключить. В результате заказчик зачастую получает продукт, не соответствующий его ожиданиям. Ошибки, допущенные на этапе постановки, занимают наибольшую долю среди причин провалов или задержек выпуска программных продуктов, поэтому их устранение является крайне важным.
== Альтернатива ==
[[Файл:Systems Engineering Process 2 roles.svg|thumb|400px|Рис.4. Объединение ролей на V-модели]]
В компании CUSTIS мы применяем именно такое разделение ролей в команде. У нас нет чистых аналитиков и чистых тестировщиков, эти роли совмещены. При этом внутри команды их обычно несколько, также как и несколько разработчиков, и мы стараемся обеспечить кросс-функциональность в пределах каждой роли. Правда, у этой модели, если рассматривать ее в чистом виде, есть и недостаток – достаточно большая нагрузка на аналитиков, которые обычно представляют собой дефицитный ресурс. Выход мы видим в том, чтобы готовить таких кросс-функциональных аналитиков непосредственно в проектах: в начале проекта менее опытные аналитики начинают преимущественно с задач тестирования, а по мере роста квалификации все больше берут на себя и аналитическую составляющую работы.
== Визуализация ролей на V-модели ==
Схемы на базе V-модели, использованные в статье, могут применяться для визуализации разделения ролей в реальных проектах. С их помощью можно представлять более сложные схемы с большим числом ролей, учитывая, в числе прочего, различную квалификацию сотрудников, а также наблюдать за динамикой изменения обязанностей в ходе проекта и оценивать рост опыта сотрудников. Визуализация предмета рассуждений всегда способствует взаимопониманию, и V-диаграммы с ролями оказались для этого удобным инструментом.
{{replicate-from-custiswiki-to-lib}}
[[Категория:Аналитика]]
[[Категория:Люди]]
[[Категория:ДокладыСтатьи]]

Навигация