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

Тестирование REST API
онлайн, начало 2 ноября
Тестирование безопасности
онлайн, начало 28 октября
Практикум по тест-дизайну 2.0
онлайн, начало 30 октября
Автоматизатор мобильных приложений
онлайн, начало 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 анонимных

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