2016-03-20: Про устройство Scrum - из ответов на вопросы

Материал из MaksWiki
Перейти к: навигация, поиск

Вчера в обсуждении на FB дал подробный комментарий про устройство Scrum по заданным вопросам, сохраняю к себе в блог для памяти. Интересующиеся могут пойти по ссылке, там есть и другие содержательные и интересные ответы.

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

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.