Archive by Author

“Самоорганизующаяся” – что это значит?

Общаясь вчера с коллегами из московского отделения PMI обнаружил категорическое непонимание того, что же такое самоорганизация команды. Ситуация усугубляется тем, что внятного определения в общем-то никто не предлагает, а следовательно – остается простор для творческого “тэйлоринга”. Через это пышным цветом расцветают следующие мифы:

  1. Если кто-то команду собрал, то она не самоорганизующаяся. Ну типа самоорганизующаяся команда – это когда какие-то парни сами взяли и организовались в команду. Это часто так, но это не всегда обязательно. Например толковый продукт менеджер создает самоорганизующуюся команду, чтобы пожать преимущества ее использования. Толковый лидер может подбирать себе единомышленников для создания продукта. Когда они собрались и запустились – появилась самоорганизация. От того, что у истоков  создания команды стоит кто-то – она не перестанет быть самоорганизующейся.
  2. Самоорганизующаяся команда предполагает отсутствие контроля и может привести к недостижению бизнес-целей. Вот эта штука меня насмерть убила. Из чего следует – вообще не понял. Команда создается именно под достижение этих самых бизнес-целей, они постоянно обновляются и их достижение измеряется. Вот способ достижения бизнес-целей – остается на усмотрение команды. Команда придумывает наилучший способ исходя из своего понимания своих сильных и слабых сторон, и именно в этом прелесть самоорганизации. Если “команда” “самоорганизуется” для того, чтобы делать исключительно то что ей нравится так как она считает правильным тогда когда ей этого не хочется – это не команда, это клика, одна из ошибочно называемых командой сущностей.
  3. В самоорганизующейся команде нет лидера. Как правило самоорганизующася команда выстраивается вокруг лидера, у которого есть понимание целей и способов их достижения, которые остальные разделяют. Таким образом у них возникает дискуссии только о том, как лучше воплотить в жизнь это самое общее видение. Да, иногда собирается подборка товарищей, которые бесконечными терками выводят общее видение – но это не есть непременное условие, при наличии страстного компетентного лидера создание команды происходит гораздо бодрее.
    Вместе с тем общими усилиями было восстановлено понимание того, что же такое “самоорганизующаяся команда”. По появлению видео – рекомендуется к просмотру. Жаль не снимали на камеру – как всегда дискуссии и ответы на вопросы гораздо интереснее презентации.
Read full storyComments { 1 }

Что чем называется?

А вот камрад Максим Дорофеев из Касперского мне сегодня презентацию показал – я бился в конвульсиях от восторга. Особенно звуковой ряд удачно использован.

Еще Лео Лознер говорил: “Ребята, осторожнее со словами – слова имеют значение”.

Read full storyComments { 3 }

“Хрен и палец – это одно и то же!”, или тэйлористам аджайла посвящается

clip_image002

Любопытное дело – среди людей, которые попробовали работать в true agile компаниях типа FogCreek, не остается равнодушных – и загадочным образом всем нравится! Но есть другой лагерь – тех, кто однозначно уверен, что аджайл – это сакс, новое модное слово которое прикрывает все те же старые добрые приколы – овертайм, выходы в субботу, меняющиеся требования, “давай-давай!” менеджеров. Ну то есть это тот же бегемот – просто раньше показывали только морду, а теперь открыли вид сзади-сбоку и его узаконили. И этих людей – почему то не в разы, а на порядки больше. Как это получается? Ответ простой: благодаря тому что аджайл – это фрэймворк, а не методология. Как это наносит предательский удар по аджайлу? Почитайте вот эти рассуждения, и затем давайте пройдемся по рассуждениям автора и разберемся, как очередные благие намерения становятся дорогой в ад.

(more…)

Read full storyComments { 44 }

OneNote® для требований в Agile

Мне как Product Ownerу ужасно нравится agile. Не в последнюю очередь – благодаря подходу к спецификации – больше мне не надо долго и мучительно объяснять аналитику, чего я хочу, потихоньку зверея от его тупости; c надеждой подымать очи в горе при вопросе “ты уверен что он понял тебя правильно?”; ждать неделю пока появятся первые вайрфрэймы чтобы исчиркать их ручкой и неделю ждать очередной версии…

Scan10010 Потому что требования я пишу сам. И вайрфрэймы рисую сам. Кроме тестировщика мне никто не нужен. Я даже завел себе мега-девайс который сразу сканер-принтер, чтобы можно было сканировать шедевры карандашного творчества. Даже сканер выдал аналитикам чтоб сканировать всякого рода шедевры. (Им так понравилось, что теперь назад не отдают – говорят “ты сказал что подарил”. Ну я не спорю – раз хорошее дело понравилось, то даже если и не говорил – лучше оставить. Надо им еще цветной принтер подарить – чтоб сториборды печатали). Но с бумажными вайрфрэймами и сторибордами есть одна неприятность…

(more…)

Read full storyComments { 5 }

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

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

(more…)

Read full storyComments { 8 }

Managing Customer Expectations (или когда говорить “нет”)

Вот 5 минут назад обсуждал с камрадом ситуацию, которая наверное для многих знакомая – есть команда, работает на Заказчика 2недельными спринтами, 6 человекIMG_0278, соответственно сухой остаток – 480 часов рабочего времени в спринт. Вот отработали очередной спринт, посмотрели сколько отрепортали часов. Получается 628. Это означает, что рабочий день каждого увеличился примерно на 2,5 часа – это если нагрузка была распределена параллельно. Как часто нагрузка распределяется равномерно? Ага, примерно когда рак на горе свистнет. Это значит, что некоторые камрады сидели на работе по 12-14 часов. При этом – сюрприз! – Заказчик не только платит всего за 480 часов, но и еще регулярно команду “прикалывает” – мол, плохо работаете, товарищи, давайте напрягитесь, а то вот отдам вам контракт малазийцам…И так каждый спринт. Я должен принимать работу регулярно? Забудьте! 40 Hrs workweek? Ничего про это это не знаю! Команда как главная ценность? три раза ха-ха! Что в такой ситуации делать?

(more…)

Read full storyComments { 15 }

Почему меня настораживают MacBookи, или кого не должно быть в команде

Вообще я давний пользователь Macовской техники – во времена оны я трудился наверное на одном из первых “переносных” маков в Украине, и несказанно радовался четкости монитора и удобству интерфейса. Сейчас вполне довольный пользователь iPodа. Office 2008 на маке мне нравится гораздо больше своего аналога на пэцэ – особенно Outlook, виджет для рабочего стола просто drives me crazy. То есть я вообще вполне лояльно отношусь к брэнду и его продукции, хотя сам и не перешел.

Но вот люди, которые его пользуют у нас и их цели – они меня серьезно удивляют.

Встречался на днях с дизайнером – надо заделать дизайн к новому блогу, который я собрался заделать осенью. Камрады, которые вызвались делать, в дизайне ни ухом ни рылом о чем сразу предупредили. Возникла идея взять на время внешнего чувака, соответственно решили встретиться и посмотреть на предложенного камрада. Пришедший чувак меня сразу несколько насторожил – уж слишком броско одет (наблюдение из жизни: как правило если кто не может быть уникальным в творчестве – самовыражается “уникальным” через одежду). Чувак меня не разочаровал – зажигал напалмом. (more…)

Read full storyComments { 9 }

Про UML, холивар и последующий холишит

кот, дрыхнет Сорри, долго молчал – боролся с подобранными помойными котами: болели всем чем можно болеть, глисты там самое безобидное. Сейчас вроде остался только энтероколит, так что снова зачесались руки и появилось время сказать слово. Собственно, говорю – о наболевшем.

Когда писался agile manifesto, все были утомлены фанатиками имеющихся на рынке методологий. Структурный подход и имеющиеся методики стали настолько тяжелыми, что рухнули практически везде. Но надо помнить, что изначально они были вполне работоспособными. По ним жили десятки лет, но однажды поняли, что накладные расходы на эти методологии слишком велики. Такова судьба любой хорошей методики – она обрастает деталями, диаграммами, чеклистами, чтобы разобраться во всем этом деле пишут инструкции, инструкции сводят в подборки документов, подборки перерабатывают в процессы – и оба-на! мы получили очередную мегатяжеловесную Методологию, доведенную до идиотизма детализацией и оснащенную армией фанатиков, которые борются уже не за успех проекта, а за чистоту канона – чтоб все было Как-Завещал-Великий-Ленин, и если проект от этого загнулся – тем хуже для проекта.

Похоже, то самое начинается с аджайлом. Мы недавно запускали новый проект. Проект со старта имеет довольно развесистую структуру. Представить графически эту развесистую структуру – довольно сложно. Однако для релиз плэннинга надо не только структуру представить, но и рамки очертить. Мы использовали для этого UML и Sparx Enterprise Architect. UML потому что юзкейс-диаграммы все с грехом пополам читают, Sparx – потому что удобно рисовать и все отрисованные юзкейсы можно поддерживать в синхронизации с Visual Studio Team System 2008, который используется на проекте. Соответственно затем пользуясь интеграцией Team System + Microsoft Office делаем релиз плэннинг – хоть в Excel, хоть в Project.

Подход исключительно прост, польза для проекта очевидна, удобство для команды знакомой с UML и Sparx – тоже очевидно. Рассказал про это камрадам в Питере. Что тут было! ЕСЛИ ВЫ ИСПОЛЬЗУЕТЕ UML, ЗНАЧИТ У ВАС НЕ АДЖАЙЛ! ИБО В АДЖАЙЛЕ СКАЗАНО – НИКАКОЙ ДОКУМЕНТАЦИИ! Дорогие камрады, это распространенное заблуждение. На самом деле:

  1. Если посмотреть множество диаграмм с примерами, хотя бы из книжек Бека или специальных изданий, то становится ясно – диаграммы вообще и UML-диаграммы в частности как визуальное средство коммуникаций очень ценились отцами-основателями.
  2. Аджайл не требует отсутствия документации. Если бы требовал – фотографии доски тоже были под запретом, потому что это хоть и кривая, но тоже документация. Аджайл требует минимальной и достаточной документации – и UML-диаграммы (при условии что у вас их все умеют читать) отлично эту задачу решают.
    С частным вопросом разобрались легко, но этот частный вопрос – следствие попытки превратить аджайл в некий догмат, довести его до абсолюта, и все что противоречит догмату – объявить неверным. Затем – требующим искоренения.
    Коллеги, напоминаю: изначальный посыл аджайла – ставка на умных людей и их умение думать, а не на процесс. То, что хорошо для проекта – это и должно входить в вашу методику. Все остальное – от лукавого.
Read full storyComments { 4 }

Самый непонимаемый принцип в Agile Manifesto

Вот есть грузовик. Принципиальная схема грузовика проста: есть кузов, который перевозит груз. Перевозка груза происходит потому что к кузову приделаны колеса, которые крутятся и передвигают корпус. Колеса крутятся потому что их вращает двигатель посредством вращающегося вала. Двигатель вращает вал так как в нем сгорает бензин, который при сгорании толкает поршень, который сообщает движение валу. Поэтому бензин сгорает, толкает поршень, колеса крутятся, кузов движется, возникает польза – передвижение груза. Каждая деталь – на своем месте, вместе они образуют концептуальное единство.

(more…)

Read full storyComments { 11 }

Agile Q&A – вопросы, которые заданы много раз

Уважаемые коллеги, 28го мы провели свой первый тренинг. Несмотря на сессии вопросов и ответов на кофе-брейках и обеде и дополнительную сессию после тренинга, осталось много неотвеченных вопросов.

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

«А когда же agile таки неприменим?»
(more…)

Read full storyComments { 2 }