Прошло уже 8 месяцев(совпадение с прошлой статьей) с тех пор, как мы в KAD::Systems начали работу по скрам. В работе 32-ой спринт, и вот что изменилось с момента написания прошлой статьи http://artemkuts.ru/all/scrum/

1. Кросс-продуктовые спринты. Т. к. по разным продуктам появляются срочные проблемы, а скрам команда всего одна, то откладывать их на 1-3 недели просто недопустимо. Кросс-продуктовые спринты позволили работать по нескольким продуктам в рамках одного спринта. Для этого мы создали отдельную доску с названием Спринт, а из досок приложений убрали списки для работы над спринтом. В начале каждого спринта на доску Спринт в список Задачи помещаются карточки из разных приложений, заполняются поля: приложение, оценка, приоритет, спринт, версия. По завершению работы над спринтом, карточки возвращаются на доски приложений.

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

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

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

5. Сортировка карточек. После подготовки спринта скрам-мастером и командой, владелец продукта сортирует карточки спринта. После этого скрам-мастер проставляет числовые значения приоритетов для каждой карточки. Если в ходе спринта появляются карточки поддержки, то сортируются они по следующим правилам. Приоритеты среди таких карточек указываются менее 1 в порядке возрастания. Чем меньше число, тем приоритетнее карточка. Например: 0.1, 0.2, 0.15. Самая приоритетная карточка будет с номером — 0.1. Приоритезация карточек поддержки выполняется по следующим правилам:

• 1. Приоритезация карточек поддержки по категориям:
• 1.1. Ошибка, полностью ограничивающая работу магазина клиента
• 1.2. Ошибка, частично ограничивающая работу магазина клиента
• 1.3. Ошибка, полностью ограничивающая работу приложения
• 1.4. Ошибка, частично ограничивающая работу приложения
• 1.5. Ошибка, не ограничивающая работу приложения
• 2. Приоритезация карточек поддержки по типу проблемы:
• 2.1. Общий случай
• 2.2. Частный случай
• 3. Приоритезация карточек поддержки по типу клиентов:
• 3.1. Оставил негативный отзыв
• 3.2. Есть основания полагать, что клиент является угрозой негативного отзыва
• 3.3. Возмущен
• 3.4. Взволнован
• 3.5. Спокоен
• 4. Приоритезация карточек поддержки одной категории, одного типа проблемы и одного типа клиентов:
• 4.1. Осуществляется по очереди — кто раньше сообщил, тот раньше получит решение

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

Надеюсь наш опыт будет кому-то полезен. Задавайте вопросы, отвечу на все.

Один из первых моих сотрудников Борис Козуб переехал в Москву в компанию Agima и устроился там тимлидом. Искренне порадовался за него, он очень быстро вырос профессионалом практически с нуля. Мне стало интересно что за компания. Зайдя на страницу услуг обнаружил типичный для меня (3-летней давности) стиль текстов. Скорее всего его писал технарь, возможно разработчик. Я написал бы точно также несколько лет назад. Представлю свои варианты некоторых текстов на странице услуги.

Исходная страница: https://www.agima.ru/our-capabilities/

—

Очень длинное предложение и очень сложное для понимания клиентом. Вряд ли кто-то это читает. Разбить или переписать. Мой вариант:

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

—

• Пропущена запятая после второй «и».
• Длинное предложение, разбить.

Мой вариант:

Разрабатываем функционально сложные, интеграционные и высоконагруженные проекты. Особенно круто у нас получаются back-office приложения, b2b и корпоративные порталы, интегрированные со внутренними учетными системами.

—

Мой вариант:

AGIMA — партнер 1С-Битрикс по крупным корпоративным внедрениям. Наши технические специалисты имеют сертификаты 1С-Битрикс и ASP.NET. Выделенный отдел 24х7 позволяет обеспечить 100% отказоустойчивость.

—

Дважды повторяется «часто». О каком конкретном случае здесь идет речь и почему он важен не понятно ¯\_(ツ)_/¯

Делимся знаниями в публикациях, на конференциях и мастер-классах, а еще разбираем частные случаи.

Мои варианты получились довольно сухие, я постарался убрать все лишнее. Можно разбавить эпитетами, например, «а еще с увлечением разбираем частные случаи».

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

В сентябре запустили первый спринт, выбрав трелло как канбан доску. Срок спринта — 1 неделя. Первый спринт не завершили, но общие впечатления остались положительные. Главное преимущество — сделали больше. Детальнее: 

• Ограничение сроков неделями. Сначала каждая карточка имела свой срок, на управление которым нужны были отдельные усилия. 
• Оценка карточек целой командой. Оценка становится объективнее и интереснее.
• Командная работа. Ряд процессов в скраме делается всей командой, что для нас очень важно. Мы привыкли работать по одиночке, но так не создать крутой продукт.

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

1. Много продуктов — команда одна. Решение — чередуем спринты по продуктам в порядке приоритетов. Приоритеты назначаю я. 
2. Не успели сделать карточку, а спринт закончился. Решение — карточку зачтем в этот спринт и перенесем остаток в новую карточку. Оценим новую и из старой вычтем количество баллов новой. Бывает так, что в процессе работы карточка оказывается сложнее, чем казалась при оценке. В таком случае из старой мы не вычитаем количество баллов новой.
3. Карточка больше чем спринт. Решение — разбить карточку на части и взять работу в нескольких спринтах.
4. Неравномерная загрузка в команде. У одного много работы, у другого мало. Решение — при планировании учитывать нагрузку и брать неприоритетные карточки, если приоритетные ненагруженный сотрудник не осилит. 
5. Удаленный сотрудник. Решение — рассказать о процессах, включить в участие в оценке, объяснить важность сроков.
6. Во сколько оценивать первые карточки. Решение — зафиксировать максимальный балл наугад → определить сложность минимального балла (например, 1 балл — изменение текста) → оценить карточки первого спринта пальцем в небо → зафиксировать максимальный балл по результатам первого спринта → продолжить оценку каждый спринт улучшая точность оценки.

По поводу п.4. планируем внедрить кросс-продуктовые спринты для равномерной загрузки. В таком случае свободный сотрудник будет делать задачи по неактивным продуктам. Сейчас нас ограничивает инструмент — трелло. В первом квартале планируем перейти на Jira | Youtrack

Переняли методологию, стараясь сохранить предписанные скрамом процессы. В работе 18-ый спринт, 6 из 17 сдали в срок. В работе появился пульс, предсказуемость. Отдельно стоит сказать, что это упростило управленческие отчеты: стоимость спринта легко вычисляется, посчитать расходы на каждый продукт — легко.