21 декабря 2012 г.

The Land that Scrum Forgot: Остров, о котором забыл Scrum Боба Мартина

Предисловие переводчика 

На оригинал данной статьи я наткнулся случайно, разгребая почту и наткнувшись на новостную рассылку от ScrumAlliance. Тема метрик Scrum команд и непосредственно кода, меня интересует уже давно. Особенно любопытно, что с этими метриками делать дальше, и первостепенно — зачем они вообще нужны?

В данной работе автор поднимает важнейшую тему для молодых Scrum команд — почему со временем теряется продуктивность и как сохранить ее в долгосрочной перспективе?

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

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

Оригинал статьи расположен по адресу: http://www.scrumalliance.org/articles/300-the-land-that-scrum-forgot

Хабраперевод «Остров, о котором забыл Scrum»: http://habrahabr.ru/post/163413/

Предисловие Майка Кона


Scrum это отправная точка. Это отличная отправная точка. Но как каркас (Прим. пер.: framework). Как полноценная методология Scrum нарочно оставлен незавершенным. Некоторые вещи — такие как используемые технические практики — оставлены командам на усмотрение. Это дает командам возможность подстраивать технические практики между проектом и бизнес-средой.

Несмотря на то, что выбор практик лежит целиком на команде или организации, вместо групы методологистов, преимущества некоторых практик настолько очевидны, что практики становятся соглашениями всех Scrum команд. Но, очень много Scrum команд становятся довольны приростом продуктивности, полученным благодаря Scrum и останавливаются в поисках путей совершенствования. Многим не удается применять технические практики, необходимые для долгосрочного успеха. В данной публикации, Роберт Мартин (возможно более известный, как "Дядя Боб") расскажет нам почему так многим Scrum командам не удается поддерживать результаты быстро полученного успеха.

Публикация Боба первая в серии публикаций в новостной рассылке ScrumAlliance. Поскольку Scrum это отправная точка, с присущими пробелами, которые следует заполнить командам, мы ищем за пределами Scrum сообщества способы заполнить эти пробелы. Что знают или делают ведущие agile мыслители за пределами мира Scrum что следует знать нашим Scrum командам? Я несколько раз просил поделиться этими мыслями. Но что может быть лучше, чем спросить Боба Мартина?


The Land that Scrum Forgot,
Боб Мартин, 14 декабря 2010 года.


Что не так со многими Scrum проектами? Почему сначала velocity подскакивает, а потом начинает падать? Почему некоторые Scrum команды периодически отказываются от Scrum? Что происходит?

Как один из тех, кого позвали чтобы спасти Scrum команды от подобного отречения, я говорю вам, что проблема не в том, что команды теряют мотивацию. Часто проблема в том, что программное обеспечение, которое команды разрабатывают становится сложнее и с ним становится сложнее работать.

Scrum дает вам быстрый старт! Это отлично. Часто первые сприты сталкиваются с первыми особенностями Scrum'а. Менеджеры и заказчики счастливы. Команда работает блестяще, и она тоже счастлива. Все счастливы и видят в Scrum огромный успех.

Это повторяется в следующей и в следующем за ним спринте. Производительность высока. Система постепенно строится, а весь функционал уже работает. Ожидания созданы. Планы построены. Энтузиазм парит над Scrum. Достигнута гипер-продуктивность!

Одна из причин гипер-продуктивности это маленький размер кодовой базы. Малой кодовой базой проще управлять. Исправления легко вносить; новые функции легко добавлять.

Но код растет быстро; и когда кодовая база становится больше, ее становится тяжело поддерживать. Программисты значительно замедляются из-за ухудшения кода. Команды «сдуваются» до невозможного из-за огромного груза плохо написанной системы. Если об этом не позаботились заранее, гипер-продуктивная Scrum команда впадает в болезнь, которая убивает множество софтверных проектов. Они породили беспорядок (Прим. пер.: mess).

«Подождите!» — слышу как говорите вы. «Я думал что Scrum нужен чтобы усилить команду! Я полагал, что команда сделает все возможное, чтобы удостовериться в качестве. Я думал, что укрепленная Scrum команда не создаст бардак!»

Да, вы правы. Проблема в том, что даже укрепленная команда состоит по-прежнему из людей, и они работают за то, что им дают. Они будут награждены за качество? Или их наградят за продуктивность? Как много значимого команда получит за хорошее качество кода? Как многое они получают за поставку рабочего функционала?


19 декабря 2012 г.

Git branch naming convention for SCRUM developers

...или Делаем систему контроля версий более информативной и гибкой



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

Тема поста возникла из недавнего обсуждения, посвященного следующей проблеме.

SCRUM команды используют Continuous Integration сервер для регулярного автоматического создания сборок. Разработчики с помощью него могут оперативно получать отклик на свой код (на сервере работают автоматические интеграционные тесты), заинтересованные лица (в том числе Product Owner) могут получать самые последние сборки с самыми последними изменениями.

Обычно оттуда же берут сборки и QA, и... сталкиваются с тем, что по сообщениям commit'ов невозможно понять, какая фича появилась, что нужно посмотреть/протестировать и т. д.

Причина этого банальна — распределенные системы контроля версий (git, mercurial,...) мотивируют (или скорее не ограничивают) программиста в том, чтобы делать коммиты чаще. Это очень привлекательно для программиста — каждый небольшой фрагмент полезного кода можно сохранить, можно откатить эти изменения, можно показать их другому разработчику.

Однако, если не выработана привычка писать «вменяемые» комментарии к коммитам, эта возможность будет полезна только одному из программистов в команде — другие участники попросту не смогут разобраться без просматривания changeset'ов в том, что действительно изменилось. Кстати, это в принципе справедливо и для пользователей SVN.

18 декабря 2012 г.

DivShot: Interface Builder для создания пользовательских интерфейсов веб-приложений


Создание пользовательских интерфейсов веб-приложений всегда оставалось довольно рутинным  занятием, особенно если пишешь UI с нуля, не используя сторонних фреймворков. Горы HTML и CSS, адовая кодбаза на Javascript, часто связанный, вермишельный код для поддержки разных браузеров, разрешений, возможностей (и снова слава HTML5).

Даже с такими могучими фреймворками как Sencha или штуками полегче вроде jQuery Mobile остаётся огромное количество мелкой работы, связанной со стилизацией или разработкой кастомных компонент. Чем UI приложения насыщеннее, тем больших ресурсов на разработку, поддержку и тестирование он требует. Тем пронзительнее боль client side разработчиков.

Однако, зачастую хочется собрать UI как можно быстрее, накидать компонент и посмотреть как этим пользоваться «вцелом». Также наряду с ценным функционалом, есть вещи без которых нигде не обойтись — авторизация, клиентская валидация форм, навигация и т. д. Они быстро собираются из стандартных компонент — формы, навигационные панели, сайдбары, лэйауты...

DivShot

Последнюю задачу кажется решает с задором и лихвой новенький сервис DivShot, недавно вышедший в публичную бету. «Interface Builder для веб-приложений. Перетаскивайте компоненты и экспортируйте в отзывчивый HTML и CSS» — озаглавлена их прелестная landing page. Что же внутри?

А внутри нас ждет самый настоящий Interface Builder — все, как заявлено: натаскивай себе компоненты в лэйаут и экспортируй полученный HTML & CSS.


В качестве демонстрации доступна два шаблона с контентом и парочка пустых с лэйаутами. Интерфейс этого чуда сделан целиком на HTML и понятен даже ребенку — справка панель с набором компонент, среди которых меню, элементы форм, тултипы, а также компонент для вставки своего HTML'а. Над ним панель свойств.

Можно создавать многостраничные мокапы, однако вот перелинковать их мне не удалось. Предварительный просмотр позволяет посмотреть результат трудов в новом окошке. Замечательно работает функция экспорта в HTML!


Экспортируемый код при этом содержит ссылки на css прямо на домене divshot.com, что позволяет скопировать его целиком в html страницу и посмотреть уже на своем сайте.

Также есть возможность редактировать CSS и добавлять свою HTML разметку, что по идее дает возможность делать свои компоненты, или проектировать UI с использованием заготовленных скетчей.
Enhanced by Zemanta

6 декабря 2012 г.

Новогодние каникулы 2012-2013: как отдыхаем в грядущий Новый Год

Новогодние каникулы в уходящем 2012 году начнутся с 30 декабря и закончатся 8 января, т.е. составят 10 дней, в соответствии с новым постановлением Министерства Труда и Социальной Защиты.

Кроме того, весенние праздники станут теперь на 2 дня длиннее — выходные приходящиеся на нерабочие дни январских каникул будут перенесены на второе и третье мая соответственно.
Так сообщает нам портал DP.RU.

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


Сейчас в Японии 14 выходных дней в году — Экиден с 2 по 3 января, а в течение всего января японцы молятся семи богам удачи. Во второй понедельник января отмечается день Сэйдзин но хи — праздник совершеннолетия. Совершеннолетие в Японии наступает с 20 лет, хотя еще в 19 веке для юношей оно наступало в 15, а для девушек в 13 (!) лет.
Следом японцы отмечают 14 февраля — день влюбленных. Далее 14 марта — Белый день. 20 или 21 марта отмечают Сюмбун но хи — равноденствие. 29 апреля - День зелени (Мидори но хи). Это государственный праздник любви к природе. До 1988 года он отмечался как День рождения императора Сёва. 5 мая - государственный праздник День детей (Кодомо но хи). 

Вот такие новогодние праздники.

2 декабря 2012 г.

Аксессуары для iPhone 5, iPhone 4S, iPad и MacBook от Twelve South

Недавно engadget опубликовал информацию о поступлении в массовую продажу сумасшедше крутых чехлов BookBook для iPhone 5 от компании Twelve South!


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

А вот так выглядит BookBook для iPhone 4/4S.
Стоит такое чудо $60 на официальном сайте Twelve South, но к сожалению в Россию не доставляют, а доставляют в некоторые страны СНГ, в том числе и в Украину. Доставка обойдется примерно в $50 прекрасной курьерской службой FedEx.