Askhat's Site

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

Началось с трудом. На конференции Agile Labs поспорили со Славой Панкратовым о том, что круче - Agile и не-Agile. Сам спор, по-моему, не получился. Дело в том, что предмета спора нет, мерить скорость круглых коней в вакууме бессмысленно. Очень напоминает споры в детском саду, кто круче - каратист или боксер.

Сравнивали мы, между прочим, эффективность RUP и Agile. Глупее сравнения не придумаешь. Попробуйте ответить, что длинее - деревянная палка или железная?

Или вот Славино "Agile не работает в случае X". У меня достаточно богатый опыт, и я могу привести с одинаковой легкостью примеры ЗА и ПРОТИВ. Что из этого следует? Да ни черта не следует :-). Ну типа поговорили. Ну типа да, иногда не работает. С другой стороны, есть примеры что работает. Классно. И что теперь?

Scrum в больших проектах. Атака - "Деревянных палок длинее самого дерева не бывает". Ответ - "Мы можем составить несколько деревянных палок подряд". Обалдеть, как умно :-). Изменение требований. Атака "деревянные палки более гибкие". "Дамаская сталь погибче ваших будет".

Да взять те же юнит тесты. Всем понятно, что Agile не узурпирует право на юнит тесты? Ну да, я сам их писал в эпоху до Agile. Ну вроде как всем понятно, что они нужны и что с ними лучше. Ага, в теории. А на практике возникает куча проблем при внедрении в конкретных случаях. А какой смысл спорить, Agile или не Agile у нас, если мы не можем внедрить юнит тесты? Причем вне зависимости от использования методологии не можем, просто контекст проекта такой "невезучий"?

Или вот Слава спрашивал про статистику успешных проектов в Agile и Scrum. Кажется, что наличие статистики очень важно. Если успешных проектов Agile больше, то он круче. Кстати, статистика есть. Но, несмотря на перевес Agile - я ей не верю. На успех проекта влияет пицоттыщ факторов, из которых использование методологии где-то в пределах прогрешности измерений. Да, наверное, если мы возьмем проект и решим, какая методология лучше, это повлияет на успех. Но штука в том, что "хороший" RUP лучше, чем "плохой" Agile. Так что мы сравниваем, коллеги?

В течении всего спора со Славой я чуствовал, что происходит бред, мы говорим не о том, это все бессмысленно. Так вот, почему я говорю, что что-то щелкнуло в голове :-). Я понял важную вещь.

В рамках развития любой системы происходят смены эпох. Новое время приносит новые практики, которые добавляются к предыдущим и обогащают их. "Теперь мы и ЭТО умеем." Вот этот новый мир, в котором есть важные новые методы и обретает новое название.

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

Так что, хотите вы этого или нет, Agile пришел. И он принес новые методы. И их нужно уметь использовать. Хотя бы чтобы не выглядеть идиотом :-).

И ключевое слово тут - УМЕТЬ :-)

Так вот, это важное понимание меня расслабило :-) Нет никакого Agile, да и не было никогда. Как не было RUP и CMMi и прочих страшных слов. Есть более и менее современные подходы к решению проектных проблем. И не дайте всему этому хайпу себя обмануть :-)

Моя презентация с Agile-Labs про процессные заболевания и методы их лечения.



be ag:)e

Вчера состоялся круглый стол по методологиям на проекте Happy-PM. Там принимали участие Митя Башакин, Сергей Архипенков и ваш покорный слуга, Асхат Уразбаев. Что характерно, все трое в разное время работали в Luxoft :-)

По-моему, получилось интересно.

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

Но в общем, мне очень понравилось. На сайте Happy-PM уже доступна аудио-запись круглого стола.

А Саше Орлову большой респект за организацию и проведение :-)

Слушайте, у вас бывает так, что вам задают вопрос, а вы не знаете, что ответить? Вроде вы спец, и весь из себя такой умный, и тему знаете досконально, а ответить трудно. Я приведу пример таких вопросов:

• Должны ли мы слепо следовать всем правилам Scrum?
• Какое покрытие тестами достаточно?
• Может ли быть Product Owner быть одновременно Scrum master'ом?
  

Давайте первый вопрос возьмем. Про возможность менять Scrum под себя. Любой здравомыслящий человек, обладающий хоть каким-то опытом в разработке, ждет ответа "ДА". Если я отвечу "НЕТ", про меня "сразу станет все понятно". Я стал ограниченным, зашоренным, не знающем реальной жизни. А Scrum - это религия, все Agile Coaches - ее апологеты, ее цель - снять бабло и т.д.

Теперь представьте, что вопрос задал менеджер, ни разу не работавший в цикле коротких итераций, прочитавший про Scrum одну статью.

Сценарий №1. "ДА!!!".

"Ну, как я и предполагал, мы можем поменять Scrum под себя. Что там есть в статье? Итерации... Явная глупость номер один - фиксировать их длину. Разумеется, длина итерации должна определятся бизнес необходимостью. Кроссфункциональность сразу в сад. У нас глубокая специализация по коду, так что все равно не выйдет. Так... Scrum Master... Им должен быть член команды? Ну это же НЕ ТЕ ЛЮДИ! У них не получится! Я сам стану Scrum Master'ом. Burndown Chart... Ладно, порисую пару недель, от меня не убудет. Ну все, поехали!"

Через одну-две итерации менеджер убедится, что Agile - херня полная. Первыми падут daily scrums (ежедневные пятнадцатиминутные митинги). Их никто не любил! Приходилось загонять людей туда силой. Потом - burndown chart. Менеджер рисует его, но им никто (даже он сам) не интересуется. Получится такой инструмент write-only. Следующая жертва - итеративность. К концу второй или третьей итерации окажется, что работа еще не сделана. Итерацию продлят. Некоторые итерации будут длиться вдвое больше, чем запланировано. Ну и так далее (лень печатать, если интересно - могу расписать дальше).

У менеджера НЕТ своего опыта. Scrum в некотором смысле и так сбалансирован и минимален - дальше сжимать его просто некуда.

Когда Шваберу задают такой вопрос, он сдвигает брови и говорит "Do Not Change Scrum" :-)

Теперь представьте, что вопрос задал Scrum Master команды, работающей в Agile несколько месяцев. Допустим, я отвечаю ему "НЕТ!!!".

Сценарий №2. "НЕТ!!!"

"Эх, у нас три человека, которые и так постоянно общаются друг с другом. Я думал, Daily Scrum нам не нужен...".

"Наш PO уходит в декрет. Эх, а я хотел бы побыть за нее какое-то время ..."

"У нас итерация в одну недельку. Мы почти всегда укладываемся в нее. Эх, я думал, нам не нужен burndown chart"

Видите, команда опытная, самоорганизованная. Она ИМЕЕТ ПРАВО пренебречь правилами или ввести свои собственные.

Интересная статья на InfoQ. Великие и ужасные гуру Spolsky и Bob Martin (Uncle Bob) спорят о необходимости писать тесты. Разумеется, великий мастер Uncle Bob настаивает на написании тестов. А Spolsky уверяет, что не везде они так уж необходимы. Он указывает на затраты времени на написание и на необходимость тратить время на исправление тестов при небольших изменениях кода (хрупкость тестов). Uncle Bob утверждает, что все это потому, что некоторые (некоторые) просто не умеют писать OO-код. По мнению Spolsky, SOLID принципы ООП не являются agile и вообще, выглядят ужасно бюрократичными и придумал их тот, кто и кода-то мало написал. Bob не стерпел. Холодная стариковская кровь вскипела. Он указал, что пишет, писал и будет писать много кода, и большая часть его Test First.

Как водится, старики быстро перешли на личности. Uncle Bob посетовал, что всякая тварь тут будет рассуждать что такое Agile в присутствии людей, которые участвовали в создании Agile-манифеста.

В общем, там много еще стаффа, почитайте :-)

А я вот мучился мучился и вспомнил, что это все мне напоминает:

Ученик спросил великого мастера программирования Летящего Пера: "Что превращает тест в юнит тест?"
Великий мастер программирования ответил: "Если он обращается к базе, значит он не юнит тест. Если он обращается к сети, значит он не юнит тест. Если он обращается к файловой системе, значит он не юнит тест. Если он не может выполняться одновременно с другими тестами, значит он не юнит тест. Если ты должен делать что-то с окружением, чтобы выполнить тест, значит он не юнит тест."
Другой мастер программист присоединился и начал возражать.
"Извините, что я спросил", — сказал ученик.
Позже ночью он получил записку от величайшего мастера программиста. Записка гласила: "Ответ великого мастера Летящего Пера прекрасный ориентир. Следуй ему, и в большинстве случаев не пожалеешь. Но не стоит застревать на догме. Пиши тест, который должен быть написан."
Ученик спал хорошо. Мастера все еще продолжали спорить глубокой ночью.

Путь Тестивуса

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

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

В пятницу-субботу на прошлой неделе закончился тренинг "Scrum Master: управление командами в Agile".

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

Это был тренинг для людей, которые УЖЕ работают по Agile и ТОЧНО знают свои проблемы. Я постарался сосредоточить все знания, нужные скрам-мастеру в одном двухдневном семинаре.

В первый день мы занимались тем, что со временем я хочу превратить в строгую науку :-) - дизайном процессов разработки ПО. Рассматривали разные кейсы, обсуждали проблемы и придумывали их решения. Мы учились придумывать ХОРОШИЕ и РАБОТАЮЩИЕ процессные решения. Это те, которые работают сами по себе, без необходимости постоянного вмешательства.

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

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

В общем, мне понравилось, хотя я и устал ужасно за эти 2 дня :-).

Альбом: Тренинг-ScrumMaster-13.02.09

Всем привет, коль уж Асхат вспомнил историю про Agile по русски = "Мочим код и фиксим баги", выложу-ка интересную табличку Agile vs Code&Fix, которую я некогда увидел в интернете и сохранил у себя в записях.

На семинаре Асхата, в пятницу-субботу обещался быть сам Алекс "happy PM" Орлов, самый человечный человек :-). Обещал излить на этом семинаре излишки мыслей и опыта на тему "Работа в распределенных проектах".

Подсмотрел у peeplevarreh ссылку на пост уважаемого Рона Джеффри. Интересно, что он пользуется манифестом как определением Agile. Да и у нас многие согласны с этим.

Мне кажется, это не совсем так... Давайте вспомним.

Появились люди, которые "uncover better ways of developing software" - обнаружили лучшие способы разработки ПО. Если грубо, то как-то внезапно оказалось, что если работать короткими итерациями, дружными веселыми командами, писать хороший код, да еще и общаться с заказчиком потеснее, то и результат получится получше, да и работать будет поприятнее. Собрались методологи вместе да и написали "Манифест гибкой разработки", где собственно и изложили основные мысли. Идеи затем начали проповедовать на всех углах.

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

Тут многие наши начинают тормозить, глядя на западных товарищей. Что же тут особенного, вашу маму? Какой смысл во фразе "working software over comprehensive documentation"?

А все дело в том, друзья, что Манифест (как и, наверное, все манифесты) сформулирован не ЗА какие-то идеи, а ПРОТИВ. Иначе говоря, он направлен против каскадной разработки. Против waterfall'а, засилие которого мы наблюдали в западных странах еще недавно.

У нас же, в силу относительной молодости отрасли с одной стороны, и принципиального отсутствия развитой индустрии обучения большинство проектов работало в модели Code&Fix. Мочим код и фиксим баги - вот и вся метода.

Так вот, в приницпе весь манифест неплохо подходит под этот метод разработки.

• Individuals and interactions over processes and tools.
  

Все в порядке, процессов у нас нет!

• Working software over comprehensive documentation.
  

Документация? Эээ...

• Customer collaboration over contract negotiation?
  

Да-да, у нас все по понятиям!

• Responding to change over following a plan.
  

План? Кажется я писал его месяца 4 назад, надо бы отрыть...

Вот и получается, что проект в стиле "Мочим код и фиксим баги" неплохо подходит под определение Agile подхода. Хотя на деле не имеет с ним ничего общего.

Давайте сегодня разберемся чем занимается P.O. более детально.

Всю его деятельность можно поделить на три направления:

• Требования заказчика
• Успех проекта
• Организация совместной работы.

Работа с требованиями

В первую очередь, Product Owner в Scrum ответственен за понимание потребностей заказчика. От части его роль можно воспринимать, как роль Заказчика - человека, который разрабатывает концепцию проекта(Product Vision) и доносит команде разработчиков список с некими приоритетами по той или иной фитче. P.O. создает product backlog и обновляет его на регулярной основе: добавились новые требования, разработали новую фитчу, улучшили старую - это все отражается своевременно, до начала следующей итерации в backlog'e. В добавок, P.O. приоритезирует product backlog так, что бы наиболее важные фитчи всегда находились в текущей работе.


Отслеживание успеха проекта

Ответственность за успех проекта является второй неотъемлемой областью интересов Product Owner'a. Что это означает? Это означает ответственность за достижение цели проекта и предоставление некоторых финансовых показателей, как например Возврат Инвестиций (ROI - Return on investment). Product Owner принимает решения о том какую функциональность будет разрабатывать команда, принимает решение о дате релиза и бюджете проекта исходя из потребностей заказчика, рынка и ROI. Так же Product Owner занимается и поддерживает в актуальном состоянии План выхода релиза и Отчетность по всем релизам.


Коллективная работа

Последняя, но не менее важная задача P.O., это организация коллективной работы. В чем это проявляется? P.O. должен стремиться к тому, чтобы все решения принимались сбалансировало учитывая интересы как бизнеса, так и разработки, что требует плотного сотрудничества с командой и всеми заинтересованными лицами от первого спринта до выпуска релиза:

• Product Owner активно общается с заказчиком
  
• P.O. и команда вместе детализируют требования
• P.O. отвечает на вопросы, всплывающие во время спринта
• P.О. подготавливает Планирование спринта, максимально детализируя задачи, объясняет причины причину приоритетов, отвечает на вопросы всплывающие по ходу планирования
• P.O., принимает результаты, руководствуясь совместно выработанными критериями "Сделано" (Definition of Done, об этом в следующих постах)

Все это требует максимальной кооперативной работы со всеми участниками проекта. Если ваш P.O. обладает этими качествами, то в проекте будет организован предсказуемый, текущий в нормальном ритме процесс разработки. Думая о том какого человека взять на новую должность, подумайте о ком нибудь человеке из маркетинга, или выберите Project Manager'а, который лучше всего понимает продукт не только с технической стороны.

Новый мегатренинг!!!
Сегодня я хотел бы немного рассказать о новом тренинге. Он раскрывает секреты управления софтверными продуктами в условиях постоянных изменений.

Совсем недавно мне позвонили из одной крупной софтверной компании. После внедрения Scrum в компании начались конфликты. Руководитель жаловался, что разработчики стали оспаривать решения менеджмента по разработке той или иной фитчи в итерации. Оказалось, что переход на итеративную и инкрементальную разработку просто обострил существующие проблемы! Менеджемент ставит задачи, которые оказываются не нужны с точки зрения бизнеса. :(

Разработка обвиняет менеджмент в неадекватности. Менеджмент, в свою очередь, обвиняет разработку в неправильном исполнении. Потеряно время команды и деньги компании. А мы хотим что бы продукт зарабатывал :)!

Часто ли вам приходилось работать в Agile проектах, где общая цель итерации не совсем ясна?! В проекте, в котором есть Backlog, но люди, которые участвуют в развитии продукта не понимают целей релиза. Как оказалось, это происходит во многих компаниях, как в малых, так и в компаниях с многомиллионными бюджетами. Дело в том, что многие фразу "Конец итерации = законченный и рабочий продукт" понимают как, написание "идеального" стабильного кода к концу итерации, забывая об истинных бизнес-целях продукта.

Я бы хотел, чтобы мы не совершали таких ошибок.

В каждом проекте должно быть понимание для чего и для кого продукт разрабатывается. Для этого создается Концепция продукта или Product Vision. Product Vision - это документ, описывающий путь по которому должен развиваться продукт с точки зрения бизнеса, доносящий смысл разработки до всей проектной команды. Концепция должна быть понятна и донесена каждому от Product Owner'а и Команды до заказчиков и всех заинтересованных лиц. Наличие правильно сформулированного Product Vision'a является одной из составляющей успеха проекта.

На нашем супер-тренинге :) одной из тем, которую мы подробно рассмотрим, будет написание Product Vision'a.

Мы поговорим о том, как его написать так, что бы этот документ был полезным и эффективным в проекте.

Постараемся научиться в первую очередь думать о проекте с точки зрения бизнеса.

Это совершенно новый тренинг. Мы еще не разу за время существовании компании не погружали вас в особенности работы продуктовых команд в Agile и готовы поделиться секретами :). Тренинг будет интересен тем кто, так или иначе связан с менеджментом софтверных проектов.

Ждем всех кому не чужда любовь к разрабатываемому продукту:).

Программу тренинга можно посмотреть здесь

Записаться на тренинг, можно здесь

Вести его буду Я, Никита Филиппов.

Давать интервью приятно. Вот обычно, чтобы прослыть хорошим человеком, надо уметь слушать собеседника. А тут все наоборот - тебя спрашивают, твое мнение интересно. Ты хмуришь лобик и складываешь губки бантиком. Ты звезда.

Все портит результат. Слушаешь потом свой голос и думаешь - господи, я не знаю этого человека! Совсем не мой голос. Читаешь текст интервью и опять же думаешь - что же так сумбурно-то получается? Хочется кое с чем поспорить. Ну или добавить.

Это я вот чему. Я, кажется, не писал, что я давал интервью проекту Happy-pm. А Александрeagleson Орлов лично (лично!) его у меня брал. Самое время об этом написать :-).

В основном это ответы на стандартные вопросы новичков. Вот например, всех интересует, где Agile не работает. Или кто круче - Scrum или XP. Или как поделить деньги.

Содержание такое:

• Мега-плюсы гибких подходов
• Что делать, когда команда разнится по компетенциям?
• Командная ответственность
• Долгосрочное планирование
• Тестирование в Agile
• Как правильно награждать команду деньгами?
• Agile в распределенных командах и проектах
• Как продать Agile заказчику
• Кто круче - Scrum или XP?
• Основная вещь, мешающая парному программированию
• Когда Agile применять не надо
• Что почитать по Agile?

В общем, есть первая часть интервью и вторая. Там есть mp3 и текст.

А eagleson персональное спасибо :-)

Видео теперь на сайте:

Введение в непрерывную интеграцию, Андрей Сатарин
Каким должно быть приёмочное тестирование в agile-проектах?, Алексей Баранцев
Тестирование в Agile проектах, Илья Гаврилов
Unit testing with XML, Дмитрий Всехвальнов
Безудержный Refactoring: как не убиться об стену, Андрей Бибичев
Тестирование Web 2.0., Владимир Колесников

Альтернативное видео и отчет от конференции от компании CustIS здесь

Видео с Физерсом будет попозже.

Новый мегатренинг!!!

Называться он будет "Scrum Master: управление командами в Agile". Мы решили свести вместе весь наш опыт по работе с командами в разных компаниях в одном мегатренинге.

Это продвинутый тренинг для тех, кто занимается или собирается заниматься внедрением Agile. Фактически, тренинг предназначен начинающим Agile Coach. Эх, я был счастлив, если бы такой тренинг мне провели несколько лет назад, когда я начал заниматься внедрением Agile! :-)

Мы не обещаем "10 Простых Шагов Внедрения Идеального Agile" или чего-то подобного, речь скорее пойдет о том наборе разнообразных навыков и знаний, которые уберегут вас от болезненных ошибок и при этом помогут правильно оценивать эффективность своей работы.

Самый главный навык, которым мы займемся - будем учиться мыслить "процессно" (мой термин по аналогии с "физическим мышлением"). Мы построим в голове модели, которые позволят понимать, какое решение надо принять в той или иной ситуации как оно повлияет на команду в кратко- и долгосрочной перспективе и как сделать внедрение решения максимально эффективным.

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

Маленький Disclaimer: это НЕ официальная сертификация на Scrum Master. Однако вы получите сертификат от нашей компании :-). На самом деле будет даже ДВА сертификата. Один вы получите за то что "прослушали" тренинг. Второй сертификат вы получите только если на практике докажете, что реально применяете полученные знания в жизни. Для этого нужно будет проделать кое-какую работу в своей компании/проекте и дать нам обратную связь.

Вести тренинг буду я, Асхат Уразбаев.

Жду вас на тренинге.

Содержание тренинга тут.
Записаться на тренинг можно тут

Записавшимся до Нового Года новогодняя скидка 10% :-). Двухдневный тренинг пройдет в Москве 13-14 февраля.

Материалы конференции в виде презентаций теперь можно найти на нашем сайте:

Введение в непрерывную интеграцию, Андрей Сатарин [с handouts]
Каким должно быть приёмочное тестирование в agile-проектах?, Алексей Баранцев
Тестирование в Agile проектах, Илья Гаврилов
Unit testing with XML, Дмитрий Всехвальнов
Безудержный Refactoring: как не убиться об стену, Андрей Бибичев
Тестирование Web 2.0., Владимир Колесников
Презентация Майкла Физерса будет опубликована немного позже

Читал тут eagleson про мотивацию бонусами и не могу молчать :-). Смысл статьи в том, что если вы хотите удержать персонал, вам нужно платить им бонусы, но не сразу, а потом (когда-нибудь). Тогда они не будут от вас уходить (хоть вы их ногами бейте), а будут ждать бонуса.

Ну вот, допустим, у вас есть много денег и вы хотите вложить их повышение производительности ваших сотрудников.

Есть один простой способ. Платите сотруднику пропорционально производительности. Большой выхлоп - много денег. Малый выхлоп - мало денег. В соответствии с теорией Павлова у сотрудника выработается условный рефлекс и он будет брызгать слюной к каждой выплате.

Работает ли это? КОНЕЧНО! С токарями-фрезеровщиками, дворниками, продавцами и даже немного с учителями английского. А вот с программистами НЕ РАБОТАЕТ. И проблемы тут две.

№1. Проблема измеримости выхлопа. Нету линейки для программиста. Аршином общим не измерить. У них особенная стать. Ведь что такое производительность программиста? Кол-во строчек кода за единицу времени? Бред! Копипейст или просто выбор инструментов и подходов может породить практически любое кол-во. Кол-во багов? Не ошибается тот, кто ничего не делает. Ничего не пишем - нету и багов. Кол-во исправленных багов? Так ведь никакого героизма в исправлении багов нет. Смысл в том, чтобы НЕ ПИСАТЬ багов. Не хватало еще поощрять за их исправление! Задачка на полчаса - написать утилиту, которая путем внесения багов в код и исправлением их после репорта от тестера максимизирует ваш бонус, хе хе :-).

В общем есть только один инструмент - произвол менеджера. Менеджер - это такой мудрый чувак, который знает, кто и как работает. А как он знает? А в этом и есть тайное знание менеджера и за это он получает бабло. А как он меряет своих чуваков? У него есть ОЩУЩЕНИЯ. Например, если вы менеджеру кажется, что вы тормоз, то вам выставят BE (below expectations). Или, например, сделают вам маленький КТУ (коэффициент трудового участия). А ведь иметь маленький кту стыдно... Или еще как-нибудь вам дадут понять, что вы тормоз. Это называется "предоставить фидбек".

И тут есть проблема №2.

Представьте, что у вас с вашим менеджером совет да любовь. Вам дали много денег (тем или иным способом) и вы садитесь за свой стол. Теперь вы, видимо, будете писать больше кода в единицу времени? Ну как же, вас же мотивировали! Раньше вам мало платили и вы нажимали на клавиши с ленцой, теперь такого вы не допустите. Стучать будете как стенографистка. Или может, теперь вы будете меньше багов делать? Да с чего вдруг?

В общем, эффект будет сомнительным. Мотивация деньгами действует полчаса. Как только вы похвастались жене в аське - ВСЕ! Вам уже МАЛО.

А вот если, например, вас лишили премии. Что характерно, вашего товарища Васю при этом поощрили. Вы, конечно, расстроитесь. Но в то же время как-то соберетесь, мобилизуетесь и будете СТАРАТЬСЯ. Да? Скорее всего - нет. Вы обидитесь на вашего менеджера (вы-то думали он ДРУК!) и вашим любимым сайтом отныне будет hh.ru. Но пусть даже это не так. Ваши чувства к мудрому руководителю не угасли! Вы почувствовали справедливость его слов и вашей целью отныне является то, чего хотел добиться Коля Остен-Бакен от Инги Зайонц - взаимности. Все лишние мысли - вон! Только работа. Остаемся по ночам. Пишем только качественный код (как, кстати, это делать по ночам?). И вот подходит к вам удачливый соперник Вася и просит помочь. Нет, вы не откажете. Вы не такой. Вы ему поможете - как только у вас появится время. То есть никогда.

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

А менеджер будет трагически говорить на ежеквартальных отчетах начальству: "Пора уже вам тщательнее подходить к подбору персонала! А то набираете сплошных безответсвенных уродов! Невозможно работать!"

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

А денег должно просто ХВАТАТЬ. Их уровень должен быть комфортным. Все остальная мотивация - неденежная.

Помимо того что к нам приезжает Майкл Физерс. Открывается секция докладов, в рамках Бесплатной конференции по инженерным практикам Agile - Agile Days.

Каждый выступающий, еще раз доказывает свой высокий статус в области Software Development и Software Engineering.

Если вы хотите стать докладчиком, вам достаточно написать нам письмо на askhat[at]agilerussia.ru

Как стать докладчиком?

Заявка должна содержать следующую информацию:

1. Название выступления;
2. Краткую информацию о выступлении;
3. Информацию о том, где можно использовать материалы Вашего доклада и кому он может быть полезен;
4. Имя докладчика, контактную информацию;
5. Краткую информацию о докладчике.

Буду рад ответить на Ваши вопросы!