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

Программирование на Python для тестировщиков
онлайн, начало 23 октября
Тестирование безопасности
онлайн, начало 28 октября
Школа для начинающих тестировщиков
онлайн, начало 22 октября
Автоматизатор мобильных приложений
онлайн, начало 28 октября
Фотография

Асхат Уразбаев: Scrum — подход к управлению сложными проектами


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

#1 Case

Case

    Основатель

  • Members
  • PipPipPipPipPipPip
  • 7 071 сообщений
  • ФИО:Панкратов Вячеслав
  • Город:Украина, Киев.

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

1 июня 2010 в рамках совместной инициативы Гильдии менеджеров программных проектов и Локальной группы по интересам «Управление проектами в ИТ и телекоммуникациях» московского отделения американского Института управления проектами (PMI) состоялся семинар Асхата Уразбаева «Scrum — подход к управлению сложными проектами».

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

Семинар провел Асхат Уразбаев, вице-президент Гильдии, евангелист Agile и Scrum, Agile Coach, совладелец компании ScrumTrek, основатель сообщества AgileRussia.

Предлагаем Вашему вниманию видеокаст выступления Асхата:


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

Участники смогут зачесть 1 PDU за этот семинар при продлении сертификации PMI PMP, PgMP. ID семинара: OSMC16.

http://feedads.g.dou...t2FA/0/di</img>
http://feedads.g.dou...t2FA/1/di</img>

http://feeds.feedburner.com/~r/it4business/~4/omdcfrRcT-Y
  • 0
Слава Панкратов
Редактор портала www.it4business.ru

#2 OliaBudn

OliaBudn

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

  • Members
  • Pip
  • 28 сообщений
  • ФИО:Будницкая Ольга

Отправлено 06 июля 2010 - 12:40

Уфф... Прослушала все, примерила на себя, проанализировала, что работает у нас так и что не так. Но как всегда вопросы остались.
1) Везде, где я читала про Скрам речь шла об одной команде. А как быть если 11 девелоперов ? Ну вот у нас они поделены на 2 команды. Плюс еще есть 3 тестировщика, которые тестируют всё. Это уже не скрам? Так он не работает? Или
На сколько я читала и слышала, скрам хорошо работает для маленьких команд. Если есть уже 2-3 команды, то возникает необходимость общаться командами. И тогда же возникает разграничение ответственности. Что уже противоречит идеям Скрама.
С тестировщиками еще сложнее. 3 тестировщика на 2 команды не делятся. Мы пытались работать по схеме по 1 тестировщику в команде + 1 приходящий, но результат скорее негативный. Тестировщики должны знать весь функционал продукта. Иначе возникает "дырка" между командами, которая не покрывается тестами. Поэтому эволюционным путем пришли к идее, что тестировщики составляют отдельную команду.
Был ли у кого либо позитивный опыт внедрения Скрам на таких командах?
2) Во время просмотра еще возник вопрос, может ли быть так, что PO - это не один человек, а несколько? Таким образом получится команда PO, команда девелоперов и команда тестеров. Каждая команда шарит знания внутри. На данный момент у нас PO (Product Owner) заняты тем, что пытаются принять все ЮС, насоздавать новые и еще выяснить как должны работать те, которые в процессе создания (это у них занимает уйму времени, т.к. необходимы консультации с другими людьми). Они конкретно зашиваются и времени даже на принятие сделанных сторей им не хватает. Как их разгрузить?
2) Процесс тестирования в скраме не понятен. Done - это когда девелопер закончил? Или когда все проверено и оттестировано? Тогда как совершается передача тестировщику?

На данный момент от скрама у нас осталась итеративность, ЮС-ри, РО, мастера (главная функция, чтоб все каждое утро проставили часики в burn down chart) , burn down chart. Вот собственно и все.
  • 0

#3 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 06 июля 2010 - 13:57

На данный момент от скрама у нас осталась итеративность, ЮС-ри, РО, мастера (главная функция, чтоб все каждое утро проставили часики в burn down chart) , burn down chart. Вот собственно и все.

http://www.slideshar...scrum-tailoring
  • 0
Regards,
Alexey

#4 SALar

SALar

    Гуру

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


Отправлено 06 июля 2010 - 15:21

А зачем в SCRUM тестировщики? Они и в других методологиях не очень то нужны. В скраме это просто нарушение базового принципа кросфункциональности.
  • 0

-- 

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

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

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

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

 


#5 OliaBudn

OliaBudn

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

  • Members
  • Pip
  • 28 сообщений
  • ФИО:Будницкая Ольга

Отправлено 07 июля 2010 - 07:56

А зачем в SCRUM тестировщики? Они и в других методологиях не очень то нужны. В скраме это просто нарушение базового принципа кросфункциональности.


Очень весело слышать такое. :help: Т.е. вы рискнете сказать, что тестировщики вообще не нужны? Про кроссфункциональность - это вы имеете ввиду, что программеры будут тестировать? Может и тестирование не нужно вообще как класс? Как-то попахивает прошлым веком, когда тестирование считалось ненужным процессом. И еще интересно, что по этому поводу скажет уважаемый Слава Панкратов. :nea:
И кстати, рекомендую прочитать книгу Lisa Crispin and Janet Gregory "Agile Testing. A Practical Guide for Testers and Agile Teams". Есть и русский аналог, но я читать его не смогла - переводчик ладно, он лицо отстраненное, но вот рецензенту - руки оторвать.
Тем не менее я отвечу - это нужно делать затем, что тестирование тоже занимает время. И если одной из задач (фич?) скрама является определение даты окончания проекта, то определить его невозможно. Допустим программист сделал ЮС, поставил ее в done, тестировщик открыл, а она не работает. Возможно она не работает в каких-то реальных условиях на компе у тестировщика и с текущим билдом. Но не работает. А надо, чтоб работала. И как ее можно считать сделанной. А заказчику показывать? Вот для этого время на тестирование и должно включаться в расчеты. Хотя, как правило, время на тестирование можно урезать и гадать, как это скажется на качестве.
  • 0

#6 OliaBudn

OliaBudn

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

  • Members
  • Pip
  • 28 сообщений
  • ФИО:Будницкая Ольга

Отправлено 07 июля 2010 - 08:15

На данный момент от скрама у нас осталась итеративность, ЮС-ри, РО, мастера (главная функция, чтоб все каждое утро проставили часики в burn down chart) , burn down chart. Вот собственно и все.

http://www.slideshar...scrum-tailoring

У нас совсем не похоже. Вроде все условия созданы (ну за исключением того, что манагеры (PO) находятся в Австрии, а девелоперы и тестировщики в Беларуси). А так - все признаки на лицо, но не работает. Когда только внедряли, то в комнату к девелоперам было входить страшно. Казалось, что могут запустить любым тяжелым предметом, который под руку попадет. Потом приехал Agile coach. Смелый парень. Кинулся разруливать, но в итоге свалился на то, что ответственность за отдельную часть - это круто. Оценивать стори может тот, кто ее делать будет и для этого совершенно не нужно собирать всю команду (до этого обсуждения беклога длились 1,5 дня, после этого время сократилось до 15-30 минут). И еще манагерам как и раньше приходится выдавать задания конкретным людям, а не команде. Тестеров в отдельную команду (у них и так самоорганизующаяся команда - тимлида нет, а оно работает, задания можно ставить на команду и знать, что выполнят, даже если выживет только 1 из 3-х.) Зато обстановка в офисе нормализовалась, доски висят нетронутыми (далеко идти, аж в соседнюю комнату, а у каждого комп - открой Excel и посмотри.) Короче работай сам и дай работать другому.
А еще один американский менеджер мне плакался, что у них Скрам вообще зашел в тупик, потому что команда очень часто обновлялась - у них это в порядке вещей.
  • 0

#7 LeshaL

LeshaL

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 094 сообщений
  • ФИО:Алексей Лянгузов
  • Город:Saint-Petersburg


Отправлено 07 июля 2010 - 19:32

А зачем в SCRUM тестировщики? Они и в других методологиях не очень то нужны. В скраме это просто нарушение базового принципа кросфункциональности.

Хочешь делай по ХР или по Scrum.
Без тестеров получится лишь срам.
  • 0
Regards,
Alexey




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

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

Яндекс.Метрика
Реклама на портале