Dev complete

Приходит к вам разработчик и говорит ”фича готова”. Ежели за грехом был ранее замечен, можно спросить “а покажи”. Сразу возникает вопрос – а что показывать? В этот момент будет здорово, если под рукой окажется вот такой чеклист:
- Код написан;
- Создан фича бранч;
- Разработчик сам потыкал фичу, “вроде работает”;
- У тестировщика нет препятствий, чтобы начать тестирование;

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

Когда стартуете новый проект, определите внутри команды что значит “фича готова” (разработка завершена / dev complete), да положите на вики. Добавив к нему понятие “тестирование завершено”, вы получите то, что в скраме называют Definition of Done. Придерживаясь такого списка критериев, команда дает более точные оценки, потому что лучше понимает объем работы.

Аминь!

​​Workload Pie chart


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

1. Планирования следующего спринта. Прежде чем стартануть спринт, проверьте сколько задач висит на каждом разработчике. 50 часов для двухнедельного спринта, это перебор.

2. Трекинга прогресса спринта. Принцип тот же что и в предыдущем пункте, смотрите количество часов в незакрытых тасках против остатка спринта. Эдакий аналог Burndown Chart.

3. Оперативного планирования. Если на Иакове заасайнено задач на 24 часа, а на Фоме всего 6, вероятно, какие-то таски можно перераспределить.

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

Настройка:
Filter: project = ID или имя вашего проекта AND status != closed AND Sprint in openSprints(). Сохраняете этот фильтр, в поле виджета вставляете его имя.
Statistic Type: Assignee
Time field to report on: Current Estimate

​За беклогом нужен глаз да глаз

Паузы в диалоге

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

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

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

Вариант 1: "Ты пропустил баг - это косяк, больше так не делай и заведи, наконец, чеклист".💩

Вариант 2: "Заказчик написал по поводу вчерашнего бага" пауза "расстроился, рассказал какие проблемы у них это вызвало" пауза "как думаешь, что можем сделать, чтобы в будущем не повторить?" пауза "это хорошо, а вот еще чеклист, дал бы положительный эффект?" 🔥

​"5 пороков команды"

Все всегда думали что смертных грехов 7, но Патрик Ленсиони запомнил только 5. Не спешите расстраиваться, книга заходит как кулич на Пасху. Если в вашей команде есть проблемы, то сможете найти здесь несколько толковых советов. Для поклонников принципа Парето и тех, кого в дрожь бросает от слова "бизнес-роман", последние 20% книги дают структурированную выжимку всех идей. Задумка крутая: для каждого порока описаны симптомы, последствия, методы лечения и даже связи другими пороками.
Автор выделяет следующие типичные проблемы команд, называя их пороками:

- недоверие;

- боязнь конфликта;

- безответственность;

- нетребовательность;

- безразличие к результату;

Кому-то настолько запала в душу эта книга, что он сделал вот такой слайд для тех, у кого ну совсем нет времени. Благословение автору!

Продакшн логи

“Откупоривайте шампанское - мы вышли в прод!” Все с нетерпением ждут релиза, но самое сложное впереди. Вскоре обнаружатся дотошные грешники, которые отыщут все 500-ки вашего бекенда.

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

Сервисами логирования можно отследить:
- данные пользователя (ОС, устройство, браузер, страну и т.д.);
- последовательность запросов и ответов, которые приводят к багу;

Выбор тулы лучше отдать на откуп разработчикам. Мы используем Appsignal для Ruby и Sentry для React JS и вполне довольны. Подключить благодетель займет от пары часов, до нескольких дней, в зависимости от сложности и величины проекта.

​Фидбек на ретроспективу

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

Чем лучше вы понимаете что приводит к катарсису, а что нет, тем круче будут ваши следующие миты.

​Всем хороших выходных 😉

Как уместить дизайн в спринт

Многие спрашивают, как по скраму рисовать дизайн. Челлендж в том, что разработчик не может оценить фичу, пока не увидит лэйаут. Ответ простой - рисуйте дизайн на спринт вперед. Например, сейчас у вас 8 спринт, в процессе команда готовит стори для спринта 9. Одновременно с этим, дизайнер отрисовывает интерфейсы для спринта 10. В таком варианте, в 9ом у вас уже есть утвержденный дизайн. Варьируйте гэп "дизайн-разработка" в зависимости от скорости аппрува диза заказчиком и будет вам Вальгалла.

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

- совместить аналитику и дизайн в один спринт, как совмещаете тестирование и разработку;

- сократить длительность спринтов;

- релизиться чаще;

Иногда аппрув дизайна не является частью процесса (или проходит сверхбыстро), например в продуктовых компаниях. Тогда можно делать его в том же спринте, что и разработку. Это сложно, но некоторым удается. Последние делятся секретом успеха:

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

- создайте и поддерживайте актуальным дизайн гайдлайн.

Skype не очень

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

Достойнейшей из бесплатных альтернатив является google hangouts, канонизированный штатах. Если есть аккаунт в гугле, то звонить можно сразу, надо только знать имейл друга. Скриншаринг, групповые звонки и, конечно, интеграция с другим продуктами корпорации добра.

Cisco WebEx хорош в плане звонков, но он менее интуитивный и платный. В Slack хороший звук, но групповые коллы платные.

Всем хорошей связи.

​Хорошо хоть пятидневка.

Источник

​PERT

Program Evaluation and Review Technique это целая методология планирования, хоть и довольно лаконичная. Самый интересный ее элемент - метод оценки по трем точкам - чаще всего имеют в виду, когда говорят PERT.

Чтобы сделать эстимейт по перту нужно дать 3 оценки:

- оптимистичную (O)

- пессимистичную (P)

- наиболее вероятную (M).

PERT = (O+4*M+P)/6

Допустим, вы получили оценку O = 5 дней, P = 15, M = 7. Тогда ваш PERT = (5+4*7+15)/6 = 8 дней. Из формулы видно, что самой значимой является наиболее вероятная оценка. При этом учитываются как оптимистичная, так и пессимистичная оценки, но с меньшим весом.

Этот метод полезен для проектов с высокими рисками. Плюсы:

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

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

3. Используя PERT, можно удивить клиента точными цифрами, сказав "с вероятностью 68% мы сделаем эту фичу за столько-то дней". Причем это подтвердит даже ваша бывшая математичка, никаких чудес.

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

Мотивация на долгосрочном проекте

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

- Генерация идей по улучшению продукта;

- Фидбек от менеджмента вашей компании;

- Новости с прода, репорты, планы от клиента (регулярный фидбек и без того маст хэв!);

- Смена задач, технологий, делегирование ответственности. Фронтендеры берут простые задачи бека, тестировщики описывают стори и т.п.;

- Командировка;

- Семинары внутри команды;

- Общение напрямую с заказчиком;


Друзья, пришлите мне в лс какие мотиваторы сработали у вас, самые интересные опубликую на канале.

Wiki

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

General
Team, roles, responsibilities  
   Retrospectives
   Risks
   Sprint reports
   Release notes
   Non-functional requirements
   UX personas
   DOD
   DOR
   JIRA flow
   Audits
Personal meetings

Dev
   Architecture & Technologies
   Environments
   Code guidelines
   Build versions
   Gitflow
   Deployment guide
   Builds (Jenkins)

QA
   Credentials
   Performance tests results
   Integration tests
   Test plan
   Reports

Договоренности надо фиксировать, иначе, считайте, их нет. Большая часть этого списка про договоренности. Например, есть страница Code guidelines - значит все пишут более-менее одинаковый код (необходимое, но не достаточное условие). Или Environment - команда знает какие серваки существуют и для чего используются. Конечно, договоренности надо проверять (и записывать на страницу Audits), но это уже другая история.

Главный скилл менеджера

Фундаментальный навык ПМа и, по совместительству, самое сложное в его работе - коммуникации. Смертный вряд ли сумеет заменеджить проект, не умея договариваться. Настроить джиру или сделать понятный репорт сможет любой, скажем, подписавшись на полезный канал в телеграмме 😜. А вот объяснить дев лиду в чем он неправ, при этом не только не поругаться с ним, а мотивировать поменяться - талант от боженьки. Кстати, еще круче будет, если дев лид сам придет к этой мысли в ходе разговора с вами.

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

1. Трудные диалоги: Что и как говорить, когда ставки высоки. (Гренни, Макмиллан)

2. Как пасти котов (Рейнвотер)

3. Статьи о конструктивном общении и алгоритме решения проблем (Орлов).

Подборка каналов о PM

В телеграмме не так много каналов об управлении проектами, вот самые классные:

@scrummasters - заметки про скрамчик, много практики;

@psilonsk - рассуждения о тонких, глубоких штуках в управлении;

@realtoktok и @teamleading - мощнейшие советы, хаки для PM\SM;

@lovely_it_hell - проблемы менеджмента глазами head of R&D;

@pmwithloveandsqualor - канал Даши похож на радио, там все сразу, вперемежку с личным, но некоторые посты цепляют;


Другое:

@docops - как вести документацию, но не служить Сатане. Рекомендую аналитикам.

@AgileBelarusCom - чат о гибких методологиях, можно не стесняться задавать вопросы любого уровня, на все ответят. Порой поражаюсь когда эти люди успевают работать 😎. 

Делайте проект так, как продакты делают свои продукты. Темы схожие, много полезной инфы нахожу на @ruspm и на легендарном @proproduct.

​Гаджет Sprint Health

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

Хотите за полсекунды понять пора ли вашему спринту вызывать священника – бросьте взгляд на Sprint health гаджет. Он показывает:

- сколько дней спринта прошло\осталось. Помогает, если вы отлично провели вчерашний вечер 🍸

- сколько Story Points в open\in progress\done. В связке с предыдущим пунктом можно прикинуть успеете ли сделать запланированное.

- изменение скоупа, на сколько отклонились от первоначального плана (добавили\убрали стори);

- blocked\flagged тикеты. Этим, вероятно, нужно пристальное внимание;


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

​Релизный чеклист

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

https://telegra.ph/Reliznyj-chek-list-09-03

Если вы пушите в мастер по 6 раз в день, список будет сильно короче.

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

​Пирамида усвоения информации

Ютуб круче Библии. Ученые доказали что смотреть видео эффективнее, чем читать, с точки зрения скорости получения знаний. Остальные методы обучения они тоже исследовали и визуализировали в виде пирамиды усвоения информации (Learning Pyramid).

Как это использовать:

1. Просто читать уже мало, пробуйте на практике все что заинтересовало.

2. Обсуждайте проблемы с коллегами внутри компании или в коммьюнити.

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

Интро к ретре

Norman Kerth, апостол ретроспектив, придумал такую мантру:

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand. 

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

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

Клиент продавливает сроки

Когда заказчик ставит недостижимые сроки, есть пара приемов, которые помогут вам вписаться в них:

1. упростить фичу;

2. упростить разработку (говнокод, выбросить юнит-тесты и т.д.);

3. добавить людей или распараллелить работу;

4. урезать качество;

5. овертаймы;

Иногда этого недостаточно, при этом сроки все еще гневают всевышнего. На этот случай вот вам цитата из книги "Мифический человеко-месяц":

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

У повара есть еще одна возможность: добавить жару. В результате омлет часто оказывается безнадежно испорченным: горелым с одного края и сырым — с другого.