Scrum, Kanban и т.д. для отдела тестирования
#1
Отправлено 26 июля 2009 - 17:55
Возможно, есть какие-то особенности, противопоказания или же наоборот, бенефиты от применения таких гибких подходов для более специализированной деятельности, нежели разработка в целом.
#2
Отправлено 26 июля 2009 - 20:02
Мне доводилось пару лет поработать в международном проекте под скрамом. Нас было 4-5 тестировщиков, это было достаточно интересно, но у меня осталось впечатление (и по опыту оно все больше подтверждается) - если у вас нет команды или ваши спецы некомпетентны, ничего хорошего не выйдет, будь то скрам, канбан, рап, сиэмэмай или чего другое. Команда и её цель - самое главное. Ещё хочется верить что, к примеру, ребята лабающие медицинский софт и подобное, далеки от гибких технологий.В свете поднятой темы про Scrum и Kanban возник следующий вопрос: не сталкивался ли кто-нибудь с подобной организацией работы не маленькой команды разработки всё-в-себе, а именно команды тестирования?
Возможно, есть какие-то особенности, противопоказания или же наоборот, бенефиты от применения таких гибких подходов для более специализированной деятельности, нежели разработка в целом.
ПС: А топикстартеру, я смотрю, снобизма не занимать - такой весь в теме, умный и столичный, у меня аж комплексы появились.
#3
Отправлено 26 июля 2009 - 21:00
Скрам, канбан и прочие человеко-ориентированные методологии, думаю, требуют наличия реальной многофункциональной команды, а не сферических в вакууме тестировщиков, оторванных от разработки.не сталкивался ли кто-нибудь с подобной организацией работы не маленькой команды разработки всё-в-себе, а именно команды тестирования?
#4
Отправлено 27 июля 2009 - 04:38
Топикстартер не совсем в теме, совсем не столичный и своих комплексов вагон. Мне просто интересно.ПС: А топикстартеру, я смотрю, снобизма не занимать - такой весь в теме, умный и столичный, у меня аж комплексы появились.
#5
Отправлено 27 июля 2009 - 09:06
Когда заходит речь о подобных методологиях, надо учитывать контекст.
Контекст у меня такой: есть компания, которая посредничает на рынке неликвидных ценных бумаг США (это все акции, варранты, вексели и прочее, которые по разным причинам не могут продаваться на обычных биржах).
Их софт - приложение на .NET, сайт работает только в IE. Приложение написано три года назад американскими девелоперами.
Проблемы заказчика: внесение изменений в существующую платформу затрудняется с каждой неделей, она "костенеет".
Цели заказчика: создать новую верисю этого приложения, с учетом всего того, что уже надо/хочется поменять.
Его решение: старое приложение постепенно "закрывать", паралельно создавая новое, в рамках существующего проекта.
Разработкой требований занимались аналитики с обеих сторон. Требования фиксировались в виде юз-кейсов и использованием схематичных изображений элементов страницы - в вики. Требования были достаточно подробными и грамотными. Траблы случались только оттого, что требования иногда меняли/уточняли прямо в вики, и я не успевал, например, отслеживать эти изменения (писем много).
Вот в этом случае было удобно, разумно и эффективно использовать agile. Более того, использование agile было требованием со стороны клиента. Он "содержал" команду, регулярно выплачивая нужные суммы, и постоянно "присутствовал" при разработке. Каждый день все на связи, члены команды кочуют между Нью-Йорком и Киевом.
Поначалу был грамотный коучер, который следил за следованием духу скрама, потом он ушел.
Были двое "ручных" тестировщиков и один
У ручных поначалу были серьезные проблемы с успеванием. И проблемы с планированием работы. Вообще, это оказалось самым больным местом - планирование работы, оценка времени. Death Match по Agile (кратко, бо презентация, но обсуждение было крупным).
Программисты загибались, потому что им предлагали в итерацию включить слишком много задач. Много в том плане, что одно только их обсуждение могло занять много, много часов. Пытались использовать карты (покер), закрываться в отдельных комнатах и не выпускать никого, пока все вопросы не будут решены, оценивать самостоятельно, а потом сравнивать, и все равно было сложно сказать, сколько времени нужно, и уложатся ли все задачи со стороны бизнеса в следующую итерацию. И поскольку время поджимало, переходили к кодированию. Иногда не укладывались. А бизнес жал. На словах все выглядит просто - принимаем в итерацию только то, что успеем сделать. В действительности постоянно приходится идти на компромиссы со стороны девелоперов.
У тестировщиков было счастье в том, что девелоперы смогли сделать сборку билдов очень легкой. Я мог сам сбилдить определенный билд с нужным мне номером ревизии, и в нем копаться сколько и как угодно, никого не задевая, всего лишь модифицируя бат-файлы для запуска того, что и как нужно. И это было очень круто.
Тестирование шло так: задача закрыта? Ага. В какой ревизии? Задеплою себе эту ревизию, и проверю задачу.
Это работало отлично в плане "проверки фич по отдельности", но были сложности с регрешн-тестированием, потому что задачи были разрознены, и был риск что-то упустить. Но потом, когда знакомство с проектом было уже на уровне "ну ты, проект, а ну, иди сюда, нах!", регрешн проходил очень быстро и достаточно эффективно. Уточню - это был не "полный" регрешн, полный пытался создать тестировщик-автоматизатор. Мы постоянно проверяли основной функционал, без сильных ответвлений.
С оценкой времени у нас тоже были сложности, но эти сложности в какой-то момент оказались решаемы, и перед началом итерации у ПМ были оценки и со стороны девелоперов, и со стороны тестировщиков. Даже родился новый метод оценок. Не дай бог его в реальности применять, но это как раз презентация возможностей человеческой адаптации. Как вы поставите задачу, так ее и выполнят.
Потом сложилось следующее: поскольку новое приложение писали на JAVA, команда девелоперов разделилась на две - .NET и JAVA. Пришлось им как-то разделиться, увы. Впоследствии команда .NET расформировалась, и частично перешла в JAVA. Другие ушли. В какой-то момент на уровне менеджмента было решено увеличить количество работников, и всеобщий agile закончился сам по себе. Тестировщики сели в отдельную комнату, у них появился отдельный менеджер. Все приемы SCRUM проводились в отдельных командах в отдельных комнатах. Пресловутое приложение работает успешно, компания все еще миллиардер.
Так. Что я упустил, о чем не рассказал?
Software Testing Glossary - простыми словами о непростых словах.
#7
Отправлено 27 июля 2009 - 11:23
Ну это как бы любой процесс подразумевает. ритм-то должен быть у разработки, и состояния определенные.А канбан, ещё, судя по всему, требует наличие конвейера.Скрам, канбан и прочие человеко-ориентированные методологии, думаю, требуют наличия реальной многофункциональной команды, а не сферических в вакууме тестировщиков, оторванных от разработки.
В скраме ведь тоже компонент не становится продуктом за одну операцию, правда?
#8
Отправлено 27 июля 2009 - 12:47
Мне доводилось пару лет поработать в международном проекте под скрамом. Нас было 4-5 тестировщиков, это было достаточно интересно, но у меня осталось впечатление (и по опыту оно все больше подтверждается) - если у вас нет команды или ваши спецы некомпетентны, ничего хорошего не выйдет, будь то скрам, канбан, рап, сиэмэмай или чего другое. Команда и её цель - самое главное.В свете поднятой темы про Scrum и Kanban возник следующий вопрос: не сталкивался ли кто-нибудь с подобной организацией работы не маленькой команды разработки всё-в-себе, а именно команды тестирования?
Возможно, есть какие-то особенности, противопоказания или же наоборот, бенефиты от применения таких гибких подходов для более специализированной деятельности, нежели разработка в целом.
К сожалению, верно и обратное. Отличная команда отличных профи легко может завалить проект, если не пользуется глубинными знаниями.
Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM. "Просто" вводя аналитика, или тестировщика, или ПМ-а руководство убивает производительность. Почему? Ведь ребята то отличные. Ребята то отличные, а руководство просто не поняло почему в SCRUM нельзя выделять отдельные роли. Всего навсего у него не хватило понимания методологии. Чуть-чуть.
Лучшие усилия — недостаточны; лучшие усилия не гарантируют вам качества.
Мы сами все разрушим своими же усердными стараниями.
До чтения Деминга, я тоже полагал, что есть всего 3 фактора успеха. Это люди, люди и люди. Сейчас я так не считаю. Люди - один из факторов успехов. Пожалуй, самый важный.
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#9
Отправлено 27 июля 2009 - 13:01
Какие же это профи если менеджер арифметики не знает? Больше похоже на пример классического роговолосого управления.К сожалению, верно и обратное. Отличная команда отличных профи легко может завалить проект, если не пользуется глубинными знаниями.
Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#10
Отправлено 27 июля 2009 - 13:37
Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)Ну это как бы любой процесс подразумевает. ритм-то должен быть у разработки, и состояния определенные.А канбан, ещё, судя по всему, требует наличие конвейера.Скрам, канбан и прочие человеко-ориентированные методологии, думаю, требуют наличия реальной многофункциональной команды, а не сферических в вакууме тестировщиков, оторванных от разработки.
В скраме ведь тоже компонент не становится продуктом за одну операцию, правда?
#12
Отправлено 27 июля 2009 - 13:51
Я сейчас статистику собираю. И как то так получается, что не знают. Причем количество незнающих не просто больше 50%, он похоже больше 95%.Какие же это профи если менеджер арифметики не знает? Больше похоже на пример классического роговолосого управления.К сожалению, верно и обратное. Отличная команда отличных профи легко может завалить проект, если не пользуется глубинными знаниями.
Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.
Вот задачи на тот же принцип, но посложнее:
* http://community.liv...563.html#cutid1
* http://community.liv...ew=53136#t53136
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#13
Отправлено 27 июля 2009 - 14:29
Кстати, Scrum позволяет решить указанную проблему при помощи двух практик: velocity и ретроспектива.К сожалению, верно и обратное. Отличная команда отличных профи легко может завалить проект, если не пользуется глубинными знаниями.
Просто к слову. В моей последней статье http://blog.shumoos.com/archives/186 показывается, как можно легко убить производительность команды, если недооценить значение кроссфункциональности в SCRUM.
Опубликуете посмотрим, пока говорить не о чем.Я сейчас статистику собираю. И как то так получается, что не знают. Причем количество незнающих не просто больше 50%, он похоже больше 95%.
Я так понимаю все это предлагается «за-TOC`ать»? Там вся сложность в отсутствии абстракции, расписать все как у Вас в статье и сложность волшебным образом пропадет. Реальные ситуации не решаются, решаются модели.Вот задачи на тот же принцип, но посложнее:
* http://community.liv...563.html#cutid1
* http://community.liv...ew=53136#t53136
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#14
Отправлено 27 июля 2009 - 15:34
Ты просто путаешь "конвейерный" процесс со вполне естественным конвейером в любом процессе: придумай-разработай-протестируй-задеплой-обеспечь поддержку.Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)
Не представляю себе разработку одним комком.
#15
Отправлено 27 июля 2009 - 21:52
Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.Ты просто путаешь "конвейерный" процесс со вполне естественным конвейером в любом процессе: придумай-разработай-протестируй-задеплой-обеспечь поддержку.Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)
Не представляю себе разработку одним комком.
#16
Отправлено 28 июля 2009 - 05:23
Почему скучно? Конвейерность объемлющего процесса не означает, что отдельные задачи становятся менее разнообразными и интересными, верно?Мне просто кажется, что разработка ПО не должна быть похожа на конвейер, иначе скучно :)
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#18
Отправлено 28 июля 2009 - 16:53
Ок, смотри, конвейер на примере одной небольшой, но интересной компании:Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.
бизнес ставит задачу - инжиниринг выдает оценку сроков - маркетинг и продажи начинают готовить почву - (дальше цикл в инжиниринге: разработчики пишут код - тестировщики проводят тестирование, и так N итераций) - протестированная версия развертывается на бета-сайте - проходит бета-тестирование - маркетинг поливает подготовленую почву - версия уходит в продажи... ну и так далее. Не скучно? А вроде процесс нормальный.
Конечно, можно веселее сделать, но тогда "Школьный портал" получится.
#19
Отправлено 28 июля 2009 - 18:40
Конвейер подразумевает более мелкие телодвижения. Например ты, как тестер, пишешь кейсы по спеке и прогоняешь, опять пишешь и прогоняешь и т.д.Ок, смотри, конвейер на примере одной небольшой, но интересной компании:Нет, не путаю, говорю именно о конвейерном процессе. Пока оставлю свои мысли для блога.
бизнес ставит задачу - инжиниринг выдает оценку сроков - маркетинг и продажи начинают готовить почву - (дальше цикл в инжиниринге: разработчики пишут код - тестировщики проводят тестирование, и так N итераций) - протестированная версия развертывается на бета-сайте - проходит бета-тестирование - маркетинг поливает подготовленую почву - версия уходит в продажи... ну и так далее. Не скучно? А вроде процесс нормальный.
Конечно, можно веселее сделать, но тогда "Школьный портал" получится.
Вспомни, такие люди приходили не собеседование
#20
Отправлено 28 июля 2009 - 22:03
Это уже особенности построения конвейера в конкретном производстве. Что никак не говорит о том, что сама идея плохая.Конвейер подразумевает более мелкие телодвижения. Например ты, как тестер, пишешь кейсы по спеке и прогоняешь, опять пишешь и прогоняешь и т.д.
Люди, которых мы интервьюировали, чаще всего были воспитаны на конвейере, где использовалось не тестирование, а "контроль качества" в его худшем виде (надеюсь, здесь сейчас не начнется война определений). Что говорит только о том, что и идею контроля качества, не самую плохую, в общем-то, тоже можно реализовать отвратительно. И о том, что "отвратительно" это выглядит только с точки зрения другого типа, без оценки всех деталей и особенностей реализации.
Но, опять же, вывод тут только один - специалист, подходящий для работы на одном типе конвейера, далеко не всегда подходит к другому типу. А на "своем" типе ему может быть вполне весело и даже эффективно.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных