new article on QA in SCRUM

[Alexey Krivitsky]

QA in SCRUM Posted: 23 Oct 2007 08:59 AM CDT Кривицкий, 23 октября 2007. На семинарах, которые я провожу, часто от представителей отделов качества раздается один и тот же вопрос: «Что SCRUM думает про QA?». Я написал небольшую статью, в которой попробовал подробно ответить на этот вопрос. Как оказалось QA в SCRUM сталкивается с конфликтом, который в состоянии решить только команда вцелом. Скачать статью.

[Ілля Романенко]

Цікава стаття це "+" :)

[Alexander Lockshyn]

Полезная статья, спасибо! А на английском варианта нету? У меня
американские коллеги как раз этой темой заинтересовались, но почему-то
не нашли в интернете чего-то путного на тему "SCRUM для QA".

On Oct 24, 3:51 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> QA in SCRUM <http://www.agileukraine.org/2007/10/qa-in-scrum.html>

[Yuriy Mann]

Хороший анализ, респект.

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

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

> > состоянии решить только команда вцелом.- Hide quoted text -
>
> - Show quoted text -

[Sergiy Movchan]

:) так в статье собственно тоже нет ничего "путного" - ровно то же, что и везде про скрам.

собственно чего я влезаю - все интересуются не взагали "QA в SCRUM", а более предметно - "регрессионнное тестирование в SCRUM". вот тут начинаются вопросы, ведь с ростом имплементированной функциональности объём работ по регрессионному тестированию растёт. это означает, что встаёт проблема выбора:
1. увеличивать размер спринта, чтобы сохранить project velocity.
2. уменьшать project velocity, чтобы сохранить размер спринта.

для справки

Is ProjectVelocity the same thing as (or a superset of) what is often called a project's "pulse", "heartbeat", or "rhythm" by folks like GradyBooch, SteveMcConnell, JimMcCarthy, and others? One might call this the "mean time between releases" where "releases" includes both formal and informal releases (internal as well as external build/integration milestones). I don't think so. The heartbeat is the periodicity on the calendar (monthly releases, two week (TwoWeeks iterations, annual updates, or whatever). The ProjectVelocity is the amount of features that fit into one beat, estimated in some way that both customers and programmers are comfortable with. -- KentBeck

куда ни кинь всюду клин. и что делать?

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


естественно это относится только к "новым проектам", где действительно происходит нарастание функционала. для устаканившихся "сапортов", где новая функциональность составляет 1-2% от текущей, а основной мотив спринтов - багфиксинг - там всё прекрасно работает.


P.S.: это по мотивам недавнего scrum-workshop'а в Харькове

Regards,
Sergiy.

--
...dali bude...

[Sergiy Movchan]

...и постепенное расширение "слоев" тестирования по мере "созревания" команды...

до регрессионных тестов расширились? если да, то как - поделитесь опытом?

On 10/25/07, Yuriy Mann <yury...@gmail.com> wrote:

Хороший анализ, респект.

--
...dali bude...

[Alexey Krivitsky]

On 10/25/07, Sergiy Movchan <sergiy....@gmail.com> wrote:

:) так в статье собственно тоже нет ничего "путного" - ровно то же, что и везде про скрам.

собственно чего я влезаю - все интересуются не взагали "QA в SCRUM", а более предметно - "регрессионнное тестирование в SCRUM". вот тут начинаются вопросы, ведь с ростом имплементированной функциональности объём работ по регрессионному тестированию растёт. это означает, что встаёт проблема выбора:
1. увеличивать размер спринта, чтобы сохранить project velocity.
2. уменьшать project velocity, чтобы сохранить размер спринта.

vo-pervyh spasibo vsem za otzyvy.
(sorry chto pishu na latinice tut na kompe v internet cafe gde ja sejchas nelzia postavit russkij)

na shiot voprosa kak byt s regressionym testirovaniem:
ja pytalsia na eto otvetit v statje - nuzhno pisat stolko koda skolko mozhno dovesti do sostojania "polnoj gotovnosti".

konechno, po mere uvelichenia objema testirovanija pri toj zhe komande, technologiah i dline sprinta nuzhno budet pisat menshe koda, no eto normalno.

upadiot velocity, stanet jasno, chto est problemy (sdelat problemu vidimoj - eto uze pol reshenia),
nu a kak ejo reshat - dolzhna podumat vsia komanda, vozmozhno chto na etom etape komanda i pojmiot vazhnost avtomatizacii i pro-committ-sia na etot schiot

krw

[Alexey Krivitsky]

On 10/25/07, Alexander Lockshyn <red...@gmail.com> wrote:

Полезная статья, спасибо! А на английском варианта нету? У меня
американские коллеги как раз этой темой заинтересовались, но почему-то
не нашли в интернете чего-то путного на тему "SCRUM для QA".

privet Sasha, spasibo za komment.
na angliskom poka net, nu ja s udovolstviem pridu k vam i rasskazhu v zhivuju, kogda vashi zakazchiki budut v ukraine.

krw

[Serhiy Yevtushenko]

:) так в статье собственно тоже нет ничего "путного" - ровно то же, что и везде про скрам.

собственно чего я влезаю - все интересуются не взагали "QA в SCRUM", а более предметно - "регрессионнное тестирование в SCRUM". вот тут начинаются вопросы, ведь с ростом имплементированной функциональности объём работ по регрессионному тестированию растёт. это означает, что встаёт проблема выбора:
1. увеличивать размер спринта, чтобы сохранить project velocity.
2. уменьшать project velocity, чтобы сохранить размер спринта.

 

Я бы добавил еще один вариант, который тут почему то не рассматривается:

 

Увеличивать производительность регрессионного тестирования.

 

То есть, если у вас резко возростает время регресионного тестирования, то возникает вопрос:

Где находиться узкое место

1) В производительности тестирования -> тогда вопрос возникает - как увеличить объем функциональности, который  можно регрессионно протестировать за итерацию

 

Ответы могут:

- автоматизация тестов

- изменение архитектуры, чтобы нужно было перетестировать только часть компонентов, а не все приложение

- распаралеливании тестов

 

- ... (лучший ответ зависит от текущей ситуации)

 

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

 

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

Любой общий ответ, без знания специфики проекта, будет скорее всего не верен.

 

Сергей

 

[rk]

> 2. уменьшать project velocity, чтобы сохранить размер спринта.

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

> куда ни кинь всюду клин. и что делать?

Алексей правильно заметил: только ваша команда сможет найти подходящий
путь для вас и заказчика. У нас когда-то команда пыталась увеличить
размер итерации, мотивируя тем, что много накладных расходов (в том
числе и тестирование). Заказчик наотрез отказался. Пришлось
собраться всем, обсудить и поменять процессы в проекте, по возможности
автоматизировать, поменять себя и способ работы, чтоб укладываться, а
что еще делать? Ищите решения сообща.

[Yuriy Mann]

>> ...и постепенное расширение "слоев" тестирования по мере "созревания"
>> команды...
>
> до регрессионных тестов расширились? если да, то как - поделитесь опытом?

Буквально только что обсуждали это с нашим QA, в очередной раз.

Идея такая:

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

-- Потенциальная проблема - ручное тестирование GUI (если не удалось
автоматизировать). Тут есть у меня такое предположение (непроверенное
в Agile, т.к. в текущем проекте пока ГУИ очень мало): при тестировании
любой фичи/багфикса внутри спринта должен быть анализ, какие места в
ГУИ это может затронуть. Соответственно, изменение может считаться
протестированным, только когда все затрагиваемое ГУИ также проверено.
При существовании тест-кейсов для ранее написанной функциональности,
это не должно занимать критически много времени.

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

On Oct 25, 1:06 pm, "Sergiy Movchan" <sergiy.movc...@gmail.com> wrote:
> ...и постепенное расширение "слоев" тестирования по мере "созревания"
> команды...
>
> до регрессионных тестов расширились? если да, то как - поделитесь опытом?
>

[Yuriy Mann]

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

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

Я пока решил проблему так.
Скажем, считаем Velocity с 3-го по 5-й спринт. Берем количество
календарных дней между началом 3-го и концом 5-го:
days = start(3) - end(5)

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

nubmer of story points per month = complexity/days*30

Отсюда делаем выводы, сколько user stories мы сделаем, например, через
3 месяца (они, естественно, должны быть оценены в стори поинтах).

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

ВОПРОС, для меня по прежнему туманный: как реалистично оценивать
complexity в условиях, когда команда растет, а то и делится на две
команды?
Есть у кого-нибудь такой опыт?

On Oct 25, 1:04 pm, "Sergiy Movchan" <sergiy.movc...@gmail.com> wrote:
> :) так в статье собственно тоже нет ничего "путного" - ровно то же, что и
> везде про скрам.
>
> собственно чего я влезаю - все интересуются не взагали "QA в SCRUM", а более
> предметно - "регрессионнное тестирование в SCRUM". вот тут начинаются
> вопросы, ведь с ростом имплементированной функциональности объём работ по
> регрессионному тестированию растёт. это означает, что встаёт проблема
> выбора:
> 1. увеличивать размер спринта, чтобы сохранить project velocity.
> 2. уменьшать project velocity, чтобы сохранить размер спринта.
>
> для справки
>

> Is ProjectVelocity <http://c2.com/cgi/wiki?ProjectVelocity> the same thing

> as (or a superset of) what is often called a project's "pulse", "heartbeat",

> or "rhythm" by folks like GradyBooch <http://c2.com/cgi/wiki?GradyBooch>,
> SteveMcConnell <http://c2.com/cgi/wiki?SteveMcConnell>,
> JimMcCarthy<http://c2.com/cgi/wiki?JimMcCarthy>,

> and others? One might call this the "mean time between releases" where
> "releases" includes both formal and informal releases (internal as well as
> external build/integration milestones). I don't think so. The heartbeat is
> the periodicity on the calendar (monthly releases, two week

> (TwoWeeks<http://c2.com/cgi/wiki?TwoWeeks>iterations, annual updates,
> or whatever). The
> ProjectVelocity <http://c2.com/cgi/wiki?ProjectVelocity> is the amount of

> features that fit into one beat, estimated in some way that both customers
> and programmers are comfortable with. --

> KentBeck<http://c2.com/cgi/wiki?KentBeck>

>
> куда ни кинь всюду клин. и что делать?
>
> ведь фиксация размеров спринта по-большому счёт и нужна для того, чтобы
> знать наш velocity, а тут получается, что если фиксируем, то не знаем.
>
> естественно это относится только к "новым проектам", где действительно
> происходит нарастание функционала. для устаканившихся "сапортов", где новая
> функциональность составляет 1-2% от текущей, а основной мотив спринтов -
> багфиксинг - там всё прекрасно работает.
>
> P.S.: это по мотивам недавнего scrum-workshop'а в Харькове
>
> Regards,
> Sergiy.
>

> On 10/25/07, Alexander Lockshyn <redw...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Полезная статья, спасибо! А на английском варианта нету? У меня
> > американские коллеги как раз этой темой заинтересовались, но почему-то
> > не нашли в интернете чего-то путного на тему "SCRUM для QA".
>
> > On Oct 24, 3:51 pm, "Alexey Krivitsky" < alexeykrivit...@gmail.com>
> > wrote:
> > > QA in SCRUM <http://www.agileukraine.org/2007/10/qa-in-scrum.html>
>
> > > Posted: 23 Oct 2007 08:59 AM CDT
> > > Кривицкий, 23 октября 2007.
>
> > > На семинарах, которые я провожу, часто от представителей отделов
> > качества
> > > раздается один и тот же вопрос: «Что SCRUM думает про QA?».
>
> > > Я написал небольшую статью, в которой попробовал подробно ответить на
> > этот
> > > вопрос. Как оказалось QA в SCRUM сталкивается с конфликтом, который в
> > > состоянии решить только команда вцелом.
>
> --

> ...dali bude...- Hide quoted text -

[Alexey Krivitsky]

hi :)

 

On 10/26/07, Yuriy Mann <yury...@gmail.com> wrote:

У нас есть две особенности процесса, которые вообще создают проблемы в
вычислении Velocity стандартным способом:
- Спринты переменного размера

 

eto ploho, osobenno esli vy *vo vremia* sprinta reshaete ego udlinit

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

 

eto OK, esli ty budesh brat sredniy velocity po poslednim 3-5 sprintam, to ne budet vazhno chto vy delali mezhdu sprintami.

no (!) vazhno zaschityvat tolki polnostju sdelannye zadachi

 

chem prosche caclulatii, tem prozrachnee process,

esli zhe vsio slozhno i neochevidno, to nuzhno iskat koren problemy i ego iskoreniat

mne kazhetsia, u vas eto peremennaja dlina sprintov

 

---

krw from Manali

 

[Sergiy Movchan]

On 10/26/07, Serhiy Yevtushenko <syevtu...@gmail.com> wrote:

Я бы добавил еще один вариант, который тут почему то не рассматривается:

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

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

так это и так все знают :-) только смирились с этим (очень редко получается нарасчивать кол-во ресурсов в конце проекта, хотя по-уму так и надо, но по-деньгам никто так делать не хочет)

Любой общий ответ, без знания специфики проекта, будет скорее всего не верен.

ну это очень общее замечание :) так же любой фреймоврк - это общий ответ...

--
...dali bude...

[Sergiy Movchan]

On 10/26/07, rk <kin...@gmail.com> wrote:

> 2. уменьшать project velocity, чтобы сохранить размер спринта.

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

как это в скорость можно включать неоттесченное? это же не "done".

что еще делать? Ищите решения сообща.

ну это-то понятно :)

--
...dali bude...

[Yuriy Mann]

> > У нас есть две особенности процесса, которые вообще создают проблемы в
> > вычислении Velocity стандартным способом:
> > - Спринты переменного размера
>
> eto ploho, osobenno esli vy *vo vremia* sprinta reshaete ego udlinit

Ни в коем случае - во время спринта. Причина переменной длины -
необходимость "подогнать" sprint review/planning meetings под дни,
когда наиболее вероятно будет доступна вся команда и, главным образом,
PO. Люди ходят в отпуска, ездят в командировки. Почему бы не делать на
это поправки. Для меня принципиально важно, чтобы по возможности все
присутствовали при ревью и планировании, а также в фазе углубленных
обсуждений и уточнения требований между спринтами.

Кроме того, когда я говорю о переменной длине, это не значит: первый
спринт неделя, второй - три. Разница обычно в один-два дня, обычная
длина - две недели. Хотя поначалу конечно экспериментировали и с
бОльшими диапазонами, и именно по этому поводу, в общем, все равно не
имели проблем.

> eto OK, esli ty budesh brat sredniy velocity po poslednim 3-5 sprintam, to
> ne budet vazhno chto vy delali mezhdu sprintami.
> no (!) vazhno zaschityvat tolki polnostju sdelannye zadachi

Естественно. Тут все в рамках приличия ;)

> chem prosche caclulatii, tem prozrachnee process,

Тут у меня тоже есть свое мнение: все зависит от зрелости того, кто
пользуется процессом, в этом самом процессе. У меня были знакомые,
которые любили писать код в ФАРе, при этом писали хорошо. Это не
значит, что если бы они изучили соответствующий современный IDE, это
бы ухудшило их результаты. Но на первых порах, естественно, со сложным
IDE им бы было тяжелее.

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

> esli zhe vsio slozhno i neochevidno,

Не думаю, что описанный подход с Velocity такой уж сложный и
неочевидный.

> to nuzhno iskat koren problemy i ego
> iskoreniat
> mne kazhetsia, u vas eto peremennaja dlina sprintov

Проблемы-то нет :) Т.е. мы ее не ощущаем пока. Хотя Sprint
Retrospectives исправно и добросовестно проводим. Просто адаптируем
книжные метрики для себя. Кроме того, как и положено, и сам процесс и
эти вычисления у нас от спринта к спринту меняются и адаптируются -
возможно, когда-то поймем, что проще вернуться к "традиционному
Скраму".

On Oct 26, 7:13 pm, "Alexey Krivitsky" <alexeykrivit...@gmail.com>
wrote:
> hi :)

> krw from Manali<http://picasaweb.google.com/alexeykrivitsky/MandiRoadToManali>

[rk]

> как это в скорость можно включать неоттесченное? это же не "done".

Значит я не правильно понял проблему, прошу прощения.

А включать нетестируемое - можно :)
Мы так и делаем пока в новом проекте. Тут подымалась эта тема - у нас
тоже зарезали бюджет на дополнительных тестеров. Проходим этап
воспитания заказчика - фиксим одни и те же баги почти каждую неделю -
уже начало что-то доходить: дали бюджет на тестера :)

[Sergiy Movchan]

On 10/29/07, rk <kin...@gmail.com> wrote:

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

красиво. "воспитание суровой реальностью" :-)

но в моём понимании "done" - это если заимплеменчено, функционально потесчено и проходят регрессионные тесты. Хотя надо подумать над ухудшением качества ради улучшения ситуации :)

--
...dali bude...

[Serhiy Yevtushenko]

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

 

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

 

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

 

 

 

 

29.10.07, rk <kin...@gmail.com> написал(а):

[Alimenkou Nikolay]

Привет всем!

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

Прежде всего хочу отметить, что у нас довольно непродолжительные
итерации,
а именно 2 недели. При этом объем нового функционала за итерацию
довольно
велик. Для того, чтобы QA успевали за работой разработчиков и не
приходилось
уменьшать velocity мы используем следующие активности:

1) regression testing (не важно автоматизированное или ручное)
2) new features testing
3) test automation
4) integration/demo testing

Теперь я покажу как и какие активности проявляются на разных этапах
итерации.

В первые один-два дня происходит regression testing "релиза" от
предыдущей
итерации. При этом используется весь имеющийся набор
автоматизированных тестов,
а также ручное тестирование неавтоматизированных областей. Кстати, как
раз второй
фактор должен подталкивать QA к полной автоматизации. Практика
показала, что
этого времени хватает для проведения полного regression testing. Если
QA на проекте
не хватает, то данный этап займет больше времени и может быть стоит
уменьшить
velocity для того, чтобы разработчики оказали помощь в автоматизации
регрессионных
тестов.

С третьего по восьмой день new features testing и test automation
вступают в силу и
становятся основными активностями QA. Следует отметить, что первая
активность
не постоянна и проявляется только после закрытия story разработчиками.
Поэтому
для ее проведения может быть выделена не вся команда QA целиком.
Вторая же
активность имеет цель поготовить как можно большую базу
автоматизированных тестов
для regression testing по уже существующему функционалу. Для того,
чтобы данный
этап прошел успешно, надо хорошо распланировать выполнение stories.
Цель - избежать
позднего завершения объемных со стороны QA stories и оставить
небольшой буффер на
решение проблем в конце итерации (вместо поспешного закрытия story в
последний
момент).

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

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

Спасибо за внимание. Может кто-то почерпнет для себя интересные идеи.

[Sergiy Movchan]

On 10/30/07, Alimenkou Nikolay <lumii.su...@gmail.com> wrote:

1) regression testing (не важно автоматизированное или ручное)
2) new features testing
3) test automation
4) integration/demo testing

отличный подход!
то есть конечно именно со скрамом есть небольшие разногласия - в конце итерации N вы не знаете, что из имплеменченного в ней done ( т.к. регрессия идёт в N+1), но если брать в долгосрочной перспективе, то это работаетю

спасибо за инфу!

--
...dali bude...

[Alexey Krivitsky]

всем привет!

читаем жёсткую критику на http://it4business.ru/articles/749/
:)

крв

[irina.pi...@gmail.com]

Ну уж не знаю насколько она жёсткая :) Но пару моментов были хороши :)

Честно говоря, Алексей, меня тоже смутил вывод - "Производить меньше
кода, если не успеваете покрыть его тестами" Согласна, что это
уменьшение производственных остатков, НО ведь бизнес идет вперед
огромными шагами, и если мы будем говорить - Мы не производим больше
кода, потому, что у нас нет тестеров, которые могут проверить
функционал - это bullshit, ни один клиент этого не поймет... Поэтому,
я все же "ЗА" увеличение тима тестетов в тот момент, когда становится
понятно, что скорость девелоперов намного превышает скорость
тестеров.

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

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

[Tim Yevgrashyn]

Ира, почему-то сразу вспомнилось, что говорил Майк на последнем CSM классе.

 

Иногда, некоторые проекты с которыми он работал, приходили к тому, что распараллеливали работу команды(команд) девелоперов и команды QA (включая тестеров). Таким образом команда QA использует результаты работы команды девелоперов для планирования своего sprint backlog и дальше уже сама идет по Scrum в своей реализации. Думаю в этом случае у девелоперов были свои done, критерии. И у QA, думаю, были свои нюансы с тасками. Да и синхронизация таких команд это уже скорее к вопросу Scrum of scrums.

 

Наверняка команды работали по описанному тобой принципу - 4-5 итераций разработка, потом стабилизация-релиз. Мой опыт дает мне четкую уверенность, что для комплексных проектов (особенно не web-ориентированных) никто не делает релиз каждую итерацию. Даже если итерация длинной в целый месяц.

 

Поэтому я привел этот пример как один из возможных способов. Он очень зависит от специфики проекта и команды, да и велик риск отступления от основных IID/Agile/Scrum принципов.

 

[Serhiy Yevtushenko]

По поводу отдельных комманд тестеров- в статье по поводу скрама типа С Jeff Sutherland описывал, как они ввели релиз команду тесторов для того, чтобы можно было выпускать часто релизы. Как я понимаю, они работали дополнительно к команде девелоперев с тестерами, при обильном использовании автоматизированного тестирования. В PatientKeeper достигали скорости 45 релизов (к заказчикам) в год (не все из них были майджор).

 

[Borys Lebeda]

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

Когда-то моя мама была в Чехословакии в 70х годах. Там её, комсомолку, комунистку и красавицу, поразил интересный момент: когда местная работница выполнила дневную норму в 15:00 она спаковала вещи и пошла домой. Нашей делегация, воспитанная в духе соцсоревнования, была просто в шоке от такого кощунства: мол как так, а кто будет бороться за перевыполнение нормы?

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

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

А вот стабилизационных спринтов некоторые заказчики не понимают. Такую вещь тяжелее продать ... Это как получает

[Borys Lebeda]

Не такая уж и жесткая: Я согласен с Панкратовым в том, что Лёша слишком небрежно смешал понятия tester  и QA. Остальные претензии в основном следуют именно из этого ...

--
Borys L.

[irina.pi...@gmail.com]

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

ЗЫ. Это не наезд на тестеров, а просто размышления на тему почему же
скрам ничего не пишет о тестировании.

[Borys Lebeda]

Мне кажется что распаралеллить скрам на две команды можно только при автоматизированном тестировании, в этом случае команда тестировщиков, не тестирует процесс, а занимается улучшением этого процесса.
Т.е. пока девелоперы смотрят  ежедневные отчёты робота тестировщика в течении своего спринта, команда тестирования думает, как покрыть недостающие тесткейсы, улучшить отчётность и увеличить стабильность.
В этому случае незакрытым вопросом остаётся только один важный момент:
предположим девелоперы написали новую функциональность и решили, что её нужно тестировать, пока её тестирование не автоматизировано, ведь команда тестирования возьмётся за автоматизацию только в своём следующем спринте. Получается что внутри команды разработчиков должен быть какой-нибудь ручной тестировщик, который будет тестировать новую функциональность ...
Я даже не могу сформулировать вопросы по этому поводу ... где можно прочитать про это распаралелливание?

[Tim Yevgrashyn]

Ира,

 

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

Во-всяком случае мы избавились от нападок типа "мы все сделали за итерацию, а тестеры не успели протестировать" или "мы тестировали согласно своему плану, а тут сверху свалилась куча незапланированных задач". ИМХО, очевидный прогресс.
 

Я абсолютно согласен, что для наращивания velocity команд (всего проекта), нам нужно инвестировать больше в автоматизацию тестирования. Пока заказчики удовлетворены текущей скоростью, хотя как известно "аппетит приходит во время еды" ;-)

 

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

Та же формализация acceptance criteria (для User stories или чего угодно) - уже семимильный шаг к автоматизации приемочного тестирования. К сожалению шаг зачастую очень тяжелый.
 

[Sergiy Movchan]

On Nov 9, 2007 12:50 PM, irina.pi...@gmail.com
<irina.pi...@gmail.com> wrote:

> ЗЫ. Это не наезд на тестеров, а просто размышления на тему почему же
> скрам ничего не пишет о тестировании.

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

можно конечно не тока юнит, но и аксептанс тесты писать заранее (для
web-проектов это работает и для написания API это работает), но это
только меняет работы местами - но "параллельности" не добавляет.

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

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

--
http://cotoha.info/

[sun]

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

[Alexey Krivitsky]

Ира, привет. см мои комменты внизу

On Nov 8, 4:31 pm, "irina.pivovar...@gmail.com"

<irina.pivovar...@gmail.com> wrote:
> Честно говоря, Алексей, меня тоже смутил вывод - "Производить меньше
> кода, если не успеваете покрыть его тестами" Согласна, что это
> уменьшение производственных остатков, НО ведь бизнес идет вперед
> огромными шагами, и если мы будем говорить - Мы не производим больше
> кода, потому, что у нас нет тестеров, которые могут проверить
> функционал - это bullshit, ни один клиент этого не поймет... Поэтому,
> я все же "ЗА" увеличение тима тестетов в тот момент, когда становится
> понятно, что скорость девелоперов намного превышает скорость
> тестеров.

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

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

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

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

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

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

> Плюс еще очень полезно иметь стабилизационные спринты, когда больше
> внимание уделяются подтягиванию хвостов путем максимального
> сосредоточения на фиксанье багов. Такие спринты можно устраивать раз в
> 4-5 спринтов (при условии, что длина спринта ~=2 неделям)

мне кажется, это суть одна и та же проблема, что и нехватка ресурсов
на тестирование.
и мой ответ тот же: стоит начать писать столько кода, сколько можно
протестировать и потом пофиксать.
печально. но какие у нас есть варианты, если мы не хотим выпускать
дефектный код?

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

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

рассматривайте торможение разработки как механизм высветления проблем,
но ни как конечное решение.

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

к примеру команда завершила итерацию с такими результатами:
история А, размер 2, 3 минорных бага (ОК)
история Б, размер 5, 1 мин, 1 критический баг (не засчитывается)
история В, размер 3, 2 мин бага (ОК)

велосити будет 2+3=5,
история Б, добавить 5 к велосити той итерации, когда будет починена
(логично, что это будет следующая итерация).

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

> А вообще некоторые ребята совершенно правы были говоря о том, что

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

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

это можно называть "здравым смыслом" или как-то иначе. не суть важно

--лёша, гоа