Менеджер делает все то, что нужно делать, но что не делает никто другой.
Или, как минимум, организует и делегирует, чтобы делалось все то, что почему-то никто не делает.
Но вот команда взрослеет, Scrum уже отлажен, все привыкли друг к другу и процессу, есть внутрикомандный scrum-мастер. В этом случае роль менеджера действительно уменьшается. И во что он трансформируется вопрос на вырост. Может, в скрам-мастера. А может, в продуктового менеджера, или аналитика, или помощника Product Owner.
Кажется, редкие-редкие команды достигают такого дзена, где менеджер не нужен. Да и не в нашей ментальности работать без начальства. Короче, менеджер необходим и востребован, аллилуйя.
Можно ли совмещать в себе несколько ролей сразу? Быть и скрам-мастером и Product Owner? Технически да, я такое видел в молодых командах. Но это антагонистические роли. В них специально зашит конфликт. Product Owner хочет больше и быстрее от команды, и менять все в любой момент. Scrum Master хочет, чтобы команда спокойно работала, и процесс не ломался. Сможете вы такое в своей голове удержать (быть и добрым, и злым), или начнет шизофрения развиваться? Хорошего-то мало. Я бы начал выращивать scrum-мастера внутри команды. Благо это несложно, дня за три можно справиться.
3.11. Аналитика, дизайн, разработка параллельно
Обычно нужно несколько спринтов, чтобы получился MVP (minimum viable product) минимальный жизнеспособный продукт. MVP должен быть клевенький.
Цепкий, энергичный менеджер может организовать параллельную работу над аналитикой, дизайном и кодом. В Scrum-е спринт по аналитике запускаем чуть заранее. За ним дизайн. И далее уже код. Примерно по такой схеме (правда не факт, что у вас будет так много дизайна и аналитики, но вдруг?).
При параллельной разработке нагрузка на менеджмент и коммуникации растет чуть ли не экспоненциально. Поэтому подход не для новичков, а для матерых организаторов.
3.12. Документация
Agile-манифест (которому сто лет в обед) набор правильных лозунгов, которые как-то надо адаптировать к практике:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Agile-манифест разработки программного обеспечения. 2001 год.
В зрелом продукте документация нужна, Agile это не отрицает. В небольших web-проектах и приложениях можно и без нее. Степень замороченности прямо пропорциональна объему проекта, педантизму заказчика и ресурсам. Правда, документация всегда немного отстает от реальности, и это окей.
Работая над SingularityApp, например, я беру какую-то крупную хотелку из бэклога и расписываю, как бы я хотел, чтобы она работала с точки зрения пользователя. Это просто схемки интерфейсов на iPad, скриншоты похожих реализаций и немного текста. Если нужно докрутить формальности отдаю аналитикам (с проверкой, чтобы не исказили идею). Там уже могут появляться прототипы, описание граничных случаев, интеграционные протоколы и так далее, если мне нужна такая степень проработки и формализма. Такие штуки удобно хранить в Confluence или википедии проекта. Подойдет и Google Docs.
Уже эти постановки дербанятся на технические тикеты (sprint backlog), и по ним рисуются интерфейсы. Confluence позволяет отправлять задачи в бэклог прямо из текста документов (правда, довольно коряво, но все же). Мелкие хотелки из бэклога можно так детально не разжевывать.
Кодерская и техническая документация, в основном, лежит либо в самом коде (the code speaks), либо в вики проекта.
Общее правило положи документацию как можно ближе к месту ее использования.
Иначе про нее забудут, забьют и потеряют. Мне лениво лезть лишний раз за кусочком текста. Я хочу все понимать здесь и сейчас.
Документацию важно увязать с тест-планами, чтобы QA не плодил свои постановки и хотелки.
Пользовательская документация (инструкции, мануалы, вопросы и ответы) обычно отдельный процесс. Полностью делегируем. В долгих и больших проектах, где важно поддерживать консистентность документации (и на это есть ресурс), во время написания пользовательских инструкций актуализируются и изначальные постановки: чертежи с iPad заменяются реальными интерфейсами, дополняются моменты, которые уточняются по ходу реализации.
На заказных web-проектах и мобильных приложениях такой контур слишком затратен, тут документацией должен стать сам код, бэклог, ТЗ или описания в Swagger. Хотя время от времени сложные, интеграционные моменты приходится документировать. Особенно, если реализуется API, с которым будут работать сторонние разработчики.
Документация требует времени, ресурсов, отдельного контура управления и внимания. Ну а хорошего технического писателя днем с огнем.
Нужна ли документация на вашем проекте? Будете ли вы ее писать по ГОСТ 19 или ГОСТ 34, или стандартам ISO? Будете ли использовать UML или BDD-подход (Behavior-driven development, дословно «разработка через поведение»), язык описания сценариев Gherkin? Вопрос, на который не надо торопиться отвечать. Делайте минимально необходимое и дополняйте по мере необходимости. Не старайтесь заранее все предусмотреть.
ЧЕЛОВЕК, КОТОРЫЙ ВСЕ ПРЕДУСМОТРЕЛ
Однажды человек решил предусмотреть на сайте ВСЕ. ВСЕ тренды, вау-эффекты, поисковые рекомендации да мало ли. Короче, все. Ну что б потом не переделывать. Это был очень предусмотрительный человек.
И на встречу со студией он решил прийти лично. Надел костюм. Пальто. Шляпу. Взял зонтик. Подумал и на всякий случай захватил солнцезащитные очки. Перчатки. Сотовый телефон. Две запасных батарейки. Это был очень предусмотрительный человек.
Взял пару бутербродов. Бутылку коньяка. Пачку презервативов. Хлоргексидин. Перочинный ножик. Вареных яиц. Ножовку по металлу. Бумажную карту Свердловской области. Аккуратно разложил это по карманам своей жилетки. И не надо думать, что это был какой-то уникум, типа Онотолия. Просто обычный человек, который всегда все предусматривал.
Аптечку. Лыжи. Акваланг. Ласты. Бинокль.
Вышел из дому. Стоит посреди лужи. И думает: «Блин, а все ли я предусмотрел на сайте?»
3.13. Метод красной рамки
Для программистов, если они не шарлатаны, уже привычно работать итерациями. Какая-то функция на экране готова. Какая-то нет. В новых версиях в каждый спринт, добавляется что-то новенькое. Но в целом можно уже посмотреть, как ведет себя продукт.
Чтобы не возникало вопросов, что уже готово, а что нет, рекомендую использовать метод красной рамки. Суть в том, что прописывается специальный стиль (например. todo), выводящий тонкую красную рамку вокруг нужного нам элемента. Этот стиль присваивается тем компонентам интерфейса кнопкам, полям, формам и т. д. которые отражаются на экране, но еще не реализованы в коде. Таким образом наглядно видно, что в данный момент готово, а что нет.
Этот метод работает и в заказной итеративной разработке. Заказчику не нужно будет постоянно объяснять, куда можно тыкать, а куда нет. Если что-то не работает мы четко разграничиваем ситуации «сломалось, баг» или «все под контролем, еще не реализовано».
Одна из первых итераций портала Северсталь. Поиск, вход, регистрация и переключение языков еще не реализованы.
Итак, плюсы:
1. Заказчик сразу видит, что готово, а что нет не тратим время на объяснения, почему не работают некоторые поля.
2. Тестировщик понимает, какие блоки еще сырые, и не тестирует их.
3. У разработчиков не остается шанса промотать задачу.
3.14. Потому что карго-культ!
Во время 2-й мировой войны США строили свои военные базы по всяким разным диким островам в Тихом океане. Продовольствие и шмотки возились самолетами, причем часть груза просто сбрасывалась вниз. Ну, и кое-чего перепадало диким человекам, живущим на этих островах. Причем, иногда перепадало столько, что аборигены полностью забивали на свою хозяйственную деятельность, выращивание бананов и скотоводство. Туземцы быстро уловили, что американцы сами ништяки не производят, а все им достается с неба, за верность духам предков.
Война кончилась, американцы свернули базы. И вот представьте их удивление, когда лет через 20, вернувшись на эти острова, они обнаружили марширующих негров с муляжами ружей, наушниками из дерева, копии самолетов из бамбука в натуральную величину, муляжи аэродромов из соломы В общем, туземцы довольно четко эмулировали действия американцев, с той лишь разницей, что духи предков почему-то не спешили больше сбрасывать с небес ништяки.
Туземцы не понимали, что стоит за происходящим, не понимали, как устроен мир, и почему с неба падает продовольствие. Поэтому выполняли бессмысленные ритуалы, которые не давали результата.
Не тем ли мы занимаемся, когда выполняем ритуалы, вроде стояния у канбан-доски по утрам или планирования с помощью карт Planning Poker, абсолютно не понимая смысла происходящего? Понимаете ли вы, какие выгоды дает каждый компонент?
Возможно, единственная проблема туземцев в том, что они остановились в своих поисках и экспериментах и не получали какую-либо обратную связь. Истина видимо где-то посередине: разбирайтесь в тех методологиях, которые используете, и постоянно экспериментируйте, оставляя только реально работающие подходы. И ништяки повалятся к вам.
Упорство отличается от Упертости. Упорный, если не получилось, пробует другой подход. Упертый продолжает делать то же самое, рассчитывая на другой результат.
3.15. Для тренировки
Итак, мы разобрали Scrum гибкий простой фреймворк для организации работы команд над современным софтом! Он задыхается в угрюмой, бюрократичной среде и хорош там, где нужно регулярно улучшать продукт, реагировать на изменения в мире и обратную связь. Мобильные и веб-приложения самое то!
Задание иди и внедряй!
Попробуйте это внедрить у себя. Посмотрите, что заработает сразу, а что ни в какую. Проведите несколько спринтов и ретроспектив.
И постарайтесь не скатываться в СКРАМНО («у нас Скрам, НО без итераций») и Карго-культ.
Успехов!
Литература
Джефф Сазерленд, «Scrum: Революционный метод управления проектами».
Фредерик Брукс, «Мифический человеко-месяц».
Антон Макаренко, «Педагогическая поэма».
Скрамгайд в доступном переводе от Сибирикс (QR-код слева).
https://blog.sibirix.ru/2018/10/31/scrumguide-all/
Пояснения
Канбан-доска инструмент метода разработки «Канбан», представляет собой доску, разделенную на этапы работ, с задачами в виде карточек, которые перемещают по доске по мере их продвижения по этапам.
Рефакторинг перепроектирование или переработка кода, изменение его структуры, которые не производят функциональных изменений, но существенно облегчают его работу.
Закон Мерфи шутливый философский принцип, который звучит как: «Все, что может пойти не так, пойдет не так».
Story Point метод оценки сложности задач, когда за 1 балл принимается самая простая задача, а все остальные оцениваются относительно нее.
Автотест (автоматизированный тест) это скрипт, имитирующий взаимодействия пользователя с приложением, для локализации ошибок в работе сайта, приложения или ПО.
Смоук-тест минимальный набор тестов на явные ошибки, который обычно проводит программист. Без прохождения такого теста нет смысла затевать более глубокое тестирование.
Продуктив уже запущенный сайт, живущий на сервере заказчика.
Коммит в системах управления версиями коммит добавляет последние изменения в часть исходного кода в хранилище, делая эти изменения частью основной версии хранилища.
Confluence софт для для командной работы, удобный для распределенных команд за счет опций совместной работы.
SingularityApp мощный хаос-менеджмент планировщик, разработанный в студии «Сибирикс». Существует в виде онлайн-версии для ПК и приложения для смартфонов на Android и iOS.
Википедия проекта база знаний, где хранятся подробные руководства функционала продукта.
Консистентность документации цельность документации и согласованность документов друг с другом.
Swagger язык описания интерфейсов для описания RESTful API, который используется для проектирования, создания, документирования и использования веб-сервисов RESTful.
UML это специальный язык для описания разных бизнес-процессов, структур и прочих вещей, для которых необходимо последовательное описание. В запутанных ситуациях с большим количеством сущностей может сильно помочь. UML включает несколько видов диаграмм: диаграммы последовательности, компонентов, объектов, структуры, синхронизации и так далее.
Язык описания сценариев Gherkin человеко-читаемый язык для описания поведения системы, который использует отступы для задания структуры документа (пробелы или символы табуляции). Каждая строчка начинается с одного из ключевых слов и описывает один из шагов. Обработчик разбивает файл с тестами на функции, сценарии и входящие в них шаги.
Часть 4
Аналитика и продуктовые техники
Большинство удачных идей оказывается неудачными.
Британские ученые подсчитали, что 92 % стартапов проваливаются в течение 3 лет. Главная причина продукт нафиг никому не сдался (42 %).
Я чувствую так же. Мы плотно работали со стартапами с 2010 года. Некоторые из них живы, и даже неплохо живут. Но, оглядываясь назад, я вижу кладбище.
Наверное, всем, кто работал в заказной разработке достаточно долго, знакомо это чувство. Много времени, сил, энергии, интеллекта и отваги вкладывается в какой-то проект, в какую-то идею И где это все годика через 4? Пшик, очень жаль
Другое дело, когда проект создавался под конкретную задачу, было заранее понятно, что есть сегмент пользователей, у которых в нем есть потребность, и посчитана экономика. Зачастую это обычные, работающие бизнесы, решившие поглубже залезть в интернет или автоматизировать рутину. Тут, несмотря на кризисы, выживаемость и успешность близки к 95 %. Пойман Product Market FIT (PMF) состояние, когда клиенты довольны продуктом и рекомендуют друзьям. А сам бизнес растет.
Я уже говорил об этом во введении, об экологичном пути руководителя проектов, но скажу еще раз. Моя религия и пятнадцать лет опыта выращивания руководителей проектов говорят, что если вы только осваиваете управление digital-проектами и не имеете глубокого технического бэкграунда, то самый экологичный путь стать первоклассным специалистом это поработать некоторое время в тестировании и аналитике.
В этой части мы посмотрим на техники управления продуктом, которые помогут минимизировать галлюцинации основателей, нащупать сегменты пользователей, протестировать гипотезы и т. д. Этими инструментами должны хорошо владеть руководители продуктов и аналитики. В маркетянские штуки уходить не будем.
Для руководителей проектов инструменты полезны. Во-первых, для понимания, как Product Owner принимает решение. Во-вторых, на вырост. В-третьих, скорее всего, Product Owner что-то из этих штук сам делать поленится, или его нужно будет возвращать в реальность. А кто будет делать все то, что делать надо, но не делает никто другой вы уже в курсе.