Pull to refresh
175
0
Борис Вольфсон @blv

Пользователь

Send message
Спасибо :) Постараемся время как-то поудобнее выбрать :)
Вань, к сожалению, организаторы некоторое время тянули с помещением :(
Мы проводим такие «небольшие» конференции достаточно часто (по 4-6 часов общей длительности), чтобы публика не успела устать :)
Обычно проводим по субботам, в этот раз проводим не у себя в офисе… замечание учтем :)
Помню прошлый твой доклад собрал больше всех «плюсиков» и вопросов было больше всего :)
В нашем департаменте человек 30.
Да, внутренняя разработка: в Google Calendar ставились событие для админов и отправлялось СМС. Получилось своебразное дополнение к системе мониторинга с автоматическим оповещением и логом событий.
А какие игры будешь показывать на своем тренинге?
Никита, вы бы немного инфы про эти методы выложили на своем сайте, чтобы народ знал, что почем… а то у нас в 99,9% случаев сбор требований — это написание кашеобразного документа под названием ТЗ, человеком, который не будет нести ответственность за проект :)
А сфера деятельности, если не секрет?
На блог Юлии подписан, на www.software-testing.ru тоже, но за ссылку спасибо, там информация очень структурирована :)
Спасибо :) Но заголовок согласитесь немного желтоват, народ фактически занимается QA, ведь пишут функциональные тесты (модульные я все-таки отношу к девелоперской деятельности).
Можно пруфлинк не холивара ради, а для саморазвития?
Конечно, далеки: здесь будет опрос компаний разных размеров + наша специфика. Но срез будет интересный, я на такую статистику в основном иностранную натыкался.
Я думал на эту тему. Команда, конечно, может распределять задачи самостоятельно на митинге при планировании, нужно тогда немного права по-другому настроить.
Лучше упорядочить их по приоритету в рамках спринта, и распределять по ходу спринта: освободившийся участник(и) берет самую приоритетную задачу, тогда при факапе, вы не сделаете только самые неприоритетные задачи в рамках спринта.
Не холивара ради, есть несколько замечаний относительно написанного вами:
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.

Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании. Совместную консенсусную оценку обычно проводят в виде покер-планирования + необходимо кроссфункциональность участников проекта, чтобы не было «своих задач».

Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Кроме вышесказанного могу посоветовать приглашать на оценивание задач еще и Product Owner'а, чтобы он четко понимал, откуда взято число + возможно вплывут недопонимание в требованиях в ЮС.

Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Состав участников достаточно мощный для немосковской конференции. По гибкому моделированию будут доклады?
За последние 30 минут можете смело ругать меня. :)
Согласен полностью. Доклад Заборова самый интересный получился. Очень понравился их метод пиления проекта и использования как покомпонентного подхода, так и послойного.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Works in
Registered
Activity