Продуктивность команды в Agile – цинично о ее истоках

Bifurcation Многие удивляются – откуда в аджайле берется продуктивность? И отказываются признавать ее рост. Другие признают, но считают, что это мистическое свойство, “возникшее ввиду достижения некой загадочной величиной точки бифуркации”. Могу легко объяснить откуда что берется – но боюсь для многих объяснение прозвучит цинично. Объяснить могу так как я сам – ужасно продуктивный товарищ (и еще ужасно скромный, ага). Принципы достижения продуктивности я для себя сформулировал лет 5 назад – и с тех пор крайне мало к ним добавил. Они очень простые:

  1. Ставь цели. Ты должно четко знать, чего тебе надо, как оно выглядит и что для этого надо. Имей в голове картинку или на бумаге “зачем – почему откуда – куда – каким путем”. Не можешь объяснить зачем тебе оно надо – оно тебе не надо.
  2. Фокусируйся на них. Один момент времени – одна цель. У тебя может быть сотня, но работать одновременно по сотне – не сможешь. Поэтому лучше массировать усилия – выделяй таймбоксы на цели, и впахивай внутри них как папакарла.
  3. Ешь слона кусочками. Разбив большую цель на список задач – ты ужаснешься сколько надо сделать, но будешь в состоянии выделить маленькие задачи на каждый день, каждая из которых на шаг приближает тебя к цели.
  4. Когда работаешь – работай, и работай ритмично. Никаких фоновых кино, твиттеров, разговоров в фоне,  ответов в скайпе – потому что все это тебя отвлекает и ты теряешь время на переключении от задачи к задаче. Будешь отвлекаться – будешь очень медленно работать. Вместо этого – полчаса работы + 10 минут перерыва на побочку (помахать гантелями, ответить скайпы, выпить чаю, напостать в твиттер и т.д.).
  5. Разгребай навоз. Увидел, что задача застряла в туду? Безжалостно задай себе вопрос “шозанах?” Боишься? Делать ее!!! Неприятная? Делать ее!!! Непонятно как? Ресерч и делай!!! Иначе со временем твой туду лист превратится в такую навозную кучу, что проще сменить компаниюрод деятельности чем ее разобрать (но и там у тебя со временем вырастет куча).
  6. Делай себе ревью. Каждый день смотри в свой туду. Если все сделал – смело скажи себе “Damn i’m good!” (© Duke Nukem). Не сделал? Задай себе вопрос “почему я сегодня обгадился?”, причем не в контексте “на кого свалить?”, а в контексте “как мне добиться результата несмотря на?”.
  7. Будь дисциплинирован. Добейся исполнения тобой описанных 6 пунктов. Установи себе расписание и твердо его соблюдай. Бери себя за задницу и отрывай от флейма в форуме когда есть задачи по твоим целям. Не пей пива посреди недели несмотря на то насколько хороши камрады которые зовут. Сделай своим принципом “ни одной прокликанной минуты”. Заведи блокнот в котором каждый вечер записывай “что я сделал плохо? + как завтра это исправить?”.
  8. Отдыхай. Твои выходные – это выходные. Никаких задач. Художественные книги и фильмы, спорт, природа, семья, здоровье. Иногда просто лежи на диване и плюй в потолок. Ты должен восстановиться.

Тут я ожидаю серию воплей “аааа! этот подход на корню убивает любое творчество!”. Тогда первый вопрос челленджеру – видимо, я не творческий человек? Думаю, что те кто меня знают, крепко не согласятся. О себя добавлю – я ужасно творческий человек, и как всякий творческий человек – изрядный ра…яй, и если бы я себя не дисциплинировал – вы бы скорее всего никогда не увидели многих моих творчеств, в том числе и на этом блоге (они бы никогда не вышли из стадии “гениальная задумка”).

Так вот секрет продуктивности agile –  в том что энфорсает (от англ. ‘enforce’) все эти принципы. Раз – у каждого спринта должна быть цель, значит это не бестолковое болтание на месте. Два – спринт есть не что иное как таймбокс в рамках которого мы стараемся сделать максимум для достижения цели, и даже если что-то не успеем – все равно будет сделано изрядно. Три – мы разбиваем сториз на задачи и делаем так чтоб задача не выходила за день, и за свою задачу каждое утро должны отчитаться перед всеми – значит есть прогресс. Четыре – мы работаем ритмично по крайней мере на уровне дня, плюс Pomodoro стал во многих командах стандартом персонального тайм-менеджмента, значит каждый день хоть на несколько шагов, но мы приближаемся к цели. Пять – скрам мастер указывает команде на “залипшую” задачу, и значит навоз не копится. Шесть – мы проводим ретроспективы чтоб понять где у нас можно повысить эффективность, и следим чтоб принятые решения претворялись в жизнь – значит мы улучшаем свою производительность. Семь – нам дают чеклисты чтоб мы проверяли себя и при необходимости сами себе энфорсали практики, значит мы не забываем про принципы. Восемь – 40часовая рабочая неделя, и значит мы имеем время восстановиться и запустить очередной гиперпродуктивный цикл.

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

Как видите, продуктивность аджайла – она строго закономерная, и принципы, которые лежат в ее основе – они придуманы не Швабером, не Беком, и вообще переоткрываются десятками тысяч продуктивных людей каждый год. Открыть эти принципы и написать про них – просто. Другое дело что реализация этих принципов – она крепко зависит от принципа номер 7 – дисциплина. И вот тут обычно все и ломается – кто-то не может, кто-то не хочет, кому-то вообще на все плевать – но это как говорится уже совсем другая история…

Tags: ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • http://intr13.ru/ intr13

    Спасибо за связные и интересные мысли. Но у меня есть интересный вопрос.
    Насколько продуктивно работает agile в случае когда:
    1. Все члены команды доступны только 50-75% времени для участия в проекте.
    2. Одновременно с работой по спринту, члены команды занимаются поддержкой разработанного в прошлом спринте. И приоритет на поддержку выше.
    Работает ли в вышеприведенных случаях agile и асколько он продуктивен?:)

  • http://thetorch.ru/ Денис Петелин

    Тут как всегда есть нюанс, камрад.
    Есть задачи которые легко параллелятся – например, ты без вопросов можешь крутить велотренажер и смотреть кино. Может, ваша поддержка так же дружит с основной разработкой? Тогда все 100% ок.
    Задачи, которые требуют приложения интеллекта – параллелятся плохо: попробуй например писать свой код сидя на код ревью и слушая аудиокнигу фаулера или буча. По факту – ты ничего не запомнишь из книги, не допишешь код, сделаешь поверхностное ревью, и при этом устанешь как собака. Если это ваш случай – продуктивность 100% будет ниже плинтуса, аджайл или не аджайл.
    Но в то же время если вы сможете например 1 день адресовать поддержку, а один – разработку, то тогда все ок. Или как вариант вы можете сделать общий бэклог для разработки и поддержки и сократить свой спринт до 1го дня – и каждый день ставить себе цель исходя из текущей ситуации. Тогда все опять ок, но все умеют так быстро перестраиваться – требует энергии и ясного понимания перспективы.
    То есть главный принцип – есть цель, таймбокс и задачи под нее – он должен сохраняться, и это не хитрость аджайла, это просто человек так устроен. В большинстве случаев такого разделения можно добиться (если конечно у вас культура работы “все мечутся выпучив глаза!!!” не насаждается руководством).

  • badlittleduck

    “Другое дело что реализация этих принципов – она крепко зависит от принципа номер 8 – дисциплина.”

    “8. Отдыхай. Твои выходные – это выходные. ”

    Ай по Фрейду опечаточка, Денис! )

    • http://thetorch.ru/ Денис Петелин

      Да, фигня вышла 😀
      Спасибо что заметил.

  • http://intr13.ru/ intr13

    Спасибо за ответ, товарищ!
    Тут вопрос не в параллельном выполнение задач, задачи делаются последовательно. Вопрос в том насколько эффективно 100 процентов рабочего дня бить на части. И каждая часть это отдельный проект.

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

    Кстати, есть еще философский вопрос: что такое 1 процент рабочего времени?:)

  • http://thetorch.ru/ Денис Петелин

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

  • http://pveller.blogspot.com/ Pavel Veller

    Поддержка (а я предполагаю, что мы говорим про уровень 2 и 3, а не 1, где входящие звонки и работа с клиентом по чек-листам) имеет свои процессы (ITIL, например, – классика жанра) и в зависомости от ситуации может требовать полной или частичной занятости озадаченной команды. Поддержка объемного продукта или системы обычно генерирует достаточное количество запросов, чтобы держать очередь полной, и работа тогда строится от этой самой очереди, где запросы обладают приоритетам, взвешаны по оценкам турдоемкости, и сверху мониторятся SLA. В данном случае, agile техники в обсуждаемом контексте (бэклоги, спринты, истории) не совсем пригодны, однако стэнд-апы, ответственность, дисциплина, никогда не вредят. Ну и динамики хоть отбавляй. Определенным типам людей, поддержка такого рода куда милее “плановой” разработки.

    Но это только одна граница спектра. Если трэнд запросов на поддержку позволяет включить тайм-боксы (например, в виде спайков) в спринт тогда его можно мешать с плановой разработкой и закатывать под общий проуесс. Но как только скачки нагрузки (а таковые будут обязательно равно как и провалы) выбьют сприинты из ожидаемого ритма (из графика как бы в классическом agile не выбъешь – задачи, вытесненные измененными приоритетами поступиших запросов на поддержку, легитимно перетекут в следующий спринт), выделение подкоманды сапорта со своей версией процесса станет следующим очевидным шагом.
    Разделение разработки и поддержки по дням, к сожалению, не всегда работает. Запросы поддержки, как правило, требуют приоритетной реакции, так как за ними стоит SLA контракт.

    А вообще, в каждом случае (и в этом сила process tailoring, не важно какой именно «базовый» процесс мы подстраиваем) сильная команда найдет именно тот путь, который наиболее правильно соответсвует реалиям проекта, клиента, и самой команды.

  • http://pveller.blogspot.com/ Pavel Veller

    Еще хотел добавить, что там, где поддержка натурально смешивается с разработкой (по аналогии Дениса с беговой дорожкой и телевизором), там скорее всего sustaining engineering, а не классическая поддержка (level 1, 2, and 3). sustaining engineering легко замешивается на любом SDLC с очевидным тяготением к agile методам (в силу более коротких циклов и активного изменения приоритетов по ходу работы).