Levitra online Vicodin Online Propecia online

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

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

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

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

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

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

Об авторе

Денис Петелин
Денис Петелин

Успел попробовать себя во всех ролях софтверных проектов – от разработчика до владельца компании и Заказчика. Поскольку во всех ролях работал успешно, имел востребованный опыт, который передаю другим. Сейчас - веду здоровенный образовательный проект и работаю над разработкой двух софтверных продуктов - системы управления обучением и инструмента для управления agile-проектами.


Добавить комментарий

Take a moment to comment and tell us what you think. Some basic HTML is allowed for formatting.

You must be logged in to post a comment. Click here to login.

RSS комментариев Комментарии:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Не нашли ответа в комментариях? Воспользуйтесь листом рассылки сообщества Agile.by. Подробнее о листе рассылки вы можете прочитать здесь. Или просто послать свое сообщение на адрес: agile-belarus@googlegroups.com.


Наши партнеры и проекты: