Как использовать agile и scrum для управления проектами

Приоритизация задач в несколько шагов

Сначала рассмотрим способ, который поможет отбросить ненужные гипотезы.

Сделайте табличку из строчек с описанием гипотез, а по вертикали обозначьте коллег, которые участвуют в процессе разработки и обладают знаниями по этой фиче. Каждый проставляет в своей колонке по всем строкам баллы по определенной заранее шкале. Выводим сумму и видим, какие фичи команда считает топовыми.

В первый раз таблицу создают вручную, а потом делают ретроспективы, автоматизируя. Таким образом мы смотрим, действительно ли все произошло так, как мы прогнозировали. Через несколько итераций вы поймете свои реальные коэффициенты и сможете зашить их в формулу таблицы.

Потом приходит время для следующей, более глубокой приоритизации.

Посмотрим, какие существуют инструменты приоритизации:

Разберем один из них — RICE. Это метод приоритизации гипотез по разработке фич. Расшифровка названия:

• Reach — охват;
• Impact — влияние;
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат;
• Effort — трудозатраты.

Чтобы получить оценку по RICE, необходимо следовать следующему алгоритму приоритизации.

Reach — показывает, сколько пользователей будут применять новую функциональность. Посмотреть это можно по системам веб-аналитики, по прошлому опыту или по конкурентам.

Например, представим, что вы ставите баннер в новом формате на главной странице сайта, посещаемость которой — 10 000 уникальных пользователей в месяц. Получается, именно столько людей увидят вашу фичу. Если вы взяли месячный период, то используйте его при рассмотрении всех гипотез. Учитывайте это и тогда, когда начнете считать Impact в денежном выражении.

Impact — это величина, характеризующая влияние вашей фичи. В идеале ее нужно представлять в денежном эквиваленте, так как для бизнеса это понятнее всего. Но часто останавливаются на субъективной оценке.

Confidence — чтобы понять этот фактор, задайте себе вопрос: как быть уверенным в своих действиях? Правильно: подкрепить их.

Доказательства могут быть разными, и поэтому справедливо придать каждому из них свой вес.

Перечислим часто используемые и известные способы подкрепления:

• UX-исследования;
• опросы;
• интервью;
• наблюдения;
• MVP;
• A/B-тесты;
• сторонние исследования;
• аналитика;
• и другие пользовательские исследования.

Не нужно забывать, что помимо результатов качественных и количественных исследований есть более простые доводы, почему вашу фичу должны взять в работу. Среди них:

• собственные убеждения;
• мировые тренды;
• мнение команды, эксперта, руководителя;
• «все конкуренты делают это», «продукт не работает без этого».

Еще важные каналы информации:

• топ обращений в саппорт;
• топ запросов от сейлз-менеджеров;
• топ запросов от клиентов.

В итоге у нас сформировался перечень способов, как подкрепить гипотезу. Этот список с расставленными весами привел в удобный вид Itamar Gilad — продакт-менеджер Gmail и YouTube . Рекомендую почитать его блог — https://itamargilad.com/.

Как видите, если гипотеза — это только ваше мнение, то у нее минимальный вес. Поэтому прежде чем что-то отдавать в разработку, подумайте, как проверить, насколько необходима эта фича, и сможете ли вы сделать ее с минимальным вовлечением программистов. Ведь все мы знаем, что самые большие затраты уходят в фонд оплаты труда разработки.

Effort — оценивается либо в часах разработки, либо в story point — это не меняет сути. Всегда можно привести к одной шкале.

В целом это все. Теперь можно заносить данные в таблицу, фильтровать по наибольшему значению Score и брать в работу.

Источник статьи: http://geekbrains.ru/posts/tasks_scoring

Контролируйте процессы

Диаграмма сгорания — это наглядная демонстрация того, как команда «переваривает» все задачи проекта. Красная линия — план. Синяя — то, что делает команда. Диаграмма обновляется каждый день. Вы сразу видите, когда есть отклонения от плана: можно спокойно «крутить гайки» или менять приоритеты в бэклоге.

Так выглядит диаграмма сгорания в реальных проектах.

Контролируйте работу команды с помощью двух scrum-показателей:

• Focus Factor — коэффициент, который показывает, сколько задача должна была выполняться по плану, а сколько вышло в итоге. Так оценивается «концентрация» команды над проектом.
• Velocity — производительность. Поможет спрогнозировать количество задач, которые команда сможет взять в следующем спринте — в зависимости от количества готовых тикетов в прошлом. Velocity = Focus Factor * Оценка новых задач.

Стройте график планового и фактического расхода времени на задачи. Через несколько спринтов столбцы станут примерно одинаковыми.

Личный опыт: как готовиться к экзамену на сертификат от scrum.org

Я выбрала для себя сертификат от Scrum.org. Для меня был достаточно важен вопрос стоимости — тут PSM I от Scrum.org является неоспоримым лидером. При этом о какой-то потере качества при самоподготовке говорить нельзя. Сам экзамен достаточно сложен, проходной процент высок, и готовиться надо тщательно. Кроме того, мне импонировало то, что пул людей, сдавших этот экзамен, меньше, чем у конкурентов. Это только подстегнуло и усилило мотивацию.

Фото с сайта unsplash.com

Как это ни банально, начинать подготовку необходимо с чтения. Есть несколько ресурсов, изучением которых следует заняться в первую очередь:

The Scrum Guide на русском и английском языках. Каждое предложение наполнено смыслом, поэтому читать нужно максимально вдумчиво. Первый раз можно почитать на русском языке для ознакомления, английская версия важна для прохождения экзамена
Материалы с сайта scrum.org, особенно глоссарий

Его важно освоить потому, что в экзамене могут попадаться даже дословные цитаты оттуда. Важно уметь распознавать некоторые понятия на языке Scrum Guide
Книги

Например, Scrum: A Pocket Guide: A Smart Travel Companion от Gunther Verheyen. Чтение книг поможет еще раз воспринять информацию из Scrum Guide, но в более живой и свободной форме, с примерами.

Освоив теорию, переходим к практике. Есть как минимум 5 качественных симуляторов экзамена на сертификат скрам-мастера:

• Пробный экзамен от scrum.org. 30 вопросов за 30 минут. Вопросы кажутся более простыми, чем на самом экзамене, но тренировка помогает ознакомиться и интерфейсом и общим стилем экзамена
• Бесплатный симулятор The Scrum Master. 20 вопросов за 15 минут. Перефразированные вопросы с экзамена scrum.org помогают не привыкать к конкретным формулировкам и порядку ответов
• Симулятор от Михаила Лапшина. 80 вопросов за 60 минут, есть вариант без таймера. Можно получить комментарий по каждому ответу с разбором ошибок
• Agile and Scrum Practice Test by Knowledge Hut как пример большого количества маленьких пробных тестов на просторах англоязычного интернета
• Симулятор от «аккредитованного» провайдера Management Plaza. 80 вопросов за 60 минут, стоимость около 30 евро.

Для успешного прохождения экзамена нужно иметь хороший уровень английского. Кандидату необходимо уметь быстро читать и понимать вопросы и варианты ответа — времени на поиск разъяснений в словаре не будет.

Еще несколько важных советов:

• Выделите место и время для прохождения экзамена — чтобы вас никто не отвлекал. У вас будет 60 минут и 80 вопросов, это достаточно много заданий в сравнительно малый промежуток времени 
• Записывайте вопросы на отдельный лист. Интерфейс экзамена не предполагает функции «пометок», поэтому номера вопросов, к которым вы хотите вернуться, надо записывать на листик 
• Отвечайте, даже если не уверены. Лучше дать ответы на максимальное количество вопросов, за неверные баллы не снижаются 
• Готовьтесь! У вас, скорее всего, просто не будет времени на проверку вопросов в Google, так что готовьтесь ответственно.

В результате подготовки и сдачи вы не только получаете сертификат, который вписывается в резюме и вставляется в профиль на LinkedIn, но и получаете систематизированные знания про то, как выглядит идеальный Scrum. Приготовьтесь к тому, что реальность чаще всего далека от этого эталона, однако теперь у вас будут и ориентир, и ответы на многочисленные вопросы «почему и зачем?».

Как сделать скрам-процесс успешным?

О чем следует помнить, когда только начинаете использовать эту методику?

1. Определите приоритеты в очереди задач

Первым делом нужно понять, какая задача является самой важной. Это значит, что владелец продукта должен составить список целей, которые нужно достичь, и задач, являющихся приоритетными

После этого скрам-мастер помогает команде обменяться идеями о том, что нужно сделать для достижения этих целей и сколько для этого требуется ресурсов (времени, труда, бюджета). Далее владелец продукта определяет, каким будет простейший работающий продукт — что необходимо сделать, а что нет. После чего команда решает, какую часть этих задач можно успеть сделать к концу спринта

Это значит, что владелец продукта должен составить список целей, которые нужно достичь, и задач, являющихся приоритетными. После этого скрам-мастер помогает команде обменяться идеями о том, что нужно сделать для достижения этих целей и сколько для этого требуется ресурсов (времени, труда, бюджета). Далее владелец продукта определяет, каким будет простейший работающий продукт — что необходимо сделать, а что нет. После чего команда решает, какую часть этих задач можно успеть сделать к концу спринта.

Сет Мессер, старший разработчик компании Vecteezy, объясняет, почему этот процесс так важен для определения пути к поставленной цели: «У разработчиков есть ограничение по времени (то есть мы должны сделать ту или иную задачу в поставленных временных рамках). Это означает, что мы знаем, что нам нужно сделать, и хотим, чтобы это было сделано к определенному моменту. К примеру, к февралю 2018 года нам нужна новая версия сайта. Начать работу — дело несложное, и мы знаем, что должны получить на выходе (например, новый сайт), но все, что лежит между этими двумя точками, покрыто мраком. Какую именно работу нужно выполнить и в какой момент?»

2. Летучки должны быть краткими и действенными

Ежедневные совещания-летучки — краеугольный камень скрам-процесса, так как они позволяют команде обсудить общие проблемы и совместными усилиями их устранить. Они должны занимать не больше 10-15 минут в зависимости от размеров команды. И хотя совещания — привычный элемент делового мира, к летучкам новая скрам-команда, возможно, привыкнет не сразу.

Гэвин Вудс, сертифицированный скрам-мастер из SCRUM Alliance, руководит проектами по цифровой трансформации для клиентов компании PITSS из различных отраслей. Он признает, что проводить летучки придется учиться. «Честно говоря, — говорит, он, — в некоторых компаниях внедрение скрама может очень сильно изменить привычные подходы к работе. Людям приходится больше рассказывать о том, что они делают и с какими трудностями сталкиваются, и решать проблемы сообща. Не каждому это дается легко».

«Когда вы только начинаете использовать скрам, скрам-мастеру приходится приучать сотрудников открыто, но коротко рассказывать о своей работе, — говорит Вудс. — Для этого мастерам необходимо действовать очень прямолинейно и иногда давить на людей, чтобы все участники команды поняли, что от них требуется».

Чтобы летучки были короткими, их проводят стоя, и это лишний раз мотивирует выступающих не лить воду. В конце каждый участник команды должен дать ответ на три вопроса:

• Чего я добился?
• Чем я занят в настоящий момент?
• С чем я испытываю затруднения? / В чем мне нужна помощь?

Если какой-либо момент невозможно объяснить в двух словах, его следует перенести на следующее совещание. Если задача не касается остальных членов команды, ее можно упомянуть лишь вскользь.

Летучки помогают озвучить проблему, как только вы с ней столкнетесь

Поэтому крайне важно открыто говорить о том, что вам нужна помощь команды в том или ином деле. Чтобы сократить время летучек, по максимуму используйте систему управления проектами для обменя информацией по текущему статусу работы, оставляя для устного обсуждения лишь самые проблемные моменты

3. Записывайте сделанные выводы

Не забывайте проводить ретроспективу в конце каждого спринта. Обычно ретроспектива — это часовое совещание, на котором команда разбирает, какие успехи были достигнуты, какие уроки усвоены и что стоило бы улучшить для будущих спринтов.

Заносите сделанные выводы в базу знаний и обеспечьте свободный доступ к ним для всех членов команды. И не давайте негативным аспектам работы заслонить успехи вашей команды.

«Важно не нарушить баланс между тем, что не удалось, и тем, что прошло гладко, — говорит Вудс. — Позитивный настрой способствует творчеству»

Критерии готовности

Скрам пыта­ет­ся решить одну из самых горь­ких про­блем раз­ра­бот­ки: «Заказ­чик хотел одно, мы это сде­ла­ли, а ока­за­лось, что он хотел дру­гое». В этот момент у раз­ра­бот­чи­ков, дизай­не­ров и всех осталь­ных долж­ны наво­ра­чи­вать­ся слё­зы. 

Скрам пыта­ет­ся решить эту про­бле­му, про­пи­сы­вая кри­те­рии готов­но­сти зада­чи. Заказ­чик и скрам-мастер долж­ны поста­рать­ся чёт­ко опи­сать виде­ние резуль­та­та: на что он дол­жен быть похож, как рабо­тать и т. д. 

Но это всё в тео­рии и в иде­аль­ном мире. В реаль­но­сти заказ­чик всё рав­но ска­жет: «Да, я напи­сал, но сей­час ситу­а­ция изме­ни­лась и нуж­но сде­лать по-другому». 

Критика SCRUM

Скрам кри­ти­ку­ют за излиш­нюю риту­аль­ность: вме­сто того что­бы спо­кой­но рабо­тать и делать задач­ки, люди сидят на встре­чах и зани­ма­ют­ся ретро­спек­тив­ным ана­ли­зом соб­ствен­ной дея­тель­но­сти. 

Скрам кри­ти­ку­ют за мод­ность: все его пыта­ют­ся внед­рить, не вез­де умест­но и не вез­де пра­виль­но. Резуль­тат лег­ко пред­ста­вить. 

Скрам кри­ти­ку­ют за то, что полу­ча­ет­ся, когда его внед­ря­ют негра­мот­ные управ­лен­цы. Когда риту­а­лы заме­ща­ют полез­ную рабо­ту, это дей­стви­тель­но печаль­но.

Но здесь надо пони­мать, что кри­ти­ка скра­ма — это в первую оче­редь кри­ти­ка пло­хой реа­ли­за­ции скра­ма и людей, кото­рые неумест­но его исполь­зу­ют. Донт блейм зе гейм, блейм зе плейа.

Что там с чебуреком?

В иде­аль­ном мире про­шло пять недель, и наши бой­цы сде­ла­ли супер­че­бу­рек, кото­рый без вопро­сов был при­нят руко­во­ди­те­лем и скрам-мастером. Пре­зен­та­ция чебу­ре­ка раз­ле­те­лась по всем СМИ, тыся­чи людей вста­ли в оче­редь на пред­за­каз, а чебу­реч­ная вышла на IPO.

В реаль­но­сти фаун­дер чебу­реч­ной купил ино­мар­ку, попал на ней в ава­рию, инве­сто­ры отка­за­лись финан­си­ро­вать про­ект, коман­да забра­ла нара­бот­ки и раз­бе­жа­лись кто куда: кто-то в круп­ные ком­па­нии, дру­гие — в стар­та­пы, тре­тьи бро­си­ли эту айтиш­ную жизнь и пере­еха­ли в село.

Пото­му что жизнь слож­нее, чем пред­став­ле­ния скрам-мастера о ней. 

Что дальше

Скрам — это гиб­кая мето­ди­ка, прин­ци­пы кото­рой под­хо­дят под раз­ные про­ек­ты, будь это ИТ-компания или чебу­реч­ная. В ста­тье мы рас­смот­ре­ли общие поло­же­ния, и для погру­же­ния в тему реко­мен­ду­ем сле­ду­ю­щие ресур­сы:

• Scrum.org — это сооб­ще­ство скрам-тренеров, кото­рые делят­ся кон­тен­том и пред­ла­га­ют кур­сы по скрам-подготовке. 
• Scrumalliance.org — ещё одно круп­ное сооб­ще­ство с бес­плат­ны­ми мате­ри­а­ла­ми, кур­са­ми для сер­ти­фи­ци­ро­ван­ных спе­ци­а­ли­стов и скрам-конференциями по все­му миру. 

Допол­ни­тель­но посмот­ри­те интер­вью Пав­ла Сви­ри­до­ва, кото­рый руко­во­дит бэкенд-разработкой и обра­ща­ет­ся с кол­ле­га­ми как насто­я­щий скрам-мастер.

Текст и чебу­ре­ки:Алек­сандр Бабас­кин
Редак­тор:Мак­сим Илья­хов
Кор­рек­ту­ра:Ира Михе­е­ва
Иллю­стра­тор:Даня Бер­ков­ский
Вёрст­ка:Маша Дро­но­ва
Соц­се­ти:Олег Веш­кур­цев

Определение

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта.Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы

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

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются  результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.

Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

Для визуализации agile-подходов используют доски: физические и электронные

Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя. 

Как стать скрам-мастером?

Мой путь к скраму сложно назвать прямым. В детстве меня увлекали иностранные языки. Помню, как бабушка мне рассказывала про сына маминой подруги, который сходу может понять, о чем поется в песне на иностранном языке. Я тогда думала, что это невероятно, и тоже так хотела, поэтому мечтала стать переводчиком. В каком-то смысле я им и стала, потому что большинство проектов я вела на английском языке, а еще – в работе постоянно приходилось переводить с технического на бизнес-язык и обратно.

Параллельно с учебой я работала в Лаборатории роста кристаллов Института неорганической химии (ИНХ СО РАН) в новосибирском Академгородке. Там я занималась внешнеэкономической деятельностью, взаимодействовала с иностранными клиентами. Но когда учеба закончилась, я всерьез задумалась, чем заниматься дальше.

Постоянно мониторила рынок труда и обратила внимание, что в сфере ИТ появилось много вакансий менеджеров проектов. Уже тогда я понимала, что за ИТ будущее, и решила попробовать

После пяти лет работы почувствовала, что пора переходить на гибкие методологии разработки в силу специфики моих текущих проектов. Так из менеджера проектов я стала скрам-мастером.

Теперь точно могу сказать, что нужно не бояться пробовать работать в разных сферах и в разных ролях. Только так можно найти то, что действительно по душе.

В СИБУРе несколько лет назад стартовала цифровизация и появилось много новых ролей. Когда мне предложили пройти собеседование в сфере нефтехимии, я удивилась, потому что скрам-мастеров обычно ищут компании, разрабатывающие программное обеспечение. А какая в нефтехимии разработка ПО? Пообщавшись с командами, я узнала про множество цифровых продуктов собственной разработки, которые СИБУР делает в рамках цифровизации.

У промышленности своя специфика. Здесь я взаимодействую не только с командой разработки, но и с владельцами процессов – они работают непосредственно на производствах и полностью погружены в то, что мы оцифровываем. Еще одна особенность в том, что ИТ-компании часто производят продукты для внешних заказчиков. Ты отдаешь его клиенту и часто не знаешь его дальнейшую судьбу. А в СИБУРе пользователи — вот они, рядом. К ним можно съездить на производство, поговорить, потом посмотреть, как продукт внедряется и работает в реальных условиях и сразу получить обратную связь.

Я, например, начала разбираться в ИТ на работе, и отсутствие «корочки» по ИТ-специальности мне не мешает: важно находить общий язык с командой, а все необходимое узнаешь в процессе работы. А вот без базовых знаний agile, разумеется, не обойтись

Здесь пригодится информация из разных источников: скрам-гайд, статьи, книги про agile. Не менее важно общаться с практиками — посещать открытые митапы, где встречаются специалисты, практикующие гибкие методологии. Там можно узнать, как они внедряются в разных компаниях, какие методологии используются, какие бывают проблемы и необычные кейсы. Это поможет быть в тренде и развивать свои компетенции, а еще – это полезный нетворкинг

А вот без базовых знаний agile, разумеется, не обойтись. Здесь пригодится информация из разных источников: скрам-гайд, статьи, книги про agile

Не менее важно общаться с практиками — посещать открытые митапы, где встречаются специалисты, практикующие гибкие методологии. Там можно узнать, как они внедряются в разных компаниях, какие методологии используются, какие бывают проблемы и необычные кейсы. Это поможет быть в тренде и развивать свои компетенции, а еще – это полезный нетворкинг

Приложения

Работа над скрам-проектами ведется в специальных приложениях и программах. Многофункциональный интерфейс позволяет следить за ходом работы по проекту с разных ракурсов.

Worksection

Простой интуитивно понятный сервис для работы над проектами и решения различных задач бизнеса.

Worksection сейчас дорабатывает и тестирует перед внедрением (на октябрь 2017) фишки для scrum: диаграммы сгорания задач и бэклог — чисто скрамовские инструменты. Возможно будет и покер планирования. Наш консультант в этом деле, , предпочитает свою колоду для скрам-покера — с Бэтменом.

Уже сейчас в Worksection можно:

• Вести задачи и подзадачи в проектах, контролировать динамику их выполнения.
• Вносить затраченное время и деньги, наблюдать расходы относительно запланированных в бюджет прямо в системе.
• Бэклог продукта и бэклоги спринтов создавать как отдельные проекты, между которыми можно перемещать задачи.
• Участники команды общаются по задачам прямо в Worksection — вся информация, замечания и прогресс на виду. Есть комментарии и эмоции, метки, приоритеты и статусы задач.
• Плюс несколько форматов отчетности — по срокам, по нагрузке и людям, по деньгам, по проектам — позволяет сделать качественную ретроспективу.
• Быть постоянно на связи с командой, благодаря мобильной версии.

Чисто скрамовский с планированием итераций, покером, карточками-задач. В остальном стандартный пакет функций с отчетами, диаграммами и гистограммами.

Сертификат Scrum-мастера

Это самый очевидный формальный признак того, что соискатель как минимум знает основные ценности Agile и принципы работы по Scrum. Особую ценность имеют сертификаты двух организаций: Scrum.org и Scrum Alliance, их создали основатели Scrum. 

Экзамен в Scrum.org — сложный, он состоит из 80 вопросов и правильно ответить надо минимум на 85%. Одна попытка сдачи экзамена стоит $150, и это только первый экзамен. Всего их три, а каждый следующий сложнее и дороже. 

Scrum Alliance выдает сертификаты только тем, кто прошел их тренинги. В России эти тренинги читает всего один тренер — Сергей Дмитриев, основатель Unusual Concepts. Если у соискателя есть сертификат от Scrum Alliance, это означает, что он настолько заинтересован, что сумел попасть на редкие тренинги или ездил учиться к тренерам в Америку или Европу.

Разработка

Ассайнить

assignпоручатьПримеры употребления:

• «Заасайнь эту таску на кого-нибудь из бэкэнда»
• «Так не было у таски асайни»
• «Я заасайню на себя»

Бага

bugжукПримеры употребления:

• «Мы так и не разобрались с той багой»
• «Я нашла там одну багулю, посмотри, пожалуйста»
• «Мы можем взять задачу с той багой в этот спринт?»

Грумить

groomчиститьПримеры употребления:

• «Сегодня планирую погрумить бэклог»
• «Когда я уже разгрумлю эту кучу задач»
• «Осталось немного причесать код и ревью закончим»

Деплой

deployразворачиватьПримеры употребления:

• «Кто сегодня деплойный дежурный?»
• «Завтра деплоим очень важную задачу»
• «Таска ушла в деплой»

Компилить

compileсоставлятьПримеры употребления:

• «Проект не компилится что-то»
• «А стили у компонента скомпилились?»
• «Надо запустить сборку, чтобы скомпилить твои изменения»

Костыль

Примеры употребления:

• «Я могу быстро пофиксить, но решение будет костыльным»
• «Ох и накостыляли вы тут»
• «Мы можем удалить этот костыль?»

Лагать

lagотставаниеПримеры употребления:

• «У меня всё жутко лагает»
• «Комп конечно у меня лаговый, но не в этом дело»
• «Ты можешь стабильно воспроизвести эти лаги?»

Легаси

legacyнаследиеПримеры употребления:

• «Ох, там надо копаться в легаси»
• «Код нужно рефакторить, потому что там слишком много легаси»
• «А чего вы хотите от легаси?»

Мерджить

mergeслияниеПримеры употребления:

• «Я померджу ветки вручную»
• «При мердже произошли конфликты, можешь порешать?»
• «Ветку вымерджили из сегодняшнего деплоя»

Нативный

nativeроднойПримеры употребления:

• «Это нативное поведение компонента»
• «Нужно перебить нативные стили кнопки»
• «Поменяй сортировку, вначале идут нативные атрибуты»

Стоимость задачи

Примеры употребления:

• «Сколько нам будет стоить сделать этот функционал с нуля?»
• «Это очень дешево, можно сделать прямо сейчас»
• «Слишком дорогое решение, пока не будем за него браться»

Фейлить

failнеудачаПримеры употребления:

• «Мы в этом спринте зафейлили все три цели»
• «Это будет полный фейл, если мы не успеем к деплою»
• «Виноват, из-за меня мы фейлим план»

Фикс

fixчинитьПримеры употребления:

• «Пофикси, пожалуйста, это в первую очередь»
• «Не самый надежный фикс, но на первое время проблему решает»
• «У нас все баги пофикшены?»

Идеальные пропорции тела мужчины — таблица!

О важности scrum-команды

Scrum-команда — это чаще всего группа из пяти-девяти человек. Это оптимальное количество, но иногда встречаются команды и из трех человек. Если людей больше, то им становится сложнее взаимодействовать между собой, что мешает работе и снижает продуктивность.

Состав команды

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

Scrum-мастер. Чаще всего — специально нанятый сотрудник, который ведет команду к результату. Он не управляет командой, но наблюдает за исполнением основных принципов Scrum. Его задача — не давить, не делать всю работу самому и не распределять обязанности, но помогать, направлять и решать вопросы, которые тормозят процесс разработки.

Разработчики. В составе scrum-команды всегда есть люди с разным набором навыков. Так, команда из пяти-девяти человек ведет весь проект от начала до конца. Одна команда — один готовый продукт.

Как выглядит scrum-команда

Эффективный метод планирования SCRUM для мам

Не вдаваясь в тонкости, разберем основные термины и правила SCRUM и попробуем адаптировать эти методы планирования  для мам. Итак, методика SCRUM включает в себя следующие пункты:

1. Определить конечный продукт или цель. Например, у нас это может быть генеральная уборка, разбивка сада, дела на месяц.

2. Собрать команду. Ну, мы мамы сами себе команда, как говорится: “и чтец, и жнец, и на дуде игрец”. Также можно включить сюда мужа и детей, если они согласны.

3. Назначается “скрам-мастер”, который будет следить за ходом процесса, руководить и помогать участникам. Эта должность опять целиком и полностью наша — мамина. Следует учесть, самодисциплина и высокая мотивация крайне важны при игре в одного участника. Отсутствие подотчетности повышает риск все забросить.

4. В начале работы создается максимально полный список дел. В SCRUM методике  он называется “Беклог”. Ну, со списками, у нас, мам, проблем нет, задач и дел преогромное количество. Можно просто выписать все, что приходит в голову. Можно сгруппировать задачи или цели по темам или другим критериям.

5

Далее, участники команды проводят оценку всех задач по сложности, наличии ресурсов для выполнения  и важности для конечного результата, т.е. расставляем приоритеты

Мы тоже так поступим, причем оценка задачи в SCRUM определяется не по 10-ти бальной шкале, как обычно, а каждое последующее число увеличивается в геометрической прогрессии. Довольно наглядно видно разницу. Например, дела на неделю:

погладить белье -1 балл (ну не успеем ничего страшного не случиться);

поставить ребенку прививку в поликлинике -27 баллов (из всех перечисленных дел явно самое важное);

купить продукты — 9 баллов (без ужина семью не оставишь);

пересадить цветы — 3 балла (тоже может подождать).

Если бы мы просто пронумеровали эти дела, (1,2,3,4) приоритетное дело не было бы так заметно. В SCRUM команда стремится набрать дела с наибольшим количеством баллов. Причем с каждым разом сумма баллов должна повышаться, что способствует, в свою очередь, повышению продуктивности. Фриланс в декретном отпуске — шаг в новую жизнь

6. Затем, все участники команды планируют “спринт” — определенный промежуток времени, в течение которого должна быть выполнена выбранная из списка часть задач. “Спринт” может быть различным по продолжительности, но не должен быть дольше 1 месяца.

Для мам определение временного отрезка зависит от конечной цели. Может быть, вы возьмете неделю, десять дней, месяц.

Ваша задача — за время спринта сделать наиболее приоритетные дела, которые вы выберете.

7. В методике SCRUM для наглядности движения работы и отслеживания результатов используют скрам-доски с тремя колонками:

“Беклог” (вообще все задачи, которые у вас “висят”),“в работе” (те задачи, которые вы выбираете для выполнения на время спринта),“сделано”.

Все выбранные для спринта задачи из “беклога” пишутся на стикерах и помещаются в колонку “в работе”, затем, после выполнения задачи, стикер переносится в колонку “сделано”. Нельзя браться за новое дело, не закончив предыдущее. Таким образом, сразу всем видно положение дел на данный момент.

Если вы работаете командой (то есть муж и дети согласны поучатвовать в таком методе планирования), то каждый выбирает себе задачу по вкусу и выполняет ее, затем берется за следующую. Скрам-доски — это аналоги канбан-досок и командных центров. Это удобно, наглядно, азартно и неплохо мотивирует.

8. Правила SCRUM включают ежедневные совещания — 15 минутки, на которых каждый участник рассказывает, что делал вчера и что будет делать сегодня.

Мамы утром, ежедневно и самостоятельно, проводят сверку планов на сегодня и корректировку их, при необходимости. А также в течение дня при возникновении непредвиденных обстоятельств.

9.  По завершении спринта команда проводит демонстрацию результатов, а также проводится разбор полетов с выявлением плюсов и минусов в проведенной работе.

Чтобы стать продуктивнее и быть более организованной, качественно двигаться к цели, необходимо анализировать и отслеживать результаты своей работы. Даже если это домашняя рутина. Только увидев, что вы делаете не так, можно исправить ситуацию и не наступать на одни и те же грабли. Многие мамы пренебрегают этим пунктом, а зря. Анализ своей деятельности, к тому же чудесно мотивирует на дальнейшие “подвиги”. Подарки своими руками — 10 способов занятий вместе с детьми

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story)

Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager:

ID	User Story
a-001	Как менеджер, я хочу добавлять, удалять, редактировать задачи, чтобы управлять занятостью сотрудников
a-002	Как менеджер, я хочу добавлять новые задачи и изменять продолжительность, а также конечную и начальную даты текущих задач с помощью drag-and-drop
a-003	Как менеджер, я хочу назначать сотрудникам 2 типа задач: -Part-time task -Full-time task чтобы обозначить постоянную/временную занятость сотрудника

Описание каждой истории должно включать в себя набор обязательных полей, необходимых для дальнейшей работы над проектом:

Важность (Importance). Степень важности задачи по мнению владельца продукта

Описывается произвольным числом.

Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах.

Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи.

Помимо этих обязательных полей, при необходимости могут быть добавлены дополнительные:

• Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
• Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
• Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
• ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Телевидение