Да, внутренняя разработка: в Google Calendar ставились событие для админов и отправлялось СМС. Получилось своебразное дополнение к системе мониторинга с автоматическим оповещением и логом событий.
Никита, вы бы немного инфы про эти методы выложили на своем сайте, чтобы народ знал, что почем… а то у нас в 99,9% случаев сбор требований — это написание кашеобразного документа под названием ТЗ, человеком, который не будет нести ответственность за проект :)
Спасибо :) Но заголовок согласитесь немного желтоват, народ фактически занимается QA, ведь пишут функциональные тесты (модульные я все-таки отношу к девелоперской деятельности).
Конечно, далеки: здесь будет опрос компаний разных размеров + наша специфика. Но срез будет интересный, я на такую статистику в основном иностранную натыкался.
Я думал на эту тему. Команда, конечно, может распределять задачи самостоятельно на митинге при планировании, нужно тогда немного права по-другому настроить.
Лучше упорядочить их по приоритету в рамках спринта, и распределять по ходу спринта: освободившийся участник(и) берет самую приоритетную задачу, тогда при факапе, вы не сделаете только самые неприоритетные задачи в рамках спринта.
Не холивара ради, есть несколько замечаний относительно написанного вами: Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании. Совместную консенсусную оценку обычно проводят в виде покер-планирования + необходимо кроссфункциональность участников проекта, чтобы не было «своих задач».
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Кроме вышесказанного могу посоветовать приглашать на оценивание задач еще и Product Owner'а, чтобы он четко понимал, откуда взято число + возможно вплывут недопонимание в требованиях в ЮС.
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.
Согласен полностью. Доклад Заборова самый интересный получился. Очень понравился их метод пиления проекта и использования как покомпонентного подхода, так и послойного.
Лучше упорядочить их по приоритету в рамках спринта, и распределять по ходу спринта: освободившийся участник(и) берет самую приоритетную задачу, тогда при факапе, вы не сделаете только самые неприоритетные задачи в рамках спринта.
Мастер — это мост между Заказчиком и командой, он играет основную роль в планировании спринта, определяет его бюджет и распределяет истории по команде.
Вы не совсем правильно понимаете себе роль Скрам Мастера — он просто хранитель церемоний, а отнюдь не мост между заказчиком и командой. Он ни в коем случае не должен распределять ЮСки по участникам команды, команда должна самоуправляться.
Каждый участник команды разработки при планировании оценивает те задачи, в которых разбирается, указывая бюджет задачи в часах. По завершении планирования каждый участник занимается только своими задачами.
Каждый участник должен оценивать все задачи, а распределение должно происходить во время спринта, а не при его планировании. Совместную консенсусную оценку обычно проводят в виде покер-планирования + необходимо кроссфункциональность участников проекта, чтобы не было «своих задач».
Затем команда просматривает созданные Заказчиком задачи и оценивает их трудоемкость, указывая бюджет. При этом участники команды видят оценки друг друга и могут на них ориентироваться, либо не видят и надеются только на себя.
Кроме вышесказанного могу посоветовать приглашать на оценивание задач еще и Product Owner'а, чтобы он четко понимал, откуда взято число + возможно вплывут недопонимание в требованиях в ЮС.
Мастер создает спринт, в котором Заказчик в обсуждении с Мастером и командой указывает сроки (deadline). К указанному сроку спринт должен быть готов для демонстрации.
В скраме спринты жестко затайбоксены — у них всегда одна и та же длина. Это необходимо, чтобы у команды и заказчиков вырабатывался определенный ритм работы.