Начну я просто — поясню, что такое Scrum и зачем он нужен, что бы те люди, кто с ним пока не сталкивался, могли с интересом прочесть данную заметку и понять о чём собственно идёт речь.

Итак, Scrum, это популярная (модная, если хотите) сегодня методология ведения программных проектов. Другими словами, как управлять командой разработчиков, что бы программный проект завершился успешно. Что и как документировать, как, с кем и как часто обсуждать детали проекта, как ставить задачи людям и как контролировать результат. Всё это попадает под термин “методология управления программным проектом”.

Вам понятно? Отлично! А теперь…

Этот топик, есть продолжение вот этого топика: habrahabr.ru/blogs/pm/39308

Итак. Продолжим повествование на тему Скрама.

Перед тем, как описать саму методологию, чуть коснёмся классификации. Часто приходится слышать: у нас XP методология, а у нас Скрам, а у нас Agile девелопмент. Всё это имеет право на жизнь. Но, на мой взгляд, желательно правильно соотносить эти понятия.

XP — это набор принципов и подходов, меняющих традиционное отношение к разработке современного программного продукта.

Agile – это общее название группы гибких и достаточно успешных методик организации ведения проектов. Методик, которые, как правило, опираются на принципы XP и предполагают быструю итеративную разработку, тесное общение с заказчиком и, за счёт тесного общения членов команды, минимизацию создания дополнительных сущностей (артефактов/документов), которые традиционно создавались в процессе работы над проектом. Минимизацию всего того, что создаётся помимо самого программного кода.

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

Я часто сталкиваюсь с другой классификацией, когда XP называют Agile методологией. Сложно сказать…

Хорошая мотивация сотрудников — это по сути важнейшее условие успешности любой компании. Не только в сфере IT, но в IT — особенно. Ведь известно, что мотивированный сотрудник может сделать работу в разы быстрее и, главное, качественнее.
Надо сказать, что всевозможных методов мотивации сотрудников известно очень много. Казалось бы, что нет ничего проще — читай, внедряй и получай эффективных и мотивированных сотрудников.
Однако последнее время всё чаще встречаются статьи, где авторы пишут, что финансовая мотивация — это зло. Например одна из лучших статей Joel Spolsky О вреде премирования. А некоторые и вообще пишут, что метод кнута и пряника уже не работает.
Мало того, в России до сих пор многие руководители не понимают важности мотивации и лояльности сотрудников и уделяют этому вопросу недостаточно внимания, считая, что сотрудник должен быть доволен уже самим фактом работы в компании.
При этом есть множество книг и статей, где одни руководители и менеджеры рассказывают другим про то, какие методы мотивации наиболее эффективны. Но знают ли они про это на самом деле? Не правильнее ли про лучшие методы мотивации узнавать у тех, кого пытаются ими мотивировать?
Я не собираюсь тут писать еще одну статью про мотивацию — их и так много, хотя мог бы, так как побывал и программистом и менеджером и пробовал разные методы мотивации на себе и на других. Но сейчас я хотел бы просто задать несколько вопросов.

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

Задумайтесь и напишите в комментариях, какие из методов мотивации наиболее сильно воздействуют именно на вас?
Так ли бесполезны и вредны премии в вашем конкретном случае? Премии за что вы считаете наиболее и наименее мотивирующими?

Как я и обещал, вторая глава из книги «jQuery in Action» (авторы Bear Bibeault и Yehuda Katz). Как и из первой главы, выбрал все самое вкусное и интересное ;-)

Напоминаю, что первую главу можно прочесть здесь.

Заранее предупреждаю и извиняюсь, но оно того стоит: букаф многа.

Введение

В средней школе я был «круглым» двоечником, которого переводили в следующий класс только под значительным влиянием моего отца, в то время проректора ФПИ, довольно влиятельного (в личном общении) и властного человека.

В конце седьмого класса у меня встал выбор — идти в ПТУ или учиться дальше в школе. Все учителя, настаивали на том, что мне бесполезно учиться не то что в институте, но и в старших классах, в виду моей бездарности. Естественно, это мне не очень понравилось, и я решил стать лучшим в школе.

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

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

Не так давно попался под руки новый проект. До сих пор, в основном, приходилось допиливать старые. В проекте предполагалось использование БД. Погуглив немного решил отказаться от старых методов работы с данными в пользу ORM. Да, есть много кодогенераторов(например, CodeSmith), которые в считанные секунды создадут уровень доступа к данным, но такие решения не отличаются гибкостью, а при дальнейшем развитии грозят превратиться в кошмар. Хотя и у ORM тоже есть свои недостатки. Но обо всем по порядку. Сейчас же я хочу поделиться с вами моим опытом в освоении одного из представителей мира ORM — NHibernate. Почему из всех возможных ORM я выбрал для изучения NHibernate? Во-первых, потому что надо было выбрать что-то одно. Во-вторых, история NHibernate уходит глубоко корнями в ORM-фреймвокр Hibernate для Java и является достаточно зрелым решением. Больше пока, вроде, и нет аргументов, но, думаю, они появятся позже при более близком знакомстве с NHibernate.

Мой самый любимый и уважаемый фонд Y Combinator презентовал четырнадцать стартапов, которые он выращивал на прошедшей летней сессии. Хотя по разным источникам я встречал упоминание о 10 или даже 20 стартапах, на самом деле их 21, хотя не все были показаны публично или о них есть какая-либо информация. Потому мы расскажем только о тех, что публично раскрыли себя.

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…

Введение

Готовясь к редизайну и пересмотру сайта wufoo.com, я посвятил некоторое время повторному изучению основ взаимодействия человека и компьютера, в надежде вобрать что-то новое, что накопилось за десятилетия исследований в области создания простых интерфейсов. Первое, что меня удивило на этом пути — это то, что материал по данной теме был крайне сжат и явно ориентировался на математиков, поскольку был написан на языке академической элиты. Можно предположить, что если бы они хотели произвести впечатление (особенно на дизайнеров), они могли бы написать документы, более лёгкие для восприятия.
Вспоминая школу, я отметил, что лишь во время изучения физики математика приобрела для меня некий смысл. Вместо абстрактных функций мне были нужны графики. Размышляя в таком ключе я подумал, что было бы неплохо дать наглядную интерпретацию закону Фиттса — краеугольному камню проектирования человеко-машинных интерфейсов, и объяснить как его концепцию, так и то, почему эти идеи чуть более сложны, чем многим бы того хотелось

Статью выкладываю по разрешению автора. Оригинал здесь.

Я знаю два варианта организации времени начала работы в IT фирме и довелось мне поработать с обоими вариантами.

1. Приход на работу к конкретному времени. Сродни советскому: в 8.00 все должны быть на работе иначе штраф или даже увольнение. Уходят все в 17.00
2. Свободный приход к любому времени. Тут может быть куча вариаций, когда надо работать 8 часов в день или 40 часов в неделю или вообще никто время не смотрит, лишь бы работа делалась.

Я проработал 7 лет в компании, где надо было приходить каждый день в 9.30 и уходить не раньше 18.30, а теперь уже полгода в компании, где каждый приходит и уходит когда хочет.
И теперь я готов сравнить варианты.

Моя статья на Временно.нет

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

Здесь представлен обзор 38 статей, разбитых на 4 категории по способам реализации.

Сегодня поговорим о стартапах. Инициатором этой статьи стал материал от известнейшего венчурного инвестора, Поля Грехема (Paul Graham), который руководит уже известным нам фондом Y Combinator (о котором мы писали, да и в России уже появились фонды, в той или иной мере копирующие его бизнес-модель, например, addVenture, JumpIDEA, inVenture). Теперь он описал своё виденье рынка и указал на тридцать тем или скорее очертил круг интересов и рынков, в которые они готовы вкладывать. Впрочем, как правильный и успешный инвестор, он не ограничивается ими и готов рассматривать любую интересную идею (о чем и указывает в конце материала). Далее я переведу и попробую самостоятельно проанализировать эти рынки, а также позволю себе добавить и свои взгляды, указав на дополнительные интересные и перспективные направления. Это не дословный перевод, поэтому для тех, кто хочет изучить именно оригинал, вот ссылка на англоязычный источник.

Всем хорошего вечера понедельника (если такое возможно). Хочу спросить у тех кто пишет под .NET платформу, какие средства коллективной разработки они используют? Понятно что есть VS Team systems. Все ли используют его? Может кто-то пользуется чем нить альтернативным? Чем-то полегче?

Хочу поделиться приятной находкой, с теми, кто юзает WPF. Готовый DataGrid, бесплатный, для версии с ограниченными возможностями.

Ниже быстренький рассказ как примерно создавался проект об удалённой работе в области информационных технологиях getdone.ru. Или снова про старпё… ой стартаперов :)

Уволился в середине июня 2007 года из одной омской компании, после года работы в офисах: 3 недели в одном, 3 месяца в другом и рекорд 6 месяцев в последнем. Имея на руках 100 000 руб., из которых 30 000 руб. потратил на б/у ноутбук для нормальной работы, я погрузился в раздумья об очередном проекте. У меня был опыт собственных проектов — во время учёбы сделал несколько сайтов на php, но ничего особенного из этого не вышло. Идея пришла спонтанно, не отличаясь оригинальностью, мне захотелось сделать фриланс биржу (делая мелкие проекты на php и perl, студентом частенько занимался фрилансом). Постепенно, идея о фриланс бирже перерастала в большее, спрашивая себя: «а почему бы ни добавить чат, было бы круто, тем более я никогда не делал чаты», примерно в таком духе разрабатывались новые разделы.

На ресурсе free-lance.ru проспамил человек 300, имевших в портфолио более-менее нормальные работы, для создания дизайна. В предложении присутствовал только процент от прибыли проекта, но в большинстве откликов предлагали услуги за деньги. Екатерина Соаха (soaha) согласилась с моими условиями. С вёрсткой оказалось сложнее, никто не согласился помочь, поэтому выделил немного денег на вёрстку, но скупой платит дважды, поэтому сам переделывал CSS стили.

От первой строчки кода, до того, что есть сейчас, прошёл год. В основном, не считая помощи по дизайну, над проектом работал один. Иногда случались длительные перерывы, когда всё осточертевало, иногда подработки, т.к. начальной суммы не хватало. В отличие от года офисных экспериментов, за год самостоятельной работы получил огромнейший опыт в программировании. Возможно разработал систему, на основе Tapestry5 и Hibernate, уровня Django или RubyOnRails, попозже думаю заняться документированием и выкладыванием её в open source.

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

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

Сегодня Google объявила об открытии интерфейса Google AJAX Libraries API. Что это и для чего нужно я в кратце поясню.

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

Задача решается следующим образом.

1. Выкачиваем и правильно складываем базы whois.
2. Для каждой подсети определяем город.
3. Пакуем базу в бинарный файл.

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

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

• Снятие скриншотов экрана
• Мониторинг запущенных процессов
• Мониторинг открытых веб-сайтов
• Перехват сообщений ICQ и MSN Messenger
• Мониторинг USB устройств
• Запись времени начала и окончания работы
• Мастер отчетов – анализ активности пользователей
• Дистанционаая инсталляция и удаление агентов
• Невидимый режим работы агента