Закрыть
E-mail:
Пароль:
Забыли пароль?
В каталоге проекта: 14 618 веб-студий, 990 CMS, 266 778 сайтов.
РегистрацияCMS MagazineВход
CMS Magazine CMS Magazine

Сибирикс PM Book: глава 3, разработка

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

Ниже представлена 3-я глава — чек-лист по этапу программирования.

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

Дисклеймер

Глава переведена «как есть». Именно с нашими терминами и процедурными заморочками. Встречается ненормативная лексика. Не много, но если мат чужого человека для вас неприемлем, — это чтиво вам не подойдет.

Последнее китайское

18+. Книга — ругательная.


 

СИБИРИКС PMBook v0.6 (2015.1.09)

КОНФИДЕНЦИАЛЬНО. НЕ КОПИРОВАТЬ. НЕ ВЫНОСИТЬ ИЗ ОФИСА


3.1 Разработка::Подготовка спринта

 

  • Техническое задание (если есть) разбито на фичи, фичи — помещены в backlog (список фич по приоритетам).

  • Список фич/историй сформирован полностью на этап

  • Backlog — храним в таблице Google Docs. Доступен команде. Редактирует менеджер. Отсортирован по приоритету

 

ПРИОРИТЕТ

ФИЧА/User Story

КРИТЕРИИ ПРИЕМКИ / ПРИМЕЧАНИЯ

...

Уникальное
число

Фичи, а не задачи

Тесткейсы

 

  • Фичи отсортированы по приоритету.

  • Тесткейсы понятны, полезны и охватывают максимальное количество классических и экстремальных случаев! Можно привлекать QA-специалиста. В крайнем случае можно написать кейсы после планинга.


  • Менеджер четко понимает все фичи бэклога. Не только “что надо сделать”, но и “как это будет выглядеть и работать”.


  • Спринты — 1-2 недели в зависимости от опыта команды.

  • Новых задач после планинга в спринт не брать.

 


1


3.2 Разработка::Планирование

  • Создать чат команды по проекту.

  • Назначить время и место для проведения планинга. Оценки делать ВСЕЙ командой.

  • Длительность планинга порядка 90 минут.

  • Уведомить команду о времени и месте. Обеспечить явку.

  • Заблаговременно до планинга дать команде изучить бэклог и ТЗ (только те фичи, которые войдут в спринт). Выяснить все неясные вопросы.

    • Убедиться, что команда прочитала ТЗ.

    • Убедится, что команда ПОНИМАЕТ ТЗ (задает вопросы).

    • Дать время на планирование архитектуры. (В очень сложных проектах вынести архитектуру на отдельный этап


    • Архитектуру делает один человек


  • Собрать команду на планинг, с выключенными телефонами.

  • Создать спринт внутри проекта.

  • Последовательно читать фичи. Разбивать на технические задачи.


  • Задачи ставить в SCRUMBAN в однозначной формулировке. Четко. Ясно. Выполнимо.


    • Техническая реализация. Должна быть понятна всем и принята однозначно!

    • Критерии приемки.

      • Запланировать QA на написание тест-кейсов.

 


2


  • Если есть ТЗ — КАЖДОЕ слово понимать,
    подкрашивать маркером, копировать текст в SCRUMBAN.

  • Оценить с помощью Planning Poker поставленную задачу:

    • Сроки не зажимать.

    • Укладываться в бюджет с резервом.

    • в SCRUMBAN писать оценку, которую дала команда.

  • Назначить End Date (закончен код) и Release Date (сдача этапа):

    • Сообщить команде.

    • Проставить в SCRUMBAN.

    • Укладываться в бюджет.

    • Закладывать буферы времени, относительно оценок.

  • Спланировать работу на сегодня.

  • Назначить время и место стэндапов.

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

  • В календарь компании ставим продолжительность этапа с учетом резерва на тестирование и рисков на сложность задачи и скорость работы команды.

  • Вместе с одним из членов команды и QA подготовить приемочные тесты/критерии приемки/тест-кейсы.

 


3


3.3 Разработка::Standup

  • РИТМ: Проводить в одно и тоже время в одном и том же месте.

  • За 5-10 минут попросить в чате проекта обновить статусы задач и запланировать работу на сегодня.

 

  • Собрать команду. На один монитор вывести проект, на второй - канбан спринта.

  • Последовательно каждому члену команды задать три вопроса. Соблюдать очередность.

    • Что было сделано вчера?

    • Что будет сделано сегодня?

    • Какие есть проблемы?

  • В дискуссии не вступать. Параллельные потоки пресекать!

  • Технические темы выносить за рамки Standup.

  • Не более 3-х минут на человека.

  • Требовать рассказывать своими словами об изменениях в системе, а не о номерах задач.

  • Настаивать на демо готовых фич на экране; Пусть покажут пальцем, что готово. И чтоб было понятно. Не вестись на “абстракции” в коде.

 


4


3.4 Разработка::Ежедневная работа

  • Разработчикам — сразу после завершения задачи проверять и отмечать тесткейсы. PM — обеспечить это!

  • Еженедельно отправлять клиенту отчет о ходе работ.

  • По договоренности — дать доступ к баглистам/backlog/scrumban (на чтение!)

  • Управлять ожиданиями.

  • На КРУПНЫХ проектах архитектуру баз данных и инфоблоков делать заранее и проверять руководителем

  • Напоминать команде, что главное — качественный (ахуенный) проект.

  • Периодически просматривать систему.

  • Как можно раньше внести тестовый контент, максимально приближенный к реальному

  • Устранять "затыки" у команды, решать открытые вопросы.

  • Обеспечивать дизайном, версткой, помогать команде.

  • Следить за аномалиями. Не ссать ЭСКАЛИРОВАТЬ! Не врать и не бояться ;)

 


5


3.5 Разработка::Тестирование

 

  • В начале спринта составить с разработчиком и QA тест-кейсы на каждую задачу.

  • QA готовит чеклисты из типовых чеклистов, для проверки каждого соответствующего элемента и размещает их на отдельной вкладке в google doc, предназначенной для публикации баглистов.

  • При необходимости ДО тестирования провести code review и правку по code review (На не сработавшихся командах проводить 1 раз в спринт или чаще. На опытных — раз в 2-3 спринта).

  • Первая проверка — QA и разработчик совместно:

    • следить, чтобы разработчики реально тестировали (а не сразу фиксили баги, как находили). Тест разработчиками означает, что они проверили и формально покрасили чеклисты, подготовленные QA.

    • отсматривать формальное выполнение тест-кейсов.

    • разработчики проходят по чеклистам, реально проверяют каждый тесткейс и красят его. Именно это означает, что “разработчик за собой проверил”.

  • Результат тестирования — в таблицу Google Docs, в тот же файл, где лежит backlog, или карточками в SCRUMBAN.

    • Прислать ссылку на багрепорт (на чтение) — заказчику с уведомлением о старте тестирования. Это снимет с тебя вопросы “вы плохо тестировали”.

  • Отсортировать результаты теста по группам:

0 — Критические баги.

1 — Критичное Usability, забытые фичи.

2 — Некритичные баги.

 


6


3 — Некритичное Usability.

4 — Тексты.

8 — Хотелки, не будем делать.

  • Если багов много — организовать работу (канбан).

    • Пусть команда проставит оценки багов.

    • Показывать программистам за раз — только часть багов (не более 2-х экранов, самые приоритетные)

    • Ежедневно удалять на отдельный, недос.тупный для программистов лист — пофиксенные и проверенные баги

    • Новые найденные баги заносить на отдельную вкладку

    • После завершения работы над одной вкладкой — просить программ.истов проверить систему полностью. Время не зажимать

    • К найденным ими багам добавлять свои.

    • Обеспечить итеративность.

  • Внести реальный контент.

  • Протестировать проект лично. В сложных случаях — включая админку.

  • Провести тестирование внешним менеджером.

    • Показать проект дизайнеру, рисовавшему проект.

    • Показать проект артдиректору.

    • Показать проект Вове.

В случае реальной угрозы протрахаться с багфиксом менеджер обязан 1. получить оценку багфикса, 2. выстроить приоритеты и контрольные точки, 3. декомпозировать большие задачи, 4. оперативно отвечать на возникающие вопросы, 5. своевременно информировать о затыках, 6. привлекать (по согласованию) других разработчиков на помощь в решении проблем.

 


7


3.6 Разработка::Демонстрация

  • Согласовать время разговора за 1 день до сдачи.

  • За 1 час до сдачи — удостовериться, что все в силе.

  • Демо проводить совместно с командой. Каждый должен чувствовать свою ответственность и причастность. Если это неприемлемо — согласовать с Вовой.

    • Использовать видео-канал.

  • Обязательно показывать и рассказывать голосом.

  • Если канал позволяет — показывать сайт со своего экрана по skype.

  • Подготовить и настроить клиента на позитив и принятие проекта.

  • Рассказать что команда проделала много работы, вкратце перечислить, что именно.

  • Дать ссылку на проект.

  • Пройти по всем основным меню, рассказать, как было сделано и почему.

    • Обосновать принятые решения.

  • Получать обратную связь. Фиксировать предложения. Закончить на позитиве.

  • Законспектировать разговор.

  • Незамедлительно отправить callreport (cc Вове)

 



8


  • Если обнаружат мелкие баги на демо — устранить незамедлительно и тут же сдать, не передавая команду на другой проект и до проведения ретроспективы.

  • ПРЕВОСХОДИТЬ ОЖИДАНИЯ! Стараться сделать клиенту небольшой бонус (больше чем обещали). Например,

    • Уложиться раньше срока

    • Сделать пару дополнительных фич

    • Добавить пару фишек

    • Внести контент


Акцентировать внимание клиента на том, что это было сделано бесплатно, как подарок.

Отметить это же в коллрепорте.

  • Отжать акт и постоплату (если есть).

  • Назначить время для проведения планирования с клиентом следующей итерации.

 


9


3.7 Разработка::Ретроспектива

  • Проводить сразу после завершения спринта (до погружения команды в другой проект. Может быть даже ДО ДЕМО).

  • Назначить время. Согласовать с командой.

  • Попросить команду заранее повспоминать плюсы и минусы этапа.

  • Собраться без лишних ушей.

  • Настроить команду на конструктив. Привет. Как дела?


Цель: улучшить наши процессы. Напомни ее в самом начале!


  • Последовательно каждого члена команды спрашивать о плюсах и минусах этапа.

  • В споры не вступать. Модерировать. Параллельные потоки закрывать.

  • Плюсы, минусы и идеи — записывать на стикерах, вывешивать по 4-м квадрантам (+-*/)

  • Проанализировать минусы. Сформировать идеи по их решению (любые).

  • В случае сложных проблем — использовать rootcause-анализ.

  • СТАРАТЬСЯ ВЫЯВИТЬ
    ПРОБЛЕМЫ. НЕ ССАТЬ!

 


10


  • Идеи не оспаривать.

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

  • Назначить ответственных по каждому пункту.

  • После ретроспективы задачи поставить в SCRUMBAN в проект RETRO или следующий спринт на исполнителей. Стикеры вернуть на доску:

    • Основная задача содержит дату ретроспективы.

    • Принятые решения содержать — помещены в подзадачи.

    • Запланировать с Вовой в Google Calendar время на выполнения решений по ретроспективам.

    • По возможности сделать задачи с ретроспективы
      до начала следующего спринта или включить их в спринт.

 


11


 

Комментарии (Facebook)

Рекомендуем:


CMS Magazine CMS Magazine
Реклама
RSS-подписка
CMS Magazine CMS Magazine
CMS Magazine