Матрица компетентности программиста

Перевод

1 часть: http://spreadsheets.google.com/pub?key=pmAWNZu8sBj_tXy5ms5foVQ 

2 часть: http://docs.google.com/View?docid=d28gm4q_56hmv6f72z

Оригинал http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

На мой взгляд, это офигенно. Практически готовая аттестационная таблица для разработчиков.

Есть ли жизнь просле спецификации?

Функциональность бизнес-приложения - совместное дело заказчика и разработчика

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

Спецификация здесь является только точкой отсчета - слепком того, как разработчики (я имею в виду всю команду - начиная от бизнес-аналитика и кончая последним PMом :-) поняли свою задачу. Если затем кто-то из игроков по какой-то причине встает в позу и начинает "пенять на спеку" то дело швах.

Даже при самом мегакомпетентном заказчике, он какие-то вещи не поймет, пока не начнет системой пользоваться хотя бы в тестовом режиме

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

Что же можно пожелать командам, работающим над бизнес приложениями?

Заказчику

• Назначать менеджером со своей стороны гибкого человека, который абсолютно "в теме" бизнес контекста, желательно с минимальными техническими скиллами (как вариант -- хорошо работает связка "бизнес-спец"+"спец от ИТ").
• Быть готовым к длительной фазе приемки. Быть готовым за нее платить :-). 
• Запланировать пилотную эксплуатацию систему на живых пользователях. 
• По возможности, не привязывать к первой версии системы критичных дедлайнов.

Исполнителю

• Заложить в бюджет проекта достаточное количество времени и денег на доработку системы после старта приемочного тестирования.
• Не надеяться, что после того как спецификация будет написана, она не изменится.
• Не пытаться сделать абсолютно всеобъемлющую спецификацию чисто аналитически -- все равно только после того, как заказчик посмотрит на готовую систему, он поймет, чего на самом деле хотел.
• Проектировать систему так, чтобы было легко вносить очевидные бизнес - изменения (добавить поле, добавить/удалить/изменить валидатор, поправить алгоритм постройки отчета, поправить права на функциональность и т п).

Вебинары для всех и занедорого

Рассматриваю сейчас, какие возможности существуют для проведения некоммерческих вебинаров. После небольшой поиска среди вебинарного софта набрел на DimDim - это платформа для проведения вебинаров.

DimDim

От остальных игроков проект выгодно отличают две вещи - поддержка до 20 участников в бесплатной версии (у других вебинарных компаний бесплатный аккаунт поддерживает обычно вебинары для трех слушателей). Платная версия - от 20 долларов в месяц - позволяют делать вебинары на 50 и более слушателей.

Проверка показала, что система работает - исправно передает звук, позволяет расшаривать десктоп, просматривать PowerPoint-овские презентации и совместно браузить интернет.

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

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

TeamViewer

По удобству и функционалу еще приятно выделяется TeamViewer - систему, специализирующуюся на различных сценариях общения one-to-one. TeamViewer отличают очень удобная инсталляция и богатство всяких поддержечных штучек -- передача файлов, удаленное управление, получение system info и пр.

Программа бесплатна для некоммерческого использования а для коммерческого - от 25 евро/месяц.

Skype (update 6 sep 2009)
Начиная с версии 4.1, скайп позволяет абсолютно бесплатно передавать при звонке содержимое своего экрана. Причем версия 4.1+ нужна только на стороне того, кто презентует - смотреть можно и со старого скайпа, даже с версии 3.

Как инструмент для показов "один-на-один" - самое то. Группового вещания пока не сделали, ждем.

Слова:
Screen Share, Screen Casts, Presentations, Презентации

Good News about SharePoint Designer

Всем привет! Что-то давно я не писал. 

Небольшая приятность от Microsoft - SharePoint Designer с апреля сделан бесплатным и доступен для свободного скачивания на сайте компании: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=baa3ad86-bfc1-4bd4-9812-d9e710d44f42

Про пятницы

Проект, над которым я сейчас работаю, делается в два приема - мы выпускаем версию 0.9 и версию 1.0. Обе версии уходят в боевую эксплуатацию с разницей в месяц.

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

Но только сегодня я понял, что дедлайны для каждой версии  заказчик поставил на пятницу, 13.

Черт возьми, два подряд релиза в пятницу, 13-е. Такого еще со мной не случалось

Исследование CNews: Что нужно ИТ отрасли от власти

http://www.it4business.ru/live/1735/

Atlas, Capuccino, Objective J

http://280atlas.com/

Интересный фреймворк, интересное видео. Для мако-любителей, которые хотят писать на Objective C под веб (в свое время я был очарован букально Obj C - очень красивый язвык, и фреймворки там красивые и приятные). 

Capuccino Framework использует Objective-J (http://cappuccino.org/learn/)

Потенциал в этой штуке чувствуется. Пожелаем ребятам удачи :)

Покорение сложности ИТ

http://www.osp.ru/os/2005/07-08/185761/

Ефим Натис - Все возрастающее бремя сложности информационных технологий на предприятиях влечет за собой увеличение затрат и «усталость от инноваций».

Интересная статья, особенно про нормальные формы компонентов.

***

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

·         Вторая «нормальная» форма предполагает, что интерфейс представляет одну и только одну законченную бизнес-функцию. Законченность бизнес-функции — понятие относительное, и интерфейс может иметь несколько точек входа. Тем не менее определение интерфейса во второй форме гарантирует его четкую дифференциацию от других, а также логическое обоснование объединения в одном интерфейсе конкретного набора точек входа. Не накладывается каких-либо ограничений ни на характер выдаваемых данных, ни на способ их обработки.

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

·         Четвертая «нормальная» форма требует, чтобы доступ компонента к его «собственным» данным был исключительным — другие программы не имеют прямого доступа к этим данным. Для достижения такого уровня изоляции структура данных компонента не публикуется для открытого доступа. Публикуется только набор его интерфейсов для обеспечения полного контроля над обработкой данных вне компонента-«владельца».

·          Наконец, пятая «нормальная» форма делает принадлежащие компоненту данные «непрозрачными» — вне компонента структура данных неизвестна. Даже метод долговременного хранения данных (если таковой используется) не известен за пределами компонента. Различные компоненты получают и хранят данные в разных формах и используют разные технологии, наилучшим образом отвечающие семантической природе этих данных. Долговременное хранилище непосредственно не доступно для семантического анализа и, таким образом, приобретает ранг средства резервного копирования. Основные оперативные данные всегда находятся внутри компонента. Возрастающая степень нормализации требует, чтобы структуры процессов и данных были тесно увязаны и, в конечном счете, превратились в единое целое. Основными становятся данные интерфейса, а не сохраненная запись, как практикуется сегодня. Компоненты в пятой нормальной форме инкапсуляции являются объектами. Такая степень инкапсуляции достигается редко — если вообще достигается.

По мере повышения уровня нормализации программной системы ее структура становится более согласованной, а реализация — более последовательной и управляемой. Кроме того, системы, находящиеся на более высоких уровнях нормализации, оказываются более доступными и эффективными без излишнего бремени сложности обслуживания и управления.
Большинство предприятий не стремятся к пятой «нормальной» форме: ее требования слишком высоки. К 2010 году основная часть новых программных систем для бизнеса будет находиться на уровнях нормализации с первого по третий. Однако поставщики технологий с целью дистанцирования от конкурентов станут вкладывать средства в более высокие уровни инкапсуляции. В течение последующих пяти лет, вероятно, появятся новые инструментальные средства, которые позволят проводить синергическую инкапсуляцию процессов и данных, чтобы поддерживать более высокие «нормальные» формы программной инкапсуляции.
Рекомендации. Любой шаг к нормализации — это продвижение к уменьшению сложности итоговой программной среды. Начните с первой «нормальной» формы и постепенно, по мере приобретения опыта, продвигайтесь к следующим уровням. На высоких уровнях нормализации, однако, действует закон убывающей отдачи: для получения дополнительных выгод требуются все большие вложения.