InfoQ: Collaboration Over Contracts in Agile “Offshore” Outsourced Development

Посмотрел давеча презентацию Craig Larman.

InfoQ: Collaboration Over Contracts in Agile “Offshore” Outsourced Development

Первое, что понравилось, что он сумел в полтора часа вложить столько аспектов взаимодействия с offshore командами.

Сюда вошли и общие принципы agile и сугубо технические вопросы и даже типы payment.

Передаю горячий привет своему Project Manager. Андрей судя по всему твоя роль весьма сомнительная. И даже страдает Transparency. Дело вот в чем, исходя из того что Feadback мы слышим от Customer не так часто, а если и слышим то в основном положительные отзывы, то у нас или все хорошо или не совсем так, но в это верится с трудом, потому что РМ иногда приходит и говорит, а что нужно сделать чтобы вы работали в 2 раза лучше :) Craig говорит, что РМа не должно быть как такового и налаживать отношение должен Product Owner (PO) непосредственно с командой.

Где то на 44 ой минуте Craig говорил о тестировании и Acceptance Tests. Тут мне вспомнилась полемика с моим предыдущим тимлидом. Он говорил о том, что acceptance tests слишком долгие и их тяжело поддерживать. Одним из аргументов было то, что они неправильно написаны, но как мне кажется все зависит от сложности flow и проекта в целом. Единственное в чем я твердо уверен, так это то, что они должны делаться и максимальное количество из них если не все должны быть автоматизированы. Spec by Example вам в помощь. В конце концов это подтверждение того что вы имплементировали именно то, что от вас хотел заказчик.

Хорошо что Craig затронул тему о передаче знаний (Knowlage transfer). Это очень важно для offshore teams. Следует взять на заметку Domain and Vision Workshops. Потому как офшорные команды должны разбираться в доменной области и видеть big picture, иначе они превращаются обезьянок за клавиатурой.

Очень понравилась рекомендация не навязывать дизайн и архитектуру со стороны onshore. Давать возможность офшорным командам самим принимать решения в этих вопросах, иначе это очень разочаровывает. Ведь на самом деле предотвратить проблемный дизайн можно всегда с помощью Code Review и Design Workshop.

Напоследок, хочу отметить что Craig Larman удивительно всесторонне развитый и терпеливый человек и действительно имеет право давать такого рода рекомендации и мастер классы. У него богатый опыт как в управлении процессами, так и в непосредственной разработке программного обеспечения. Я это могу утверждать на основании того, что сам с ним 2 дня сидел вместе в паре и TDDировал :)

Ubuntu Natty Narwhal upgrade или как я провел сутки

Сейчас оглядываясь назад я себя чувствую уставшим. Я и подумать не мог, что затеяв upgrade на нетбуке своей жены я обреку себя на почти 24 часа пляски с бубном и googление.

Так вот, как видно из темы я решил заапгрейдится на более новую версию опреационки на Lenovo S12.

Сразу скажу, что у меня знаний в Linux администрировании на уровне пятиклассника.

Все шло хорошо, как по маслу пока не пришла пора перегружаться. Как оказалось после перезагрузки максимум что я увижу пустые обои на девственно чистом рабочем столе. Максимум что я мог делать это бездумно двигать курсором мыши елозя тачпад, менять рабочие зоны через Ctrl+Alt+PgDn|Up|Left|Right и наконец нажать на power увидеть чудо - диалог завершения работы ну собственно завершить работу или перегрузить это чудо.

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


Первое что меня обнадежило и не дало поднять белый флаг, это то что загрузка с LiveCD, происходит без потерь, кроме того мне удалось запуститься в recovery mode и увидеть Gnome Desktop (вместо Unity, которое в Ubuntu 11.04 по умолчанию).


Почитав дальше я понял что проблема с grub2 конфигурацией, и вообще с загрузчиком. Дело в том что когда-то давно когда я купил этот нетбук я поставил на него 3 операционки Ubuntu, Win7 и еще раз Ubuntu потому как не знал как вернуть загрузчик после того как его стерла Win7 :) (стыдно)


Загрузчик у меня был grub а не grub2, это я понял после того как начал применять инструкцию по восстановлению grub2 для своего grub. В итоге было решено сделать upgrade и загрузчику :) слава богу он прошел более не менее гладко благодаря вот этой статье, воспользовался я Boot-Repair тулзовиной.


Вернувшись к изначальной проблеме я начал пробовать разные варианты загрузки, манипулируя с linux boot line я пришел к выводу, работают 2 варианта
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"
и
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.modeset=0 xforcevesa"
Прописав один из вариантов в /etc/default/grub, выполнив sudo grub-update, и перегрузившись я наконец увидел Gnome


Вот немного теории которую я вытянул по nomodeset из этого ресурса. Последние ядра взяли на себя ответственность за конфигурацию video, вместо того чтобы это делал драйвер X Server. Одной из причин по видимому является появившаяся возможность заранее инициировать видиокарту и тем самым обеспечить более представительный процесс загрузки.


Итак проблема пустого десктопа была решена и я уже было вздохнул с облегчением как обнаружил новую (_|_). Пропал Wireless. И снова google нам помог, правда не сразу. Материала по поводу проблем с wlan в Ubuntu Natty навалом, и опять же не все было применимо для моей конфигурации железа.


Вот ресурс и ресурс которые мне в итоге помогли.

Первое что нужно, так это избавиться от загрузки модуля acer_wmi. Для этого
sudo rmmod -f acer-wmi

sudo rfkill unblock all 

rfkill list all
при этом wireless LAN должен быть

Soft blocked: no
Hard blocked: no


к сожалению у меня этого не произошло. Я обнаружил что у меня загружено 2 Wireless модуля: первый ideapad-laptop, а второй собственно тот который нужен brcmwl. Дело в том что я этот драйвер предварительно установил из предложенных проприетарных драйверов от Broadcom. Грохаем ideapad-laptop
sudo rmmod -f ideapad-laptop

sudo rfkill unblock all 

rfkill list all 

после этого Network Manager магически ожил.

Теперь для того чтобы эти манипуляции не делать при каждой загрузке системы кладем все ненужные модули в blacklist
echo 'blacklist ideapad-laptop'  >> /etc/modprobe.d/blacklist.conf
echo 'blacklist acer-wmi'  >> /etc/modprobe.d/blacklist.conf

также добавим

rfkill unblock all в /etc/rc.conf перед exit 0

Если вы игрались с opensource драйверами то нужно их также выгрузить

sudo modprobe -r b43 ssb wl
sudo modprobe wl 

и убедиться что они в blacklist

вроде все.

Как себя правильно разбудить

У меня большая проблема, думаю что у многих она есть. Я говорю об утреннем подъеме на работу. Хочу поделиться как я её для себя решил.

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

Так вот, а что есть просыпаться под хороший рок, подумал я.

У меня ноутбук с которого я в свое время снес нафиг Win Vista  и поставил старый добрый WinXP, а потом и вовсе перешел на Ubuntu.

создаем простенький скриптик


#!/bin/bash
export DISPLAY=:0 && vlc -f ~/Downloads/RadioROKS_256.m3u

Тут ключевой момент в переменной DISPLAY. Дело в том, что если не задать её vlc не понимает на каком X терминале запускаться. Таким образом мы указываем что мы запускаемся на локальном хосте в текущей сессии.

Берем scheduller заданий cron.

crontab -e

и настраиваем scheduller


# m h  dom mon dow   command
0 7 * * 1-5 bash ~/wake_up.sh # JOB_ID_1

сохраняем конфигурацию и просыпаемся каждый будний день в семь утра под RadioRoks.

А как вы просыпаетесь?

Об архитектуре и DAO в частности

Я тут вот о чем подумал.

Я позапрошлом и прошлом моем проектах использовались ORM (Object Relational Mapping). И почему-то архитекторы приравнивали их к DAO. Тоесть слой сервисов напрямую дергали ORM слой, составляли критерии или HQL в случае hibernate. Таким образом осуществлялось взаимодействие с базой.

Полное дерьмо.

И вот почему. Что проще, замокать DAO или Hibernate? я про тестирование сервисов в изоляции.

Что проще, один класс DAO за другим переписать (смотри паттен branch by abstraction) под iBatis или еще проще под pure jdbc и наоборот или сидеть и искать все вызовы вашего текущего ORM слоя. И тем самым задерживать релиз из-за какой то внутренней переделки, на которую заказчику глубоко посрать, ведь ему реально посрать на то, что ты используешь для доступа к базе (CRUD).

И наконец, лучше содержать свой код так, как того требует базовые SOLID паттерны. Использование DAO слоя в данном случае подходит под практически все SOLID паттерны.

Мысль на закуcку. В чем разница между DAO и Repository паттернами? IMHO в том что к Repostory Эрик Эванс добавил ряд требований, таких как Repository может быть применен

к Root Donain Object, и все модификации с Childs могут происходит через Repository.

Об эффективности оффшорных комманд

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

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

Митинги
Митинги должны быть короткими (до часа), на них желательно не опаздывать. Совместные митинги с заказчикам должны сопровождаться высоким качеством канала связи, иначе хана, отстающее видео от звука, или вместо спецификации транслируется пошаговая стратегия обновления экрана, накладывается на проблему языка и до ofshore команды доходят лишь крупицы информации.
Бороться с этим можно многими способами.
На митингах нельзя говорить одновременно нескольким людям из за того что на другой стороне это зачастую походит на Одесский Привоз в разгар торговли. Говорящий должен к себе направить камеру и говорить в микрофон.
Как то к нам приезжал Крэйг Ларман Craig page, и на одном из PBR предложил onshore стороне делать контрольные точки, ставя вопросы по теме к нам в offshore. Тем самым добиваясь полного понимания вопроса обсуждения. Это может затянуть митинг, но гарантирует понимание всех сторон.

Бюрократия и секюрити
В некоторых организациях эти моменты доходят до абсурда, по крайней мере так нам кажется со стороны ofshore. Нас менеджмент "удивляет" вопросами типа как бы нам повысить в 2 раза эффективность, и при этом загоняет нас в рамки виртуальных машин и паршивого канала связи с серверами onshore. Как следствие половину времени тратиться на поднятие енвайрмента, осознавания факта, что тебе уже некуда делать check out из svn, потому что больше 30 гигов на виртуалке не положено и кучи других неприятных активностей которые приносят скорее раздражительность чем удовлетворение от работы.

пока все. а как у вас обстоят дела?

Continuous delivery

Surfing in internet, i've found some interesting interview with Martin Fowler and Jez Humble, here is a link. Also there are guys who doubts about Continuous Delivery and Continuous Deployment practices, here is a link. Taking into account that i'm working in agile environment and we also have these painful release activities i decided to provide some comparison of what are these guys talking about and what we actually have in my project.

I can say that we haven't built a communism in this sphere. First of all we are not ready to release on demand, and this is the one of the main point of Continuous Delivery pattern. We still have problems in our culture such as keep all tests green, i will talk about it later. Because of business specific, constraints, security and finally complexity of the product we cannot automate everything. I think we have too bureaucratic process of several approves before release. The fact that we're offshore is also impose the fact that we cannot take part in release activity and also production health. And from technical point of view the architecture of the product is very complicated, there are a lot of external dependencies which we cannot automatically test, but only front to back manual testing.

Tests.
I really like the article testing-pyramid, especially the phrase "Where we also value that the information provided from the right matters to our customer and is rich in information, and the information from the left matters to our developers and their ability to be efficient." I've been a witness and also opponent in production issue judgement, when some guy asks, please point me some test that you have done for this User Story. So i just want to highlight that all test are valuable and you should automate them as march as possible.
The other issue that might cause you avoid acceptance tests and other complicated test is actually complexity of these tests. In compare to unit tests, they require more reliable interface, the should be understandable for other guys then IT, i mean BA and QA, and finally they should be produced by other guys other than IT.
So, while your software is evolved , your testing framework is also should evolve.
And final issue about acceptance test is actually maintenance. No doubt that it's rather harder to maintain acceptance test then unit test. First of all, you should wait much more time the result of these tests in you continuous integration system, because of the nature of these test. The second point is that the reason of the failure of such tests may be hidden under complexity of the flows under these tests.   And this is the main problem of resistance of developers to keep them green


Ready to production code.
One guy reproached me, that using brunches is more efficient way to produce features in your software. But i would like to remind you what branches causes:

• Merging process. This process may be too long and painful
• You cannot guarantee the coexisting of several features in mainline on demand
• you cannot build continuous delivery pattern upon multiple brunches   

Deployment pipeline

Well, this is an implementation of Continuous Delivery pattern. And IMHO it's strongly coupled with specific and architecture of the software. So any implementation of Deployment Pipeline should be flexible. May be it should have a pluggable architecture.

So thats all so far. I believe that it was interesting for you.