Текст книги "Настольная книга project-менеджера. Что нужно знать, чтобы управлять IT, digital и другими проектами с учетом российских реалий"

Пояснения

Рекурсия – ситуация, когда объект является частью самого себя. Если у вас украли кредитную карту, позвоните по номеру на обороте кредитной карты.

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

Большинство современных промышленных систем реализованы с использованием паттерна проектирования приложения MVC (Model View Controller) или его производных. Не все, это не догма, есть и альтернативные варианты, но этот подход чаще всего применяется. Model-View-Controller или MVC, или «Модель-Представление-Контроллер» – предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента:

Модель (Model) предоставляет данные, как правило, лежащие на сервере, например, в базе. И эти данные со временем могут как-то модифицироваться. Например, на сервере хранится информация о товаре.

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

Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Чтобы было понятнее, пример. В базе данных у вас лежит товар. Его можно вывести и на страницу с карточкой товара, и на страницу списка товара и в корзине пользователя. Физически в базе это будет один и тот же товар, но отображаться он будет по-разному. За хранение данных о товаре отвечает модель. За то, как этот товар можно показать пользователю – представление, или View, их может быть несколько. Ну и есть некие операции, которые можно выполнять с товаром: положить в корзину, удалить из корзины, удалить из базы, добавить остатки на складе и так далее. За них отвечает контроллер.

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

Scrum – передовой фреймворк (платформа), созданный в 90-е специально для разработки, передачи и поддержки сложных продуктов. Сейчас используется и в других сферах. Суть: весь объем работы делится на короткие этапы в 2–4 недели (спринты), в рамках которых выполняется конкретный перечень задач из бэклога (списка всех задач, упорядоченных по приоритетности). Подробнее о Скраме мы поговорим в главе 3.

Карта компетенций – таблица со списком и уровнем необходимых навыков по каждому сотруднику. Благодаря ей можно оптимально распределять людей по командам, следить за прогрессом каждого из них и давать задачи на прокачку недостающих навыков. Подробнее о картах компетенций говорим в главе 7.11. Пример карты компетенций ищите в Приложении 1.

Хакатон – форум для разработчиков, во время которого специалисты из разных областей разработки программного обеспечения сообща решают какую-либо проблему на время.

CSS-файл – каскадная таблица стилей, которая применяется для оформления веб-страниц. С помощью CSS-файла задается цвет, шрифт, положения отдельных блоков на странице.

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

Часть 3
Пятиминутный scrum

Настало время кратко посмотреть на Scrum – фреймворк разработки проектов. «Фреймворк» означает, что в чистом виде, по книге, у вас это вряд ли заработает. Ладно-ладно, заработает, но не с первого раза. Его нужно будет настраивать и сращивать с вашими текущими процессами.

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

3.1. Схема scrum. Артефакты. Роли. Процедуры

Итак, продукт выпускается поэтапно. Сначала минимальная версия. Затем постепенно наращиваем функциональность.

Каждый цикл разработки называется Спринтом. Рекомендованная продолжительность спринтов – от 1 до 4 недель, подбирается экспериментально. Нужен ритм «рывок-отдых». В итоге каждого спринта должна получиться новая версия продукта с приростом функций – инкрементом.

Product Owner (Владелец Продукта) отвечает башкой за стратегию и приоритеты разработки. К нему поступают «хотелки» пользователей, метрики, жалобы, баги, идеи стейкхолдеров. Коллективная ответственность в расстановке приоритетов не работает. Но рутину вроде сбора обратной связи можно делегировать.

В Scrum-е нет нудного толстого технического задания, которое выполняется от корки до корки. Нет попытки предусмотреть все и сразу. Вместо ТЗ хотелки складываются в специальную табличку – Product Backlog – и сортируются по приоритетам с точки зрения бизнеса. Можно по ходу работы менять, выкидывать и добавлять функции.

Примерно так это выглядит:

Простой бэклог в Google Docs

Минимальный состав бэклога: хотелка и приоритет. Можно добавлять свои поля. Например, описание и предварительная трудоемкость. Чаще всего, в условных единицах – Story Point. Берем за 1 балл самую простую хотелку, все остальные оцениваем относительно нее. Бэклоги удобно хранить в Google-таблицах. Можно дать доступ команде и синхронизировать с таск-трекером типа Jira.

Приоритет – чем больше число, тем выше. При ручной расстановке приоритетов удобно делать между ними зазоры (100, 200, 500). Так проще будет вставлять хотелку между двумя другими. Одинаковых приоритетов, по классике, быть не должно.

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

Все заинтересованные лица могут добавлять что-то в бэклог. Но только Product Owner определяет приоритеты. Для этого нужно периодически просматривать бэклог, выкидывать оттуда мусор, обновлять приоритеты и улучшать формулировки.

Есть специальные методики приоритизации, снижающие субъективное мнение (галлюцинации) Product Owner о важности той или иной хотелки. Подробнее о техниках поговорим в главе 4.

RoadMap – предварительный календарный график выпуска релизов. Этого нет в Scrum, но без него картинка проекта теряется.

Как выглядит Roadmap

Команда разработки. По умолчанию имеются в виду программисты. Команда забирает верхнюю часть бэклога в работу, дербанит каждую хотелку на технические тикеты и оценивает. Мы используем Planning Poker, о нем чуточку позже. Так формируется бэклог спринта (Sprint Backlog) – то, что команда считает реальным сделать за следующий Спринт.

Задачи, попавшие в Sprint Backlog, менять нельзя. В отличие от задач из Product Backlog, в котором можно менять все что угодно до тех пор, пока команда разработки не заберет и не запланирует верхние хотелки.

Обычно Sprint Backlog у нас попадает на канбан-доску в тикет-системе. Это привычный многим инструмент, где есть карточки с задачами и колонки, соответствующие статусам работы. Как минимум это Plan, In Progress, Check, Done. Чертовски напоминает цикл Деминга.

Можно придумывать свои колонки, добавлять критерии готовности, чек-листы, ограничения одновременно выполняемой работы (WIP, work in progress) – тут все гибко.

Канбан-доска спринта в Jira

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

Команда – такой мини-спецназ в тылу врага. Компактная: рекомендуется не более семи человек. Кросс-функциональная: есть все компетенции, чтобы сделать проект. Самоорганизующаяся (упс!), самообучаемая и ответственная. Большие проекты дробятся на компоненты и распределяются по своим командам.

Ежедневно, в одно и то же время и в одном и том же месте, команда собирается на Стендап (Daily Scrum), где каждый по очереди отвечает на три вопроса:

1. Что было сделано вчера (для достижения целей спринта)?

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

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

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

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

Как проходят стендапы в «Сибирикс»

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

Тоскливо, когда на вопрос: «Что было сделано вчера», вам отвечают что-то вроде: «Я размышлял об архитектуре», перечисляют номера тикетов или закидывают техническими деталями. Пальцем, дружок, на экране покажи, что там нового напрограммировалось!

На стендапах удобно повесить перед глазами сформулированную кратко цель спринта – помогает сфокусировать команду не на микро-тикетах, а на цели.

И Burndown Chart (диаграмму сгорания), по которой видно, успеваем ли мы, или все пошло «через плохо». Эти и другие метрики полезны, но нос держим по ветру и чутко реагируем на то, что говорит команда. Управлять только через метрики не получится.

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

Намылить, смыть, повторить.

3.2. Внедряем!

Мы внедряли у себя Scrum в начале 2000-х, когда это еще не было мейнстримом, а про Agile не говорил Греф из телевизора. Наломали, конечно, дров, но быстро все исправили. Первое, что внедрили – итерации и стендапы с тремя каверзными вопросами. Скорость и управляемость сначала выросли, а потом упали. Команды начали либо грустить, либо бунтовать. В воздухе витало «ща долбанет». И долбануло бы!

А что не так? Не было ретроспектив. У команд копились вопросы «а зачем все это» и ощущение, что с них выдаивают результат. Этакая вечная сессия.

Начали проводить ретроспективы, объяснять, как устроен Scrum. Реально собирать обратную связь от команд. Решать их проблемы. Дали почитать литературу. Обучили Scrum-мастеров внутри команд и сказали, что теперь менеджеру можно говорить слово из трех букв («Цыц!»), если он нахальничает. И начало получаться.

Примерный план действий при внедрении:

1. Дать команде почитать про Scrum, какие есть роли и артефакты, и какие плюсы он дает.

2. Нулевая ретроспектива. Собрать команду. Обсудить ее проблемы. Посмотреть, сможет ли Scrum улучшить ситуацию, обсудить, как именно. Рассказать еще раз весь процесс. Ответить на вопросы. Распределить роли.

3. Организовать итеративную работу (спринты) и стендапы. Запретить менять постановки внутри спринтов. Для начала выбрать недельные циклы. Потом – откорректировать.

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

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

Я бы вообще начал внедрение Scrum-а с ретроспектив. Раз в неделю-две собирал бы команду, обсуждал проблемы и решал их, улучшая рабочий процесс. Глядишь, через месяц весь Scrum нормально заработает.

3.3. Подготовка и планирование спринта

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

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

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

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

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

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

Опытным путем мы пришли к тому, что нужно дать команде за час-два до планирования прочитать постановки и сформулировать вопросы. Ребята делать этого не любят и читают уклончиво. Логика такая: зачем напрягаться-читать, если на планинге все равно голосом проговорим. Мозг экономит энергию. Но если этого не проделать – планирование спринта может превратиться в многочасовой склочный базар. Приходится заставлять читать и думать. Как тренер в спортзале заставляет сделать пару дополнительных приседаний.

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

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

Размер задач зависит от опыта команды. Мне нравится, когда каждый день можно глазами посмотреть, что поменялось в проекте. Постарайтесь делать декомпозицию, чтобы задачи было просто проверить, а трудоемкость была от 1 до 8 часов (если вы оцениваете в часах, а не в Story Points). Опять же, не всегда получается, да и опытная команда будет сопротивляться такой мелкой разбивке. Опытным нужны крупные куски. Но для молодых и дерзких управляемость сильно возрастает.

Сугубо технические задачи, типа «Удали поле id из таблицы Users» – дрянь. Формулировки лучше делать на уровне фич: «Форма обратной связи» или «Отправка письма о восстановлении пароля».

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

Не старайтесь забить время спринта под завязку. Например, в двухнедельный спринт команды из трех человек засунуть задач на 240 часов. Лучше иметь небольшую подстраховку на код-ревью, рефакторинг, отладку и закон Мерфи. Про него известно, что он точно случится. Сколько взять подстраховки – зависит от опыта команды и задач. Нужно подбирать эмпирически. Начните с 20 %: не 240 часов, а 190. Через пару спринтов нащупаете свою реальную производительность.

Такая подстраховка не нужна, если вы работаете в Story Point. Она зашита внутри оценки.

Кроме разработчиков, на планирование я приглашаю тестировщика. Так он будет в контексте и меньше рисков, что под видом «багов» он насыплет команде отсебятины.

Фиксируем цели спринта. Две-три, не больше. Кратко описываем будущий прирост функциональности. «Реализовать личный кабинет дилера», например. Хорошо бы их вывесить на стене, чтобы спотыкаться о них глазами.

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

Карточки задач в канбан-доске спринта

Внутри каждой карточки уже развернутое описание.

Карточка задачи с детальным описанием

Очевидно, что процедура планирования занимает кучу времени. Поэтому я не люблю короткие спринты. Две недели, на мой взгляд, – в самый раз.

3.4. Planning Poker

Planning Poker – инструмент для оценки задач. Карты удобны тем, что участники команд не могут ориентироваться на мнение своих коллег – так оценки получаются максимально очищенными от субъективизма и влияния «авторитетов».

В колоде 4 разноцветных набора для 4 участников. Если участников больше – добавляем колоду.

Достоинства карт: 0 (значит задача готова или слишком мелкая), 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100. Бывают карты с числами Фибоначчи или другой развесовкой, но мне нравятся эти.

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

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

Карты Planning Poker (planningpoker.ru)

Далее карты вскрываются. Если оценки плюс-минус совпали – фиксируем их в задаче спринта. Если нет – надо обсудить дополнительно.

Например, кто-то выкидывает оценку гораздо большую, чем остальные. Он либо про эту задачу что-то знает-замышляет. Например, был хреновый опыт в прошлый раз или там в коде ТАКООООЕ! И надо его расспросить. Либо спит (разбудим). После обсуждений – уточняем нюансы и переигрываем кон.

Еще две специальные карты: Coffee/beer – если все затянулось, и надо сделать перерыв, и WTF – для джуниоров, которые вообще ни в чем не уверены.

При планировании спринта я предпочитаю физические карты. С удаленными – online-сервис или простой видеочат, куда на «раз-два-три» все скидывают свои оценки задач.

3.5. Стендапы. Burn Down Chart

Это простая диаграмма «сгорания» спринта. Ее удобно держать под рукой на стендапах.

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

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

3.6. Стратегии тестирования

Две крайности: отложить тестирование на конец спринта или тестировать каждую закрытую свежевыполенную задачу. Как говорил товарищ Сталин – обе хуже.

Откладывать на потом – плохая идея, однозначно! Вы можете забуксовать в самом конце, и у вас получится сырой спринт. Сдавать стыдно, выбросить жалко. Product Owner будет недоволен. А баги все равно придется фиксить.

Тестировать каждую мелочь сразу – тоже не круто. Во-первых, проверенную задачу могут поломать, когда будут делать какую-то другую. Это называется регрессией (regression bugs). Брукс в «Мифическом человеко-месяце» писал, что это фундаментальная (значит, толком нерешаемая) проблема – исправление одной ошибки с вероятностью 20–50 % влечет появление новой. Полное покрытие автотестами стоит неоправданно дорого, да и никто не даст на него времени. Надо дело делать, а не абстракциями заниматься.

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

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

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

Если команда зрелая, а бюджеты позволяют (для сайтов это почти всегда не так – всем дорого), покрывайте рутинные проверки автотестами. Или, как минимум, формализуйте тест-план для критических маршрутов проведением смоук-тестов на продуктиве. Например, в интернет-магазинах покрываем тестами маршрут Каталог → Карточка товара → Добавление в корзину → Корзина → Чекаут. Критических тестов не должно быть много, и они не должны занимать много времени. Но должны вселять уверенность, что ключевые функции в порядке.

В заказной разработке редко, но встречается клиент, который не видит ценности в тестировании. Речь идет не о манипулятивном приеме, попытках отжать скидки или загнать разработчика под плинтус («Я что, должен за ваши косяки платить?!»). А об искреннем непонимании, как возможно, что после тестирования, тест-кейсов и всех этих довольно дорогих процедур – я, как заказчик, нахожу ошибки. Причем такие, которые кажутся мне очевидными. Они меня бесят! Я не понимаю, на что тратятся время и деньги.

Совет

Немного помогает, если у заказчика есть доступ на чтение баг-листов, и он видит, что команда нашла и исправила несколько сотен ошибок. Но утешение слабое, осадочек остается. Отправлять баг-листы нужно до того, как претензия созреет, а не после. Действовать от силы, а не от слабости. При этом должна быть определенная культура ведения баг-листов: смотрите главу «Правила письменной контрацепции». Однако лучше всего попадать в ожидаемое качество и давать гарантию на свою работу.