Перейти к содержимому

Фотография

Scrum, Kanban и т.д. для отдела тестирования


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 41

#1 novak

novak

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 26 июля 2009 - 17:55

В свете поднятой темы про Scrum и Kanban возник следующий вопрос: не сталкивался ли кто-нибудь с подобной организацией работы не маленькой команды разработки всё-в-себе, а именно команды тестирования?
Возможно, есть какие-то особенности, противопоказания или же наоборот, бенефиты от применения таких гибких подходов для более специализированной деятельности, нежели разработка в целом.
  • 0

#2 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 26 июля 2009 - 20:02

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

Мне доводилось пару лет поработать в международном проекте под скрамом. Нас было 4-5 тестировщиков, это было достаточно интересно, но у меня осталось впечатление (и по опыту оно все больше подтверждается) - если у вас нет команды или ваши спецы некомпетентны, ничего хорошего не выйдет, будь то скрам, канбан, рап, сиэмэмай или чего другое. Команда и её цель - самое главное. Ещё хочется верить что, к примеру, ребята лабающие медицинский софт и подобное, далеки от гибких технологий.
ПС: А топикстартеру, я смотрю, снобизма не занимать - такой весь в теме, умный и столичный, у меня аж комплексы появились.
  • 0

#3 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 26 июля 2009 - 21:00

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

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

#4 novak

novak

    Новый участник

  • Members
  • Pip
  • 67 сообщений
  • Город:MO

Отправлено 27 июля 2009 - 04:38

ПС: А топикстартеру, я смотрю, снобизма не занимать - такой весь в теме, умный и столичный, у меня аж комплексы появились.

Топикстартер не совсем в теме, совсем не столичный и своих комплексов вагон. Мне просто интересно.
  • 0

#5 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 27 июля 2009 - 09:06

Я "сталкивался", когда в Киеве жил.

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

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

Их софт - приложение на .NET, сайт работает только в IE. Приложение написано три года назад американскими девелоперами.

Проблемы заказчика: внесение изменений в существующую платформу затрудняется с каждой неделей, она "костенеет".

Цели заказчика: создать новую верисю этого приложения, с учетом всего того, что уже надо/хочется поменять.

Его решение: старое приложение постепенно "закрывать", паралельно создавая новое, в рамках существующего проекта.

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

Вот в этом случае было удобно, разумно и эффективно использовать agile. Более того, использование agile было требованием со стороны клиента. Он "содержал" команду, регулярно выплачивая нужные суммы, и постоянно "присутствовал" при разработке. Каждый день все на связи, члены команды кочуют между Нью-Йорком и Киевом.

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

Были двое "ручных" тестировщиков и один "дикий" автоматизатор :)

У ручных поначалу были серьезные проблемы с успеванием. И проблемы с планированием работы. Вообще, это оказалось самым больным местом - планирование работы, оценка времени. Death Match по Agile (кратко, бо презентация, но обсуждение было крупным).

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

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

Тестирование шло так: задача закрыта? Ага. В какой ревизии? Задеплою себе эту ревизию, и проверю задачу.

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

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

Потом сложилось следующее: поскольку новое приложение писали на JAVA, команда девелоперов разделилась на две - .NET и JAVA. Пришлось им как-то разделиться, увы. Впоследствии команда .NET расформировалась, и частично перешла в JAVA. Другие ушли. В какой-то момент на уровне менеджмента было решено увеличить количество работников, и всеобщий agile закончился сам по себе. Тестировщики сели в отдельную комнату, у них появился отдельный менеджер. Все приемы SCRUM проводились в отдельных командах в отдельных комнатах. Пресловутое приложение работает успешно, компания все еще миллиардер.

Так. Что я упустил, о чем не рассказал?
  • 0

Software Testing Glossary - простыми словами о непростых словах.


#6 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 27 июля 2009 - 10:26

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

А канбан, ещё, судя по всему, требует наличие конвейера.
  • 0

#7 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 27 июля 2009 - 11:23

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

А канбан, ещё, судя по всему, требует наличие конвейера.

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

В скраме ведь тоже компонент не становится продуктом за одну операцию, правда?
  • 0

#8 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 27 июля 2009 - 12:47

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

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


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

Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM. "Просто" вводя аналитика, или тестировщика, или ПМ-а руководство убивает производительность. Почему? Ведь ребята то отличные. Ребята то отличные, а руководство просто не поняло почему в SCRUM нельзя выделять отдельные роли. Всего навсего у него не хватило понимания методологии. Чуть-чуть.

Лучшие усилия — недостаточны; лучшие усилия не гарантируют вам качества.
Мы сами все разрушим своими же усердными стараниями.


До чтения Деминга, я тоже полагал, что есть всего 3 фактора успеха. Это люди, люди и люди. Сейчас я так не считаю. Люди - один из факторов успехов. Пожалуй, самый важный.
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#9 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 27 июля 2009 - 13:01

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

Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.

Какие же это профи если менеджер арифметики не знает? Больше похоже на пример классического роговолосого управления.
  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#10 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 27 июля 2009 - 13:37

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

А канбан, ещё, судя по всему, требует наличие конвейера.

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

В скраме ведь тоже компонент не становится продуктом за одну операцию, правда?

Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)
  • 0

#11 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 27 июля 2009 - 13:41

К сожалению, верно и обратное. ... Люди - один из факторов успехов. Пожалуй, самый важный.

Да, естественно, любая палка о двух концах.
  • 0

#12 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 27 июля 2009 - 13:51

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

Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.

Какие же это профи если менеджер арифметики не знает? Больше похоже на пример классического роговолосого управления.

Я сейчас статистику собираю. И как то так получается, что не знают. Причем количество незнающих не просто больше 50%, он похоже больше 95%.
Вот задачи на тот же принцип, но посложнее:
* http://community.liv...563.html#cutid1
* http://community.liv...ew=53136#t53136
  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 


#13 Alfa

Alfa

    Специалист

  • Members
  • PipPipPipPipPip
  • 553 сообщений
  • Город:Moscow

Отправлено 27 июля 2009 - 14:29

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

Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.

Кстати, Scrum позволяет решить указанную проблему при помощи двух практик: velocity и ретроспектива.

Я сейчас статистику собираю. И как то так получается, что не знают. Причем количество незнающих не просто больше 50%, он похоже больше 95%.

Опубликуете посмотрим, пока говорить не о чем.

Вот задачи на тот же принцип, но посложнее:
* http://community.liv...563.html#cutid1
* http://community.liv...ew=53136#t53136

Я так понимаю все это предлагается «за-TOC`ать»? Там вся сложность в отсутствии абстракции, расписать все как у Вас в статье и сложность волшебным образом пропадет. Реальные ситуации не решаются, решаются модели.
  • 0

Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.


#14 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 27 июля 2009 - 15:34

Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)

Ты просто путаешь "конвейерный" процесс со вполне естественным конвейером в любом процессе: придумай-разработай-протестируй-задеплой-обеспечь поддержку.

Не представляю себе разработку одним комком.
  • 0

#15 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 27 июля 2009 - 21:52

Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)

Ты просто путаешь "конвейерный" процесс со вполне естественным конвейером в любом процессе: придумай-разработай-протестируй-задеплой-обеспечь поддержку.

Не представляю себе разработку одним комком.

Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.
  • 0

#16 barancev

barancev

    Администратор

  • Admin
  • PipPipPipPipPipPip
  • 6 871 сообщений
  • ФИО:Алексей Баранцев
  • Город:Россия, Москва


Отправлено 28 июля 2009 - 05:23

Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)

Почему скучно? Конвейерность объемлющего процесса не означает, что отдельные задачи становятся менее разнообразными и интересными, верно?
  • 0
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium

#17 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 28 июля 2009 - 08:38

Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)

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

я об этом в блоге напишу
  • 0

#18 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 28 июля 2009 - 16:53

Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.

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

Конечно, можно веселее сделать, но тогда "Школьный портал" получится.
  • 0

#19 Clauster

Clauster

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 913 сообщений
  • ФИО:Худобородов Валерий
  • Город:Espoo

Отправлено 28 июля 2009 - 18:40

Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.

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

Конечно, можно веселее сделать, но тогда "Школьный портал" получится.

Конвейер подразумевает более мелкие телодвижения. Например ты, как тестер, пишешь кейсы по спеке и прогоняешь, опять пишешь и прогоняешь и т.д.
Вспомни, такие люди приходили не собеседование
  • 0

#20 rlabs

rlabs

    Специалист

  • Members
  • PipPipPipPipPip
  • 660 сообщений
  • Город:Россия, Санкт-Петербург

Отправлено 28 июля 2009 - 22:03

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

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

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

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


Количество пользователей, читающих эту тему: 2

0 пользователей, 2 гостей, 0 анонимных