Сегодня я немного расскажу о тех ролях, котрые должны появиться у вас при работе по методологии Scrum.
Итак, начнем. При работе над любым проектом есть как минимум две стороны: исполнители и заказчики. Для ширпотреба это команда разработки и будущие покупатели, для внутренней автоматизации это команда разработки и автоматизируемое подразделение. Бывают случаи, когда команда разработки является и собственным заказчиком... Но, во-первых, это бывает достаточно редко, а во-вторых, кроме команды непосредственно разрабатывающей нечто, этим нечто будут пользоваться и другие команды. Поэтому будем считать заказчики и команда разработки.
Заказчик в процессе разработки представлен владельцем продукта.
Владелец продукта (Product Owner) - это человек который отвечает за реализацию продукта. Именно он определяет, какие полезности можно и нужно реализовать.
В чем же состоит его работа?
Во-первых, Product Owner должен определиться с видением (Vision) будущей системы. Что это будет: курятник, атомный ледокол или система подсчета очков в гольфе.
Во-вторых, он отвечает за постановку задач команде (не конкретным разработчикам, а именно всей команде). Задачи ставятся не в виде: «пили 3 часа», а в виде: «мне нужен стул, с целью отдохнуть после трудового дня». В следующей части я расскажу, о том, что его задачи это не Task, а User Story (пользовательская история), но вид у этих задач будет именно такой, как я привел про стул.
В-третьих, управляет ожиданиями заказчика. Собственно эта задача заключается в том, чтобы понять, что заказчику наиболее важно сейчас и именно этим задачам (давайте, раз уж все равно назвал их правильно, буду в дальнейшем говорить не «задачи», а «истории») давать наибольший приоритет. Кстати, те истории, которые раньше считались важными, могут терять приоритет, а в некоторых случаях и удаляться из списка на разработку.
В-четвертых, дает простые и понятные критерии, по которым команда может оценить, насколько успешно реализованы те или иные пользовательские истории.
В-пятых, осуществляет приемку каждой итерации по критериям, сформулированным в соответствии с предыдущим пунктом.
Как называется должность этого человека в штатном расписании? Сложно сказать. Для разработки на заказ, это будет представитель заказчика. Для продуктового решения – менеджер продукта. Для внутренней – менеджер проекта.
Scrum Master - опять же 1 человек, который вроде уже и часть команды, но вроде, как и немного в стороне. Он отвечает за то, чтобы Scrum в проекте работал. Что он должен делать?
Во-первых, устраняет препятствия. Т.е. все то, что мешает команде плодотворно работать. Видели вот эту картинку?
В этой ситуации Scrum Master будет отвечать за то, чтобы: пнуть IT отдел на оптимизацию Build сервера, объясненить владельцу бюджета почему программистам нужны новые компьютеры и т.д.
Во-вторых, отвечает за соблюдение практик в команде. Про практики мы поговорим чуть позже, и пока вам придется поверить мне на слово, что они есть, и что, их надо соблюдать.
В-третьих, отслеживает прогресс команды в решении поставленных задач, и старается переорганизовать работу так, чтобы эффективность команды повышалась.
Обысно на этой в этой роли выступает TeamLeader или менеджер проекта, или, что актуально в процессе внедрения Scrum, приглашенный специалист, показывающий как надо организовывать работу по этой методике. И, кстати, несмотря на высокую должность и, как правило, высокие права, Scrum Master не ставит задач команде.
Команда - это все те, кто будет проектировать базы данных и классы, писать код, тестировать и исправлять баги. Команда выступает как единое целое, именно она определяет объем историй, который будет выполнен в рамках итерации. Именно команда несет ответственность перед Product Owner по выполнению взятых на себя обязательств. Нет программистов Пети и Коли, нет документописательницы Маши, нет тестировщика Феди. Есть команда, и все они должны стремиться к общему результату. Типичный размер команды 5-7 человек.
Функции команды:
Во-первых, оценивают сложность историй предложенных Product Owner-ом. Про оценку я хочу написать отдельную статью, поэтому следите за продолжениями...
Во-вторых, определяют список историй на итерацию.
В-третьих, вы не поверите, но определяют какие задачи нужно решить, чотбы пользователи получили полезности описанные в историях.
В-четвертых, проектируют, пишут, тестируют.
Итак, исходя из вышесказанного, команда состоит из спецтиалистов, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями, навыками и знаниями. Команда называется самоорганизующейся, т.к. ни Product Owner, ни Scrum Master не говорит какие задачи надо решать и в каком порядке. Все это на совести команды. Именно поэтому, в Scrum вклад отдельных членов команды не оценивается, так как это разваливает самоорганизацию команды.
Ну и вместо заключения, все эти роли нужны, но кроме команды - необязательны. Т.е. ну нет у Product Owner-а, но есть ТЗ или спецификация. Садитесь и нарезайте истории. Нет у вас Scrum Master, и никто не умеет применять Scrum, собирайтесь, читайте, думайте и неймейте вместе. Как я уже говорил, Scrum - это гибкая методология. Есть советы, а дальше Команда, задача и здравый смысл.
Итак, начнем. При работе над любым проектом есть как минимум две стороны: исполнители и заказчики. Для ширпотреба это команда разработки и будущие покупатели, для внутренней автоматизации это команда разработки и автоматизируемое подразделение. Бывают случаи, когда команда разработки является и собственным заказчиком... Но, во-первых, это бывает достаточно редко, а во-вторых, кроме команды непосредственно разрабатывающей нечто, этим нечто будут пользоваться и другие команды. Поэтому будем считать заказчики и команда разработки.
Заказчик в процессе разработки представлен владельцем продукта.
Владелец продукта (Product Owner) - это человек который отвечает за реализацию продукта. Именно он определяет, какие полезности можно и нужно реализовать.
В чем же состоит его работа?
Во-первых, Product Owner должен определиться с видением (Vision) будущей системы. Что это будет: курятник, атомный ледокол или система подсчета очков в гольфе.
Во-вторых, он отвечает за постановку задач команде (не конкретным разработчикам, а именно всей команде). Задачи ставятся не в виде: «пили 3 часа», а в виде: «мне нужен стул, с целью отдохнуть после трудового дня». В следующей части я расскажу, о том, что его задачи это не Task, а User Story (пользовательская история), но вид у этих задач будет именно такой, как я привел про стул.
В-третьих, управляет ожиданиями заказчика. Собственно эта задача заключается в том, чтобы понять, что заказчику наиболее важно сейчас и именно этим задачам (давайте, раз уж все равно назвал их правильно, буду в дальнейшем говорить не «задачи», а «истории») давать наибольший приоритет. Кстати, те истории, которые раньше считались важными, могут терять приоритет, а в некоторых случаях и удаляться из списка на разработку.
В-четвертых, дает простые и понятные критерии, по которым команда может оценить, насколько успешно реализованы те или иные пользовательские истории.
В-пятых, осуществляет приемку каждой итерации по критериям, сформулированным в соответствии с предыдущим пунктом.
Как называется должность этого человека в штатном расписании? Сложно сказать. Для разработки на заказ, это будет представитель заказчика. Для продуктового решения – менеджер продукта. Для внутренней – менеджер проекта.
Scrum Master - опять же 1 человек, который вроде уже и часть команды, но вроде, как и немного в стороне. Он отвечает за то, чтобы Scrum в проекте работал. Что он должен делать?
Во-первых, устраняет препятствия. Т.е. все то, что мешает команде плодотворно работать. Видели вот эту картинку?
Во-вторых, отвечает за соблюдение практик в команде. Про практики мы поговорим чуть позже, и пока вам придется поверить мне на слово, что они есть, и что, их надо соблюдать.
В-третьих, отслеживает прогресс команды в решении поставленных задач, и старается переорганизовать работу так, чтобы эффективность команды повышалась.
Обысно на этой в этой роли выступает TeamLeader или менеджер проекта, или, что актуально в процессе внедрения Scrum, приглашенный специалист, показывающий как надо организовывать работу по этой методике. И, кстати, несмотря на высокую должность и, как правило, высокие права, Scrum Master не ставит задач команде.
Команда - это все те, кто будет проектировать базы данных и классы, писать код, тестировать и исправлять баги. Команда выступает как единое целое, именно она определяет объем историй, который будет выполнен в рамках итерации. Именно команда несет ответственность перед Product Owner по выполнению взятых на себя обязательств. Нет программистов Пети и Коли, нет документописательницы Маши, нет тестировщика Феди. Есть команда, и все они должны стремиться к общему результату. Типичный размер команды 5-7 человек.
Функции команды:
Во-первых, оценивают сложность историй предложенных Product Owner-ом. Про оценку я хочу написать отдельную статью, поэтому следите за продолжениями...
Во-вторых, определяют список историй на итерацию.
В-третьих, вы не поверите, но определяют какие задачи нужно решить, чотбы пользователи получили полезности описанные в историях.
В-четвертых, проектируют, пишут, тестируют.
Итак, исходя из вышесказанного, команда состоит из спецтиалистов, которые вносят свой вклад в общий успех проекта в соответствии со своими способностями, навыками и знаниями. Команда называется самоорганизующейся, т.к. ни Product Owner, ни Scrum Master не говорит какие задачи надо решать и в каком порядке. Все это на совести команды. Именно поэтому, в Scrum вклад отдельных членов команды не оценивается, так как это разваливает самоорганизацию команды.
Ну и вместо заключения, все эти роли нужны, но кроме команды - необязательны. Т.е. ну нет у Product Owner-а, но есть ТЗ или спецификация. Садитесь и нарезайте истории. Нет у вас Scrum Master, и никто не умеет применять Scrum, собирайтесь, читайте, думайте и неймейте вместе. Как я уже говорил, Scrum - это гибкая методология. Есть советы, а дальше Команда, задача и здравый смысл.
Комментариев нет:
Отправить комментарий