Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству

В преддверии конференции SQA Days 10, которая будет проходить 2-3 декабря в Москве, мы решили (с разрешения докладчиков) опубликовать статьи-анонсы некоторых выступлений. Открывает эту серию публикаций статья Максима Цепкова, технического директора и главного архитектора компании CUSTIS, в которой вновь обсуждается больная для тестировщиков тема совмещения ролей тестировщика и аналитика. Во благо это или во зло?
Agile-методологии появились и развивались в ответ на проблемы традиционных методологий. Чтобы снижать риски, связанные с постановками, в них предусмотрено два механизма. Во-первых, быстрая обратная связь через демонстрации и общение с заказчиком. Во-вторых, стремление к кросс-функциональности внутри команды. Однако в реальности полная кросс-функциональность достигается редко из-за широкого спектра разнородных деятельностей, входящих в процесс создания ПО.

Поэтому на практике обычно сохраняются две роли – аналитика-тестировщика и разработчика. Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей, что изображено на Рис.4. Аналитика-тестировщика традиционно называют аналитиком, хотя столь же успешно его можно было бы назвать и тестировщиком. Более того, если существенная часть аналитической работы находится на стороне заказчика, то последнее точнее отражает его функции.



Читать дальше

От водопада к Agile

Максим, с каких это пор "водопад" и "Agile" стали антагонистами? "Водопад" никак и ничем не противоречит "Agile". По определению . Кстати. "Agile" противопоставлял себя RUP и MSF, которые как раз итерационные, а не водопадные.

В последнее десятилетие водопадная модель сдает свои позиции

Это совсем неверно. Работы по смене АСУ ведутся по водопаду. Практически всегда. А поскольку сейчас отношение "разработка новой" / "замена старой" сместилось в сторону "замена старой", то по сравнению с периодом 90-х можно говорить, что: "В последнее десятилетие водопадная модель применяется чаще, чем в предыдущее десятилетие".

Agile-методологии создают предпосылки для изменения состава ролей в команде разработки, декларируя кросс-функциональность.

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

Вот-вот.
Agile не Agile, а требования все едино проверять надо.
И всегда, что характерно, проверялись.
Какая роль проверяет?
Ну може
))) в чем фишка-то доклада? И новизна подхода?
"В итоге мы получаем структуру, в которой аналитик играет роль «внутреннего заказчика»: общается с внешним заказчиком и формулирует задание на разработку, передает его разработчику и затем принимает от того готовый продукт, проводит тестирование и внедрение, сдавая конечный продукт внешнему заказчику. Преимуществом этой конструкции является гораздо бОльшая ответственность аналитика за качество подготовки и передачи задания для разработки, а также и за конечный результат в целом, поскольку именно ему надо будет защищать его перед заказчиком."

ага.
Вот ровно так в 19-лохматом году мы и работали. Только в силу специфики аналитик именовался комплексником.

))) в чем фишка-то доклада? И новизна подхода?
...
ага.
Вот ровно так в 19-лохматом году мы и работали. Только в силу специфики аналитик именовался комплексником.

Вы не правы Фрося. Как раз разговоры о том как разрабатывали 20-40 лет назад и интересны. Потому как этого сейчас мало кто знает. Ну и пытаются изобретать велосипеды. Как правило, не очень успешно.

"Из видео почерпнуты мысль о том, что ТДД и аналоги зародилось еще в СССР в ГОСТАХ =) Мой мир перевернулся" (с) http://cartmendum.li...119903#t1119903

Вы не правы Фрося. Как раз разговоры о том как разрабатывали 20-40 лет назад и интересны. Потому как этого сейчас мало кто знает. Ну и пытаются изобретать велосипеды. Как правило, не очень успешно.

"Из видео почерпнуты мысль о том, что ТДД и аналоги зародилось еще в СССР в ГОСТАХ =) Мой мир перевернулся" (с) http://cartmendum.li...119903#t1119903

))) а... ну в этом контексте.
SALar!
Так может чаще к ГОСТам отсылать?

Так может чаще к ГОСТам отсылать?

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

Так может чаще к ГОСТам отсылать?

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

так на софтовые стандарты.
зачем же на промышленные?

mea culpa. Не привык я к этому канцеляриту.

ЗЫ: Но вообще читаю 34.602 и то-ли там рудиментов много, то ли еще что. Почему так часто слово "общесоюзный"? Что оно означает в 2011-м году? И таки оттуда явно не стоит проецировать все на любоую разработку ПО.

От водопада к Agile

Максим, с каких это пор "водопад" и "Agile" стали антагонистами? "Водопад" никак и ничем не противоречит "Agile". По определению . Кстати. "Agile" противопоставлял себя RUP и MSF, которые как раз итерационные, а не водопадные.

Сергей, Agile и водопад были антагонистами с самого начала, то есть с зарождения agile. Который изначально родился во многом как протест против формальной заорганизованности творческого труда программистов в RUP, которая тогда была. А Потом - был успешно воспринят, потому что оказалось, что меньшими по сравнению с традиционным процессом усилиями обеспечиваются лучшие результаты. В этом смысла очень забавно читать современные редакции PMBOK, SWEBOK - в них аккуратно оговаривается, что "названия областей совершенно случайно совпали со стадиями водопада, и он вовсе не предполагается" (цитата не дословная, но близкая). При этом в последнюю редакцию PMBOK попробовали внести итерационность в Agile(SCRUM)-смысле - получилось, на мой взгляд. забавно. Потому что нормально скрестить не смогли.

В последнее десятилетие водопадная модель сдает свои позиции

Это совсем неверно. Работы по смене АСУ ведутся по водопаду. Практически всегда. А поскольку сейчас отношение "разработка новой" / "замена старой" сместилось в сторону "замена старой", то по сравнению с периодом 90-х можно говорить, что: "В последнее десятилетие водопадная модель применяется чаще, чем в предыдущее десятилетие".

С моей точки зрения, в мировом тренде - это верно. Это подтверждают всякие статистики, переход на Agile в крупных разработческих компаниях (включая MS), а не только мелких. Что касается смены АСУ, то я лично никогда не участвовал в замене АСУ на производстве, реально управляющей оборудованием, такого опыта у меня нет. Но сейчас таких АСУ - не так много, относительно автоматизации в целом. А если говорить о замене информационных систем, управляющих бизнесом крупного предприятия или банка, то они сейчас далеко не всегда идут по водопаду. Мы, и не только мы делают это по Agile. Тут, например, любопытно, что на Agile перешел ДойчБанк в своей внутренней автоматизации, у них он весьма витиеватый получился...

Agile-методологии создают предпосылки для изменения состава ролей в команде разработки, декларируя кросс-функциональность.

ГОСТ 34.х никак не ограничивает кросфункциональность. Более того, как раз ГОСТ 34.602 и ГОСТ 34.603 молчаливо предполагает совмещение ролей аналитика и тестировщика.
И в то же время Agile ничего не говорит о необходимости кроссфункциональности. Другое дело такие частные случаи как SCRUM или XP. Но там ни аналитика, ни тестировщика быть не должно.

К ГОСТ-34 я лично отношусь очень несерьезно. Я его читал, и, в общем, не могу относиться иначе к стандарту, в котором разработка системы суть побочный процесс разработки документации на систему (это ГОСТ 34.601-90). Вообще они устарели на 20 лет, то есть навсегда. И если говорить о ролях, то когда они разрабатывались тестировщиков как таковых - не было. Agile сейчас в представлен в виде XP-SCRUM-Canban, о кросс-функциональности говорят они. А дальше, в реальных условиях. это кросс-функциональность получается ограниченной тем или иным образом. Например, таким как в докладе.

Вот-вот.
Agile не Agile, а требования все едино проверять надо.
И всегда, что характерно, проверялись.
Какая роль проверяет?

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

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

ага.
Вот ровно так в 19-лохматом году мы и работали. Только в силу специфики аналитик именовался комплексником.

Как известно, новое - хорошо забытое старое, что хорошо показывал Монтень, сопоставляя древних римлян со своими современниками, а я, читая это, добавлял русских авторов 19 века - и тоже не видел особой разницы. Конструкция, которая получается при совмещении, погруженная в scrum/canban - она интересная. А фишка доклада - в визуальных образах. Они - важны, и, на мой взгляд, получилось придумать довольно удачно.

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

Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей...

Ага, так вот откуда идет эта глу, э-м-м, странная концепция ;)

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

PS
Сказка "Жадный Вартан", она же мультфильм "Жадный богач"
http://lib.ru/TALES/...LKOW/vartan.txt
http://www.liveinter.../post152236862/
С овечьей шкурой к скорняку пришел богач-сосед.
«Из этой шкуры шапку сшить ты можешь, или нет?».
«Могу», - сказал в ответ скорняк, на шкуру поглядев.
«А выйдет две?» - спросил толстяк, на корточки присев.
- И две сошьет!
- А три???!!
- И три!!!
- Сошьет четыре???
- Да!
- А пять?
- Ну что ж – сошьет и пять!!!))) Коль в этом есть нужда….)
- А может выкроишь все шесть???
- Могу! Раз надо так.
- А может быть….
- И семь сошью…..
- Ты молодец, скорняк!

Когда заказчик через день за шапками пришел, - семь шапок выложил скорняк на свой рабочий стол!)

- Да разве это мой заказ??? Надумал ты шутить???!!! Ведь ни одну из них нельзя и на нос нацепить!
- Но ты же сам того хотел) Теперь ворчишь, чудак! Больших семь шапок из овцы не выкроишь никак)))




Цена была соблюдена, количество тоже, а вот качество? ;)

Agile slaves как они есть, короче.

Как известно, новое - хорошо забытое старое, что хорошо показывал Монтень, сопоставляя древних римлян со своими современниками, а я, читая это, добавлял русских авторов 19 века - и тоже не видел особой разницы. Конструкция, которая получается при совмещении, погруженная в scrum/canban - она интересная. А фишка доклада - в визуальных образах. Они - важны, и, на мой взгляд, получилось придумать довольно удачно.

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

Так интересней звучит!

1. И что Вы опять на agile и водопад накинулись -- красную тряпку увидели? Статья вообще-то про совмещение ролей :)

2. Критики совмещения ролей -- не стоит демонизировать и Agile тоже, призывая образы "клонов, умеющих всё", потому что в контексте agile речь как правило идёт о кроссфункциональных командах, а не специалистах.
Пруф, пруф, пруф (продолжите сами)

3. Про богача вообще какое-то нелепое обвинение. Я вижу тут две возможных интерпретации, обе, с моей точки зрения равно нелепые :)
3.1. Есть у нас два сотрудника -- аналитик и тестировщик. Давайте сделаем "совмещение ролей", и тогда одного сотрудника можно будет уволить!
3.2. Если человек владеет двумя навыками (например, аналитика и тестировщика), значит он владеет ими обоими плохо.

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

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

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

Новая роль аналитика-тестировщика объединяет обязанности аналитика, тестировщика и внедренца из классического разделения ролей...

Ага, так вот откуда идет эта глу, э-м-м, странная концепция ;)

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

Я вполне польщен приписываемым мне авторством столь почтенной и эффективной концепции.

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

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

P.S. Что касается мультика, то есть гораздо более известный баян про качели при водопадной разработке. А еще миниатюра Райкина "к пуговицам претензий нет?". Так что это - несерьезно.

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

Так интересней звучит!

Благодарю :)

1. И что Вы опять на agile и водопад накинулись -- красную тряпку увидели? Статья вообще-то про совмещение ролей :)
...

Есть люди, которые не любят agile - особенно в плакатно-рекламных проявлениях, которые тоже встречаются. Иногда даже не любят справедливо как пострадавшие - это когда кому-то agile впарили, получился некоторый провал и теперь у участников травма :)

Спасибо за поддержку!

2. Критики совмещения ролей -- не стоит демонизировать и Agile тоже, призывая образы "клонов, умеющих всё", потому что в контексте agile речь как правило идёт о кроссфункциональных командах, а не специалистах.
Пруф, пруф, пруф (продолжите сами)

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