2007/10/23

QA in SCRUM

На семинарах, которые я провожу, часто от представителей отделов качества раздается один и тот же вопрос: «Что SCRUM думает про QA?».

Я написал небольшую статью, в которой попробовал подробно ответить на этот вопрос. Как оказалось QA в SCRUM сталкивается с конфликтом, который в состоянии решить только команда вцелом.

13 comments:

Slava said...

"В тех книгах нет ни слова про QA"

А знаете почему? :)
Потому что нет никакой принципиальной разницы в организации тестирования (всё-таки про QA на уровне проекта говорить не совсем логично) в привязке к любой методологии. Есть активность, она состоит из анализа требований (как они зафиксированы – не суть, хоть на дощечках покрытых воском), проектирования и выполнения тестов и анализа достигнутых результатов – всё. Какой длинны итерация, как принимается решение о переносе функциональности между итерациями и как планируются сами итерации – вопросы принципиально другого уровня абстракции.

======================

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

Если отбросить общие слова про командное владение состоянием проекта (какая из методологий говорит обратное?), то написано типичное заблуждение свежеобращенных адептов шибких методологий к неокрепшим умам: наличие проектных активностей, таких как проектирование и тестирование и соотв. носителей этих проектных ролей зависит от размера проекта. Не зависит. Активности эти та или иначе есть – просто их в меру знаний и навыков с переменным успехом выполняют те же разработчики.

======================

"Специалисты по QA должны быть неотъемлемой частью команды"
Что постулируется всеми методологиями. Говоря более грамотно: все участники проекта должны быть участниками проектной команды. Это не постулат SCRUMA – это здравый смысл.

======================

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

Эта Америка открыта давно. Итерация не заканчивается коммитом кода, а заканчивается выпуском функционала. Подробнее ниже.

В продолжение этой же мысли:
"Легко воплотить? Нет." - ну если сложно включить тестирование в итерацию, то пардон, что же тогда легко – выкатывать версию клиенту с последним коммитом? Тестирование по определению ЧАСТЬ работ. Не надо просто тестирование оттуда выносить :)

======================

"бюджет разработки обычно имеет довольно узкую маржу".
Маржа - в общерыночной терминологии - разница между ценой и себестоимостью.

Так вот бюджет на проект и состоит из себестоимости – если грубо, то это (время*стоимость ресурсов)*ставку риска – и доходной части. Другими словами – маржа в этом случае и есть доходная часть. Увеличение размера команды происходит за счёт увеличения расходной части и на маржу (фактически норму прибыли) не влияет.

http://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%80%D0%B6%D0%B0

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

======================

"мы не можем увеличивать команду после каждой итерации"

Кто сказал? :) Да сколько угодно, если Клиента это устраивает и он идёт на увеличение расходов. Более того – открою секрет – по принципу постоянно роста проектной команды отлично живут компании-флагманы рынка IT-отрасли, оказывающие сервис по разработке софта. Увеличение команды и соотв.увеличение прибыльности проекта для компании является прямой задачей менеджера проекта в подобного рода компаниях.

======================

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

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

Функциональность это не код закомиченный в CVS – это протестированная и задокументированная функциональность. Уровень тестового покрытия и типы тестов – как основные факторы влияющие на трудозатраты по тестированию – определяются оговоренным и зафиксированным между командой разработки и заказчиком уровнем качества Продукта. Уровень документации также определяется подобной договорённостью. Грубо эти два фактора являются зафиксированным в SLA уровнем сервиса, который оказывается Заказчику. Критерий готовности на расширяется, он достигается. Объём работ по достижению Критерия Готовности не растёт без согласия Команды и Заказчика.

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

======================

"Выходит программисты должны писать меньше кода? Выходит, что так. Или как минимум, программисты не должны писать код, который не будет протестирован внутри этой же итерации."

А просто попробовать увеличить ресурсы на тестирование?

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

В целом создаётся впечатление о недостатке опыта в тестировании и управлении качеством, о которых пишет автор.

======================

Статья, мягко говоря, сырая. Пока автор говорит о SCRUM-е вообще и цитирует идеологов методологии и стандартный набор "продавца методологии" (который, кстати, аналогичен как для продавцов RUP-а, так и для продавцов ХР ;)) – всё идёт хорошо. Когда автор пытается отвечать на вопросы, в которых он разбирается слабо – получается много хуже.

Я не буду задавать глупый вопрос: "Почему адептами новых методологий становятся Разработчики, а не Тестеры или Аналитики?" Я просто констатирую это как факт.


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

Гант пишется с одной буквой "т".
http://ru.wikipedia.org/wiki/%D0%94%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0_%D0%93%D0%B0%D0%BD%D1%82%D0%B0

Pavel Kaplin said...

"Последние данные говорят, что всего лишь около 25% проектных команд [MV1], из тех, которые
пытались, успешно применяют SCRUM.
...
Сможете ли
вы причислить себя к той одной пятой проектных команд, которые смогли..."

Стыдно...

Alexey Krivitsky said...

Pavel, спасибо, что заглянул и оставил коммент.

Я не говорил, что причесляю себя к тем командам, которые смогли выстоять в борьбе с собой и реализовать 100%-скрам. И не вижу в этом ничего стыдного ни для себя, ни для команд, к которых работал. Ибо бы делали лучшее, из того что могли делать в тех условиях, в которых работали, и нам есть чем гордиться.

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

Буду рад, если ты присоединишься к нашему обсуждаению этой темы на Goolge Groups и раскроешь свой коммент, так чтоб я мог адекватно ответить.

Удачи.
Леша.

Alexey Krivitsky said...

я, наверное, не был достаточно точен, когда описал этот вывод в
статье. конечно решение сокращения количества разрабатываемого кода не может быть конечным!

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

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

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

может быть эта теория не сочетается с чьим-то опытом. с радостью выслушаю ваши истории.

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

Pavel Kaplin said...

Алексей, я имел в виду неточность в тексте. 25% - это не одна пятая.

Michael Dubakov said...

В статье вообще неверно приведен пример итерации. НЕТ в итерации фазы QA. Она размазана по все итерации. Фича должна тестироваться сразу же после того как девелопер сказал что она готова. Нет ОТДЕЛЬНОЙ фазы QA.

Alexey Krivitsky said...

michael,

спасибо за коммент. картинка идеального спринта немного утрирована для упрощение материала.

конечно, фичи начинают тестироваться по мере готовности (либо же даже частями).

леша

d3sp3rado said...

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

Pavel Kaplin said...

Потому что это ломает основную цель итеративной разработки - деливери полностью законченных фич.

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

d3sp3rado said...

> Потому что это ломает основную цель итеративной разработки
> - деливери полностью законченных фич.

Неправда, ничего не ломает.


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

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

Судя по всему, у Вас есть тенленция не доверять своей команде и даже в Agile стоять с палкой над командой.

Michael Dubakov said...

>>А что мешает ввести стабилизационную итерацию перед релизом и заняться в ней багфиксингом, наряду с непрерывным процессом тестирования внутри остальных итераций?

На самом деле если есть стабилизационная итерация - это характеризует процесс в команде как "Non-mature". Т.е команда еще не научилась делать итерации так, чтобы в конце можно было делать релиз. Стабилизационные итерации применяют команды, которые только переходят на аджайл.

d3sp3rado said...

Это всё чудесно, но много ли команд с довольно большим продуктом могут заканчивать итерации так, чтобы в продукте перед релизом оставались только minor баги?

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

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

Michael Dubakov said...

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