2016-03-20: Про устройство Scrum - из ответов на вопросы
Материал из MaksWiki
Вчера в обсуждении на FB дал подробный комментарий про устройство Scrum по заданным вопросам, сохраняю к себе в блог для памяти. Интересующиеся могут пойти по ссылке, там есть и другие содержательные и интересные ответы.
- А у спринта точно должна быть цель, даже когда самое начало проекта? Ответ. У спринта точно должна быть цель. Разработка проекта квантуется в спринты целостными этапами, а не просто грызется список задач. Если надо просто грызть список задач - используем Kanban. Дальше нужен отдельный разбор по поводу не достигнутых целей. Если она не достигнута и команде по фигу - значит цель не принята, она не воспринимается командой как цель, и с этим надо работать.
- Я как PO - особенно на начальных этапах не понимаю что делает команда - она делает какие-то технические вещи, которые я не понимаю - и так длится какое-то время. Мне нужно изучить основы разработки или просто доверять команде? А сколько все эти технические вещи должны длиться? Ответ. Команда должна уметь объяснить Вам необходимость этих технических вещей с точки зрения процесса разработки (который вы признаете значимым). И далее нужно контролировать результат, достижение этих целей. Если команда профессиональная, то она сможет объяснить это без труда, потому что профессионал действует осмысленно и целесообразно, а значит может объяснить свои действия - то есть это не наезд и не "очень долго, ты не поймешь". Доверять можно (и нужно) в том, что эта цель достигается именно этими техническими средствами и занимает столько времени, но цель должна быть предъявлена,а достижение - зафиксировано во времени.
- Команда к тому же распределенная. Не понятно как и что должен делать scrum-мастер в таком случае? Ответ. Scrum-мастер должен делать то же самое - помогать команде соорганизоваться. работать вместе на достижение цели. В случает распределенной команды ему сложнее. По методам - есть разная литература, выступления на конференциях и другие материалы.
- Зачем нужны тестеры, автотесты или тесты должен делать разработчик? Ответ. Отдельные тестеры нужны чтобы снизить стоимость разработки за счет специализации, разделения труда. Можно, чтобы разработчик делал тесты сам и тестеров не было. Можно, чтобы тестеры руководили и проверяли как разработчики делают тесты. Есть разные практики, какая подходит вам - зависит от специфики проекта. То же касается автотестов. Какие именно автотесты нужны проекту, и достижение каких целей они обеспечат - зависят от проекта. Если разработчики выступают за автотесты - нужно осмысленная для вас цель и контроль достижения, как и для любых технических действий.
- Не устраивает юзабилити интерфейсов, разработчики считают что INSPIRE вполне достаточно - но мне интерфейс кажется так себе. Можно ли отходить от шаблонов? Нужно брать в команду дизайнера интерфейсов? Ответ. Юзабилити интерфейсов не устраивает из эстетических соображений, или есть представление, что оно существенно не устроит Заказчиков или Пользователей? От ответа на этот вопрос зависит - что делать и нужен ли дизайнер. В любом случае, интерфейсы должны быть в русле шаблона, допустимого для выбранных фреймворков, если они не устраивают - надо менять фреймворк. Интерфейсы "поперек" фреймворка повышают трудоемкость разработки на порядок (да, в 10 раз) и более.
- Насколько проработанными должны быть юзер стори? Ответ. Userstory должны быть проработаны настолько, чтобы (а) команда на планировании адекватно могла их оценить; (б) эта оценка подтверждалась практикой; (в) результат соответствовал ваши ожиданиям.
- Проектов много - поэтому я просто 1 спринт делаю 1 проект, а другой спринт - другой - или разработчик участвует в нескольких спринтах - это не правильно? Ответ. Могут быть конструкции, когда команда работает над несколькими проектами. Они сложные замешивать задачи можно по-разному. Участие разработчиков в нескольких командах - нежелательно (доступно немногим, это исключение).
[ Иерархический вид ]Комментарии
Войдите, чтобы комментировать.