6943
правки
Изменения
Новая страница: «Вчера в [https://www.facebook.com/groups/agilerussia/permalink/1038095839597982/ обсуждении на FB] дал подробный комментар…»
Вчера в [https://www.facebook.com/groups/agilerussia/permalink/1038095839597982/ обсуждении на FB] дал подробный комментарий про устройство Scrum по заданным вопросам, сохраняю к себе в блог для памяти. Интересующиеся могут пойти по ссылке, там есть и другие содержательные и интересные ответы.
# '''А у спринта точно должна быть цель, даже когда самое начало проекта? Ответ.''' У спринта точно должна быть цель. Разработка проекта квантуется в спринты целостными этапами, а не просто грызется список задач. Если надо просто грызть список задач - используем Kanban. Дальше нужен отдельный разбор по поводу не достигнутых целей. Если она не достигнута и команде по фигу - значит цель не принята, она не воспринимается командой как цель, и с этим надо работать.
# '''Я как PO - особенно на начальных этапах не понимаю что делает команда - она делает какие-то технические вещи, которые я не понимаю - и так длится какое-то время. Мне нужно изучить основы разработки или просто доверять команде? А сколько все эти технические вещи должны длиться? Ответ.''' Команда должна уметь объяснить Вам необходимость этих технических вещей с точки зрения процесса разработки (который вы признаете значимым). И далее нужно контролировать результат, достижение этих целей. Если команда профессиональная, то она сможет объяснить это без труда, потому что профессионал действует осмысленно и целесообразно, а значит может объяснить свои действия - то есть это не наезд и не "очень долго, ты не поймешь". Доверять можно (и нужно) в том, что эта цель достигается именно этими техническими средствами и занимает столько времени, но цель должна быть предъявлена,а достижение - зафиксировано во времени.
# '''Команда к тому же распределенная. Не понятно как и что должен делать scrum-мастер в таком случае? Ответ.''' Scrum-мастер должен делать то же самое - помогать команде соорганизоваться. работать вместе на достижение цели. В случает распределенной команды ему сложнее. По методам - есть разная литература, выступления на конференциях и другие материалы.
# '''Зачем нужны тестеры, автотесты или тесты должен делать разработчик? Ответ.''' Отдельные тестеры нужны чтобы снизить стоимость разработки за счет специализации, разделения труда. Можно, чтобы разработчик делал тесты сам и тестеров не было. Можно, чтобы тестеры руководили и проверяли как разработчики делают тесты. Есть разные практики, какая подходит вам - зависит от специфики проекта. То же касается автотестов. Какие именно автотесты нужны проекту, и достижение каких целей они обеспечат - зависят от проекта. Если разработчики выступают за автотесты - нужно осмысленная для вас цель и контроль достижения, как и для любых технических действий.
# '''Не устраивает юзабилити интерфейсов, разработчики считают что INSPIRE вполне достаточно - но мне интерфейс кажется так себе. Можно ли отходить от шаблонов? Нужно брать в команду дизайнера интерфейсов? Ответ.''' Юзабилити интерфейсов не устраивает из эстетических соображений, или есть представление, что оно существенно не устроит Заказчиков или Пользователей? От ответа на этот вопрос зависит - что делать и нужен ли дизайнер. В любом случае, интерфейсы должны быть в русле шаблона, допустимого для выбранных фреймворков, если они не устраивают - надо менять фреймворк. Интерфейсы "поперек" фреймворка повышают трудоемкость разработки на порядок (да, в 10 раз) и более.
# '''Насколько проработанными должны быть юзер стори? Ответ.''' Userstory должны быть проработаны настолько, чтобы (а) команда на планировании адекватно могла их оценить; (б) эта оценка подтверждалась практикой; (в) результат соответствовал ваши ожиданиям.
# '''Проектов много - поэтому я просто 1 спринт делаю 1 проект, а другой спринт - другой - или разработчик участвует в нескольких спринтах - это не правильно? Ответ.''' Могут быть конструкции, когда команда работает над несколькими проектами. Они сложные замешивать задачи можно по-разному. Участие разработчиков в нескольких командах - нежелательно (доступно немногим, это исключение).
{{wl-publish: 2016-03-20 09:35:48 +0300 | MaksTsepkov }}
# '''А у спринта точно должна быть цель, даже когда самое начало проекта? Ответ.''' У спринта точно должна быть цель. Разработка проекта квантуется в спринты целостными этапами, а не просто грызется список задач. Если надо просто грызть список задач - используем Kanban. Дальше нужен отдельный разбор по поводу не достигнутых целей. Если она не достигнута и команде по фигу - значит цель не принята, она не воспринимается командой как цель, и с этим надо работать.
# '''Я как PO - особенно на начальных этапах не понимаю что делает команда - она делает какие-то технические вещи, которые я не понимаю - и так длится какое-то время. Мне нужно изучить основы разработки или просто доверять команде? А сколько все эти технические вещи должны длиться? Ответ.''' Команда должна уметь объяснить Вам необходимость этих технических вещей с точки зрения процесса разработки (который вы признаете значимым). И далее нужно контролировать результат, достижение этих целей. Если команда профессиональная, то она сможет объяснить это без труда, потому что профессионал действует осмысленно и целесообразно, а значит может объяснить свои действия - то есть это не наезд и не "очень долго, ты не поймешь". Доверять можно (и нужно) в том, что эта цель достигается именно этими техническими средствами и занимает столько времени, но цель должна быть предъявлена,а достижение - зафиксировано во времени.
# '''Команда к тому же распределенная. Не понятно как и что должен делать scrum-мастер в таком случае? Ответ.''' Scrum-мастер должен делать то же самое - помогать команде соорганизоваться. работать вместе на достижение цели. В случает распределенной команды ему сложнее. По методам - есть разная литература, выступления на конференциях и другие материалы.
# '''Зачем нужны тестеры, автотесты или тесты должен делать разработчик? Ответ.''' Отдельные тестеры нужны чтобы снизить стоимость разработки за счет специализации, разделения труда. Можно, чтобы разработчик делал тесты сам и тестеров не было. Можно, чтобы тестеры руководили и проверяли как разработчики делают тесты. Есть разные практики, какая подходит вам - зависит от специфики проекта. То же касается автотестов. Какие именно автотесты нужны проекту, и достижение каких целей они обеспечат - зависят от проекта. Если разработчики выступают за автотесты - нужно осмысленная для вас цель и контроль достижения, как и для любых технических действий.
# '''Не устраивает юзабилити интерфейсов, разработчики считают что INSPIRE вполне достаточно - но мне интерфейс кажется так себе. Можно ли отходить от шаблонов? Нужно брать в команду дизайнера интерфейсов? Ответ.''' Юзабилити интерфейсов не устраивает из эстетических соображений, или есть представление, что оно существенно не устроит Заказчиков или Пользователей? От ответа на этот вопрос зависит - что делать и нужен ли дизайнер. В любом случае, интерфейсы должны быть в русле шаблона, допустимого для выбранных фреймворков, если они не устраивают - надо менять фреймворк. Интерфейсы "поперек" фреймворка повышают трудоемкость разработки на порядок (да, в 10 раз) и более.
# '''Насколько проработанными должны быть юзер стори? Ответ.''' Userstory должны быть проработаны настолько, чтобы (а) команда на планировании адекватно могла их оценить; (б) эта оценка подтверждалась практикой; (в) результат соответствовал ваши ожиданиям.
# '''Проектов много - поэтому я просто 1 спринт делаю 1 проект, а другой спринт - другой - или разработчик участвует в нескольких спринтах - это не правильно? Ответ.''' Могут быть конструкции, когда команда работает над несколькими проектами. Они сложные замешивать задачи можно по-разному. Участие разработчиков в нескольких командах - нежелательно (доступно немногим, это исключение).
{{wl-publish: 2016-03-20 09:35:48 +0300 | MaksTsepkov }}
