Archive | September, 2009

Индикатор плохого дизайна

author: böhringer friedrich, http://commons.wikimedia.org/wiki/File:Seefrosch01.JPG

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

Бывают моменты, когда приходится прилагать много усилий для написания теста очередной функции. Ты начинаешь писать тест и его код разрастается до невиданных размеров или ты стопоришься на том, что не знаешь, как “замочить” или “застабить” функцию/класс. И тут начинается колдовство и просыпается изобретательность, которые приводят к тому, что коллега, просмотрев тест, с трудом понимает, что в нем происходит.

Если у тебя сейчас так, то тебе нужно остановиться. Убери руки с клавиатуры и взгляни на свою систему. Возможно тебе стоит заменить наследование композицией? Возможно твоя функция берет на себя слишком много обязанностей? А может у тебя слишком много зависимостей? Подумай, что мешает тебе написать простой тест?

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

Read full storyComments { 2 }

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 }