скачать книгу бесплатно
Спасибо за лозунги. Но я не знаю, как это реализовать.
2. «Не жрать после 18:00» или «Проводить стендап за 10 минут ровно».
Богатая идейка! Больше похожа на правило.
Если бездумно добавлять правила – место кончится. Или будет вагон правил, которые не блюдут. А это дискредитирует власть. Или это будут правила, которые помнит только их автор. И ненавидит коллег за несоблюдение.
Переформулируйте на локальное и исполнимое: «Не жрать после 18:00 в течение следующего спринта», например. Вот это реалистичнее.
3. «Давайте будем закладывать больше времени на подготовку и архитектуру».
Во-первых, это тоже правило. Во-вторых, не люблю, когда добавляются буферы времени.
На это есть Закон Паркинсона: работа занимает все отведенное на нее время. И даже чуть больше. Сколько буферов ни закладывай – будет мало.
Давайте лучше адекватно оценивать задачи и делать дело так быстро, как это возможно, не?
4. «Давайте проверять после тестировщика – другим тестировщиком».
Ну уж нет! Чем больше проверяющих, тем хуже качество. Зачем мне стараться, если за мной перепроверят и под носом подотрут? Рассеивается ответственность.
Я хочу «встроенное» качество как можно ближе к центру создания ценности. Я хочу встроенное в программистов качество. И они это могут!
5. «Пусть менеджер нам кофе приносит. С козинаками. И веером нас обдувает».
На ретроспективах менеджеру легко наловить себе обезьян на голову. Я видел ретроспективы, где команда навешивала на менеджера-слабака кучу правил, которые должен выполнять только менеджер.
С одной стороны, решение проблем команды и правда потребует менеджерского ресурса. С другой стороны, если после ретроспективы вы выходите с ворохом задач чисто для себя – тут явно какой-то косяк.
Надо помогать команде самостоятельно справляться с проблемами, а не быть еврейской мамочкой. Следите за тенденциями.
6. «Давайте все к черту перепишем».
Вот это происходит у меня прямо сейчас, в работающем проекте аптечной сети, где 5000 аптек, первая в стране доставка лекарств online, тысячи пользователей. Просто проекту 4 года, и там нет реактивного фреймворка. А это не так весело и круто. Программисту скучно.
То есть, идея предложена как бы во благо проекта, но чувствуется сильный личный мотив. Почесать ЧСВ, поиграть с технологиями, стать незаменимым и так далее. Словом, почувствовать себя крутым! Я не вижу ничего дурного в таких личных мотивах – они полезны. И без их удовлетворения не будет кайфа на работе.
Но формулировку мы поменяем. «Составить план рефакторинга» – уже теплее. Этот план я внимательно изучу на целесообразность, адекватность прогнозов. Согласую с клиентом и внедрю. Постепенно.
7. «Пусть дизайнеры всегда теперь делают по-другому».
Это когда проблемы пытаются решить за счет отсутствующих на ретроспективе людей. Иногда – оправданно. Но! Естественно, отсутствующие будут не согласны.
Или придумываем правила, которые нужно распространить на всю компанию, а не только на одну команду.
Во-первых, такие правила сложно внедрять: нужно сформулировать, донести до пользователей, придумать контроль и наказания и потом постоянно накачивать в них энергию. А где возьмете дополнительную?
Во-вторых, у менеджера нет полномочий решать за всю компанию. Можно предложить какое-то изменение руководству. С должным обоснованием и планом внедрения. В такой формулировке задача уже более вкусная. Но это же думать надо!
А можно собрать дизайнеров и разработчиков вместе, и пусть они глаза в глаза расскажут, что думают друг о друге. Взорвать ситуацию. Как-то сразу тональность критики и категоричность уменьшаются. Я не против глобальных изменений, но тут очень аккуратно работать надо. Нежненько.
8. «Не хочу я быть римскою папой,
А хочу быть владычицей морскою».
Ну, сорян:)
В план должны попадать конкретные, выполнимые идеи. Можно даже по SMART. С конкретными исполнителями. Следующую ретроспективу мы начнем с проверки, что из этого плана получилось. И стало ли от этого лучше (бывает, сделали, как просили, и стало хуже, ага).
7. Заключительная часть Марлезонского кордебалета
Подводим итоги. Кратко зачитываем план. Спасибо, все свободны.
Можно повторно замерить настроение команды, убедиться, что ребята считают, что меры помогут.
Можно спросить обратную связь на ретроспективу.
Если все недовольны решениями, ретроспективой – вы в беде. Очень жаль. Надо чинить ретроспективу.
3.8.2. Форматы фиксации
Мы используем три формата ретроспектив.
1) Неформальные. Короткая встреча на 15–30 минут, где по очереди даем высказаться всей команде. Плюсы, минусы, идеи, предложения. Конкретные решения фиксируем, если все с ними согласны – забираем в план работ. Подходит, если на проекте все хорошо. Просто градусник. Артефактов не остается.
2) Формат с доской 2?2: плюсы-минусы, идеи, план. И стикеры.
Самое муторное потом – перенабрать писанину со стикеров и завести реальные задачи в тикет-системе. Но вы взросленькие, как-нибудь справитесь.
3) Электронные шаблоны.
Грамотный шаблон фиксации доступен в Confluence. Мы используем чуть попроще. Главное – вывести его на большой экран, чтобы все видели, как идет фиксация, и что ничего не забыто и не переврано.
3.9. Канбан. Когда лучше, чем scrum
Канбан – легковесный и прозрачный процесс. Задачи по мере поступления вывешиваются на доску, с которой разработчик может их забирать и программировать.
Канбан-доска технической поддержки. Фрагмент.
В отличие от Scrum-а, тут нет спринтов. Канбан больше подходит для контроля текущей техподдержки, маркетинга или обработки лидов. В разработке новых функций и версий лучше работает Scrum.
3.10. Куда дели менеджера
В теории нет разницы между теорией и практикой. А на практике есть.
Йоги Берра
Допустим, мы создаем продукт in-house. Собрали разработчиков в одной комнате, сказали работать по Скраму. Самоорганизуйтесь там как-нибудь. Получится? Маловероятно. На хакатон дня в три, может, и хватит, а на полноценный продукт уже нет. И канонический скрам-мастер тут вряд ли поможет.
Самоорганизующейся команде нужен самоорганизатор.
Другой пример. Вот идет разработка. Ни шатко ни валко, по ТЗ. Скорость медленная, баги, Product Owner ругается, команда грустит. Решают попробовать Scrum, а вдруг поможет. Опять нужен кто-то, кто сможет все самоорганизовать, сшить старые процессы с новыми, перевести работу на новые рельсы. Это искусство, тут много дел.
Или, допустим, заказная разработка. Product Owner на стороне клиента есть. Как-то на одной из встреч представитель клиента сказал на полном серьезе: «Да, у нас есть Product Owner, их целых 5» (ой!).
Что ожидается со стороны подрядчика? Что будет кто-то ответственный за проект, с кем можно вопросы порешать. А то и вовсе Proxy-Product-Owner нужен, который за заказчика все порешает, всю обратную связь со всех этих пяти Product Owner (корректнее называть их стейкхолдерами) соберет, решит противоречия и в случае чего – по башке получит. П – перспективы…
Менеджер делает все то, что нужно делать, но что не делает никто другой.
Или, как минимум, организует и делегирует, чтобы делалось все то, что почему-то никто не делает.
Но вот команда взрослеет, 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, вернувшись на эти острова, они обнаружили марширующих негров с муляжами ружей, наушниками из дерева, копии самолетов из бамбука в натуральную величину, муляжи аэродромов из соломы… В общем, туземцы довольно четко эмулировали действия американцев, с той лишь разницей, что духи предков почему-то не спешили больше сбрасывать с небес ништяки.
