CustisWiki - Новые страницы [ru]

Результативность автоматизации

2010-02-11T17:35:44Z

BenderBot: 1 версия

Максим Цепков: главный архитектор компании CustIS (Заказные ИнформСистемы)

Журнал Директор информационной службы (CIO.RU), № 7, 15 июля 2009, стр. 40-42.

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

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

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

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

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

2010-02-11T17:15:08Z

BenderBot: 1 версия

Владимир Рахтеенко: Генеральный директор CustIS (Заказные ИнформСистемы)

Журнал Intelligent Enterprise (Корпоративные системы), № 18, 24 ноября 2008, стр. 48-51. http://www.iemag.ru/analitics/detail.php?ID=18270&phrase_id=37452

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

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

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

Восходящая «Звезда» MDM

2010-02-11T16:31:28Z

BenderBot: 1 версия

Валерий Никитин: аналитик проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Роман Алексеев: руководитель проекта MDM направления «Торговые сети» компании «Заказные ИнформСистемы»

Михаил Заборов: руководитель направления «Торговые сети» компании «Заказные ИнформСистемы»

Журнальная версия статьи опубликована в «Директор информационной службы (CIO.RU)», №9 (сентябрь) 2008, стр.50-53.

Быстрые темпы развития ИС, предназначенных для ведения НСИ, не дают возможности разработчикам договориться о терминологии и разобраться во множестве существующих решений. Анализ рынка приводит к выводам о том, что российским компаниям для ведения НСИ больше других подходит модель «Звезда».

Каждый человек, интересующийся автоматизацией ведения нормативно-справочной информации (НСИ), знает, что в современном языке отсутствует четкая граница между понятиями «НСИ» и «мастер-данные». Однако если приглядеться к этим понятиям пристальнее, можно найти в них отличие, которое, в свою очередь, выявит правила использования обоих терминов.

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

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

Современные тенденции в создании информационных систем привели к расширению этого понятия. Сейчас термин «нормативно-справочная информация» следует понимать как информационный ресурс компании, получаемый, как правило, извне и оформленный внутри нее (задана структура хранения данных, разработаны процедуры ее получения и хранения). С одной стороны, такой подход достаточно четко характеризует НСИ: действительно, если данные являются общезначимыми, то они не должны «рождаться» внутри компании, а должны поступать из внешнего мира. Под это определение попадает и государственный классификатор, и перечень товарной номенклатуры производителя. С другой стороны, оговорка «как правило» предупреждает о существующих исключениях, таких как скидки или организационная и юридическая структура компании.

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

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

Управление тестами с Testopia — недостающее звено? (SECR-2009)

2010-01-27T20:24:58Z

StasFomin:

Продолжаем выкладывать материалы по нашим докладам с CEE-SECR-2009/SQALabs-6.

Публикуем доклад Стаса Фомина «Управление тестами с Testopia — недостающее звено?» (Test management with Testopia — missing link?)

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

Вернее мы публикуем не сам доклад на SECR/SQADays (ибо видеозаписи там не было), а часть внутреннего семинара по данной теме.

Итак, представляем двадцатиминутное видео самого доклада:

и короткий пятиминутный скринкаст самой системы (сорри, без озвучки, но вроде и так все понятно):

Если что-то на видео было неразборчиво — можно просмотреть слайды:

Слайды не «тезисные» (то есть не слайдоменты), и отдельно от видео выступления их рассматривать не очень эффективно.

Но можно и не смотреть видео — для разъяснения (и для предпочитающих чтение), прилагаем краткую статью.

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».

Репликация: База Знаний «Заказных Информ Систем» → «Управление тестами с Testopia — недостающее звено? (SECR-2009)»

Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)

2010-01-27T20:24:15Z

StasFomin:

Итак, успешно прошла пятая по счету конференция SECR (в этом году она переименовалась в CEE-SECR 2009, но суть осталась прежней).

Мы совершенно не зря, рекомендовали наши доклады как нескучные — собственно по результатам зрительских симпатий на конференции наши доклады заняли второе и третье место.

Традиционно для SECR-2009 видеозапись и публикация докладов не велась, так что мы берем эту обязанность на себя и опубликуем все материалы по этим докладам — видео, слайды, статьи и т.п.

Первым у нас будет доклад Виталия Филиппова, «Одежка для Subversion: ViewVC и SVN-Searcher».

Во многих компаниях используется общеизвестная система управления версиями Subversion — бесплатная и с открытым исходным кодом, представляющая собой венец эволюции централизованных систем контроля версий. Однако, зачастую большая часть потенциала Subversion остается нераскрытой. На Subversion смотрят, как на «какой-то инструмент для программистов», и он используется только для хранения программного кода и исключительно для обеспечения конкурентной работы. При этом его невозможно использовать для эффективного и целостного ответа на вопросы — «Почему сделаны эти изменения?» или эффективно искать по репозитарию, даже без учета временного измерения, то есть поиска по ревизиям. Достаточно бедна веб-навигация по репозиторию — по структуре файлов и ревизиям, нет возможностей пассивного мониторинга — подписок на изменения (например, критически важных файлов). По сути, из-за всего этого репозиторий компании выпадает из корпоративной базы знаний, плюс, возможности Subversion не используются для «не программистов» (HR, маркетинг, и других инфраструктурных подразделений) — например, для хранения документов.
Мы предлагаем использовать свободные системы с открытым кодом — ViewVC и SVNSearcher — чтобы заполнить эти пробелы, и бесплатно превратить SVN-репозитарий в часть корпоративной базы знаний с эффективным поиском, веб-навигацией и RSS-подписками.

Видеодоклад — (как обычно, можно смотреть, можно скачать).

Есть и слайды — если вы хотите ознакомится быстрее, или даже пересказать доклад кому-то еще:

Ну а для любителей текста есть и статья «Одежка для Subversion - ViewVC и SVNSearcher (Dressing Subversion: ViewVC and SVN-Searcher)».

Репликация: База Знаний «Заказных Информ Систем» → «Одежка для Subversion: ViewVC и SVN-Searcher (SECR-2009)»

«Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)

2010-01-21T16:09:18Z

StasFomin:

3 августа в нашей компании прошел ранее анонсированный мастер-класс «Управление производством на основании численных данных».

Возможно его название звучало несколько скучно, но на самом деле, тема основана на культовой бизнес-литературе — произведениях доктора Элии Голдратта, автора производственной Теории Ограничений, основной постулат которой заключался от отказе от бессмысленной и беспощадной борьбы за тотальную производительность, вместо чего он предлагал сконцентрироваться на определении узких мест в производстве и продаже, и борьбе с ними, не взирая на падение локальных показателей оптимальности. Забавный был и способ изложения этой теории — в виде серии бизнес-производственных-романов («Цель», «Цель-2», «Критическая цепь», и др.), где главный герой, стартуя из безнадежной ситуации (бизнес разоряется, увольняют из университета, жена ушла, денег нет, пиджак в пыли, под кроватью брюки…) сконцентрировавшись на ключевых проблемах, находил серию эффективных решений в духе теории ограничений, и выходил победителем из сложившихся ситуаций. В общем, несмотря на некоторую инфантильность сюжета и бизнес-ситуаций с точки зрения реальностей современного мира, мы обязательно рекомендуем всем прочитать эти книги (там только о решении проблем на производстве, но и о решении семейных проблем). А конкретно этот тренинг ведущий Сергей Мартыненко основал на книге «Синдром стога сена» (по ссылке перевод первой части), где на 40 страницах текста без малейшей романтики и лирики рассматривается в цифрах оптимизация некоторого модельного производства, и где «на пальцах» читателя убеждают, что для достижения максимальной прибыли нужно жертвовать локальными оптимумами, и принимать решения, часто интуитивно непонятные. Сергей также приводил пример, иллюстрирующий, что похожие сценарии, когда действия, вроде бы направленные на улучшение процесса, на самом деле приводят к возникновению «бутылочного горла», бывают не только в материальном производстве, но и в разработке софта.

Вот обработанное от шума видео, которое как обычно, можно просмотреть в броузере или скачать для обычного просмотра:

Далее, был доклад Стаса Фомина: «Теория ограничений и Линейное Программирование», о возможности математического моделирования широкого класса производственных задач, в контексте и на материале того же «Стога сена». Математическое моделирование — это мощный и гуманный инструмент поиска «бутылочного горлышка» на математической модели производства, позволяющий прогнозировать изменения и дрейф ограничений, без необходимости натурных экспериментов на живых людях и работающем производстве, как происходило в романах Голдратта. А линейное программирование — простая и в то же время мощная модель, в которой каждый менеджер должен уметь формулировать подходящие задачи оптимизации. На этом докладе сначала было сделано введение в постановку задач линейного программирования на совершенно классическом игрушечном примере, а затем, за двадцать минут были вживую, с участием зрителей, сформулированы и решены все вариации задач из «Синдрома стога сена», причем оказалось, что бездушный компьютер, снабженный формулировкой задачи, нашел более оптимальное решение, чем сам Голдратт в этой книге (это было обнаружено совершенно случайно, при подготовке презентации за час до выступления). Таким образом, были подведены итоги:

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

Опубликован видео-скринкаст, рекомендуем его смотреть в полноэкранном режиме. Впрочем можно скачать HD-видео, оно очень компактное, 80Mb.

Для очень быстрого поверхностного ознакомления опубликованы слайды презентации (но лучше смотрите видео):

Репликация: База Знаний «Заказных Информ Систем» → ««Управление производством на основании численных данных» и «Теория ограничений и линейное программирование» (2009-08-03)»

Теория и практика Agile (2009-03-05)

2010-01-21T16:08:15Z

StasFomin:

Итак, вчера, (5 марта 2009 года) вполне успешно прошел ранее анонсированный семинар «Теория и практика Agile».

Так как меня (Стас Фомин) упрекают в многословности отчетов, буду краток. Семинар прошел успешно, — именно семинар, скорее даже «круглый стол», а не «доклады/лекции», ибо практически каждый слайд подвергся живому обсуждению, скажем, что некоторые «зрители» говорили и держали фокус внимания больше докладчиков.

Темы дискуссий, правда часто уплывали далеко в сторону. Казалось бы, какое отношение имеет дискуссия «Вменяемые Аналитики должны получать больше $4000» к теме «Аналитик в Agile?». Некоторые участники даже озвучили вывод, что оба доклада не имеют отношение к Agile. Можно констатировать, что период романтической влюбленности в модные agile-buzz-words прошел, звучит жесткая критика, и возможно (?) маятник ожиданий прихода «серебряной пули» в методологиях разработки софта скоро качнется обратно к водопадным моделям.

В общем, рекомендуем посмотреть видео — ибо мероприятие никак не сводится к слайдам/статье/аудио, много User-generated контента.

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

Андрей Бибичев «Аналитик в Agile».

Слайды и статья (хотя слайды слегка дополнены для этого семинара).
скачать видео

Александр Байкин «Гибкое управление требованиями».

Теперь о минусах. Ну, как обычно, пришло только чуть больше половины зарегистрированных, причем не пришла ни одна из зарегистрировавшихся девушек. Выносим устное порицание отсутствующим (кроме девушек, их мы поздравляем с наступающим 8 марта)!

Далее, «живой формат» растянул дискуссию несколько дольше ожидаемого — мероприятие, начавшись в 19:00 закончилось почти в 23:00, и далеко не все участники смогли сохранить бодрость духа и внимание до конца.

Но мы сделали выводы! На будущее будем или урезать scope — одна тема на такой вечерний семинар, или вводить некоторую тайм-модерацию ( гонг? девушки с «тайм-плакатами»?).

дополнительные материалы.

Репликация: База Знаний «Заказных Информ Систем» → «Теория и практика Agile (2009-03-05)»

ВикиЗакладки/Справка

2010-01-21T07:47:29Z

66.249.71.54: WikiBookmarks: load help page

ВикиЗакладки (WikiBookmarks) — расширение MediaWiki, позволяющее управлять публичными списками закладок с помощью Wiki-статьи. Автор расширения — Виталий Филиппов. Расширение распространяется по лицензии GPL (3-ей или более поздней версии). А это ссылка на домашнюю страницу расширения.

На странице Special:Bookmarks Вы всегда можете (точнее, уже смогли :-)) найти свежую версию справочной информации по ВикиЗакладкам.

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

Страница:

Текст кнопки:

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

Новые закладки добавляются в список в начале статьи, под несколькими уровнями заголовков. По умолчанию это заголовки == Год == и его дочерний === Месяц Год === ("%Y" "%B %Y"). Предполагается, что это используется для классификации закладок по датам. Если Вы хотите изменить количество и/или формат заголовков, нужно добавить в начало страницы закладок комментарий вида

<!--BookmarkHeadings:"%Y" "%Y-%m" "%Y-%m-%d"-->

Из этого комментария ВикиЗакладки вырезают все строки, заключённые в кавычки, и используют их в качестве заголовков последовательных уровней. Формат строк совпадает с форматом функции PHP strftime() (на самом-то деле это функция libc, но это не важно).

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

<!--BookmarkDate:"%d %H:%M:%S"-->

Строка, указанная в кавычках внутри комментария, и будет принята за формат даты-времени закладок.

Управление требованиями в Agile (встреча AgileRussia.ru 2009-12-02)

2010-01-20T19:16:13Z

StasFomin:

Agile «по-крупному» (встреча AgileRussia.ru 2009-04-21)

2010-01-20T18:39:11Z

StasFomin:

Во вторник, 21 апреля, прошла аннонсированная ранее встреча сообщества AgileRussia.ru, озаглавленная «Agile по-крупному!». Изначально тема заявлялась, как разбор сложностей Agile в крупных командах и проектах, обсуждение тонкостей масштабирования, ведь все, что выходит за максимальный размер стандартной Agile-команды в 9 человек, уже требует специальных подходов.

Но на месте, обсуждение велось вокруг двух следующих, «живых» бизнес-кейсов:

«Waterfall2Agile — Agile для Большой Waterfall компании: нужен? как и что внедрять?» — это пришли ребята из широкоизвестной компании «C», они детально описали свой цикл разработки и структуру проектного управления своего Большого Продукта (достаточно заметить, что цикл тестирования релиза занимал у них 18 месяцев), пояснили возникающие проблемы, и запросили у сообщества предложений по улучшению процесса — включая как Agile-практики, так и технические/инструментальные решения.
«AgilePostmortem» — это была посмертная ретроспектива распределенного Agile-проекта, интересного высокотехнологичного стартапа, к сожалению, «не дожившего до весны».

Что касается кейса «Waterfall2Agile», то ребята из компании «С» заслуживают серьезного уважения за смелость публичного обсуждения внутренних проблем разработки — далеко не всякая команда (вне зависимости от agile она или нет) решится на это. Мы публикуем две части видео «Waterfall2Agile-1» — это описание текущих процессов и постановка проблем, и «Waterfall2Agile-2» — это предложенные сообществом решения после 50-ти минутного обсуждения. Будет очень интересно, если внедрение Agile в компании «C» продолжится, и через некоторое время, на очередной встрече мы узнаем о прогрессе в этой области, о новых проблемах и нетривиальных решениях.

С другой стороны, кейс «AgilePostmortem» более соответствовал заявленной теме встречи — хотя команда там была не такая большая, как в случае компании «С», но она была и географически распределенной, и работала в очень быстром темпе, с использованием большинства современных agile-практик и инструментов эффективной разработки. Публикую «спойлер» — в целом, «вскрытие показало, что больной умер ~~от вскрытия~~ здоровым/от несчастного случая», ибо почти все было сделано правильно. Хотя с другой стороны, возможно, некоторые небольшие проблемы, которые были вскрыты обсуждением, тоже внесли свою лепту, ибо проекту совсем чуть-чуть не хватило, «чтобы допрыгнуть до другой крыши» — то есть выпустить бета-версию, ведь альфа-версия уже была и успешно демонстрировалась.

Как обычно, видео публикуем на высококачественном веб-видео-хостинге, плюс каждое видео можно скачать в лучшем (оригинальном) качестве.

Kanban vs. Scrum (встреча AgileRussia.ru 2009-07-07)

2010-01-20T18:18:23Z

StasFomin:

7 июля в нашей компании прошло очередное собрание сообщества AgileRussia, посвященного занимательнейшей теме – сравнению методологий разработки Scrum и Kanban. И если Scrum уже начал терять ореол свежести и модности, уже накопились претензии не от тех, кто «Пастернака не читал, но осуждает», а от реально практикующих Scrum в течение пары лет, то Kanban – штука в софтверной индустрии новая, и при этом не выдуманная заумь от софтверных методологов (или даже целых Институтов Программирования), а реальная практика, пришедшая из японского автомобилестроения – индустрии, уважаемой большинством программистов, даже не ездящих на «японках».

Кстати, обычно практики приходящие в софтверный инжиниринг из реальной инженерии (строительство, машиностроение, …), отличаются тяжеловесностью, обилием сложных правил и ограничений, содержат строгую специализацию по ролям – ведь в реальном мире все это действительно оправдано, и отклонение от СНИПов и прочих строительных ГОСТов, нарушение последовательности строительных операций, и т.п. – почти гарантированно приводят к проблемам, а зачастую и к катастрофам с человеческими жертвами.

В софтверной же индустрии, используемый при построении информационных систем и других сложных программ «материал» – операционные системы, библиотеки, фреймворки – не менее сложен, чем сталь или бетон, но при этом более гибок, – например, для информационной системы можно (хотя и сложно), без последствий для пользователя, полностью или частично заменить фундамент – сменить используемые библиотеки или даже архитектуру. Поэтому «классическое управление проектами», с диаграммами Ганта и безликими человеческими ресурсами плохо работает в разработке ПО, где для эффективной работы в первую очередь надо сосредоточиться на удобстве командной работы, учитывая психологию разработчика (по отдельности и в группе), минимизируя ручные операции, исключая ненужную работу, т.е. всеми возможными способами повышая мотивацию участников и исключая «узкие места» процесса. Собственно успех Agile-практик показывает, что мораль Крыловской басни «...а вы друзья, как ни садитесь...» к софверной разработке не очень применима, а вот применим скорее сюжет фантастического рассказа «Побег» (из сборника «Лавка сновидений» Ильи Варшавского), где удалось радикально поднять производительность уборки хлопка у заключенных, просто убедив их, что они свободны, и собирают «белые цветы радости».

Этим и объясняется успех Scrum-а для измученных ~~нарзаном~~ RUP-ом или MS Project-ом. Но с другой стороны, у многих, особенно у пришедших к Scrum-у от «методологии ~~Бей и беги~~ Code-and-Fix», возникает много претензий к Scrum-практикам – можно ли еще упростить? Можно ли выкинуть еще один (детский? туземный?) ритуал? …

Так вот, пришедший из автомобилестроения Kanban несет в себе дух Lean-практик, избавляющихся от любых ненужных ритуалов, и содержит в себе всего 3 правила! Сравните с 9 правилами Scrum или более, чем 120 правилами RUP. Неудивительно, что зал нашей компании был полон ПиЭмами, интересующимися – решит ли Kanban их проблемы со Scrum? Можно отказаться от итераций, планирования и жесткого time-boxing-а, не потеряв при этом управляемость и прозрачность процесса?! А, может, как часто бывает, «истина где-то посередине» – и оптимальным будет именно сочетание Scrum и Kanban?

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

Правда мы должны предупредить читателя, что перед тем как смотреть видео, лучше выполнить домашнее задание и прочитать-пролистать вводные материалы по Kanban (собственно это заранее и проделали все собравшиеся):

Ну, а если лень, то тогда наверное лучше начать со второй части видео, где все-таки рассказывается об основных принципах и происхождении Kanban и проводится соотнесение его практик с Scrum.

В целом, содержание видео следующее. Первая часть – вербализация проблем Scrum, которых собравшиеся надеялись решить через Kanban. Была исписана целая ~~стена плача~~ маркерная доска, где были и здравые надежды и претензии типа «...доктор, я смогу после операции играть на скрипке?...», а советы по лечению, под стать вопросам, отсылали даже, скажем, к сексуальным играм для взрослых.

Кратко ключевые слова из этих проблем, ставшие «меню» этой встречи:

«Support Team». Техподдержка, багфиксинг, доработки.
«Сильно распределенная разработка». Разработчики в разных местах, их трудно синхронизовать.
«Сверхкроссфункциональные микрокоманды». Пара парней на все руки (см. сериал «IT Crowd»).
«Безудержный заказчик или нестабильный backlog»/«Несинхронизованный deployment»/«Хаотически меняющиеся приоритеты». Постоянные внезапные форс-мажорные заказы «фич» вне бэклога в текущую итерацию.
«Мутные красные бумажки», «Стек-вместо-очереди», «Research-and-Development».
«Scrum-шизофрения: Два product-ownera на одну команду».
«Случай-в-Питере» — Разработка «Софт-плюс-Железо», сложность синхронизации разных команд с разными технологиями.
«Растянутый Workflow задачи» — долгая многоитерационная постановка, или тестирование на стороне заказчика.
«Технологическая цепочка».
«Существенно разномощные задачи» — «фрагментация корзины бэклога».
«Проектная аритмия» (сбивается ритм демо, планирований, ретроспектив) — разный ритм участников разработки (включая заказчика).
«Проблема счастливой семейной жизни» — waste времени на ретроспективы.
«Дефицит Product Ownerов» — они могут стать критическим ресурсом.
«Расслабляющая команда», «Деградация через самоорганизованное командой уменьшение Scope».
«Трудно форсировать Аврал».

Далее была вторая, лекционная часть-ликбез, про историю, происхождение и основные принципы Kanban. Если вы осилили предложенные ранее ссылки – вполне можно пропустить без особого ущерба.

Ну и далее два часа горячего обсуждения, когда проверяли, сможет ли Kanban вылечить диагнозы, записанные «Доктором Agile» на доске при, так сказать, коллективном дифференциальном диагнозе. Тоже местами было более чем живо, где например услышишь о уставе боя танковых колонн.

Были и здравые идеи о комбинации Scrum и Kanban — например, отсадить на Kanban техподдержку, включая системных администраторов.

Кстати, каждое видео можно скачать (в отличном качестве, с обработкой от видеошумов).

Ну и на память – та самая доска проблем Scrum, которых пытались лечить Kanbanом.

А для любителей подкастов, прилагаем отдельно и аудиозапись:

[на всё окно][свернуть]

Репликация: База Знаний «Заказных Информ Систем» → «Kanban vs. Scrum (встреча AgileRussia.ru 2009-07-07)»

Метрики в Agile (встреча AgileRussia.ru 2009-08-18)

2010-01-20T17:40:25Z

StasFomin:

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

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

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

Однако не все так просто, тривиальные метафоры, может быть и адекватные для простого промышленного производства, не всегда годятся для софтверной разработки. Да и в обычной жизни, много ли из читателей ведут метрики «семейного проекта», в виде, например, семейной бухгалтерии? Ведь вроде бы тут все абсолютно просто, понятно что мерить, понятны бонусы — да и вообще, речь идет о той самой насущной рубашке, которая ближе к телу. А уж когда речь идет о «обычной» бухгалтерии, где в отличие от семейной приходится соответствовать внешним правилам — ненависть может зашкаливать.

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

Например, за метрики ратовал Том Демарко, автор широко разошедшейся фразы «If you can’t measure it, you can’t manage it»^[1], а как выглядит «полное покрытиями метриками» на практике, можно посмотреть здесь, особенно рекомендуем посмотреть живой Project Dashboard.

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

Если метрики связаны с системой оплаты-мотивирования, то все участники будут склонны к поведению, оптимизирующему измеряемые показатели, даже в ущерб общему делу. С этой стороны баррикад можно сослаться на Джоэла Спольски (см. например, его эссе «Измерения продуктивности», «Консалтинг по оценке производительности», «Метод экономической мотивации»), и, как ни странно, опять на Тома ДеМарко, с его свежей статьей «Software Engineering is Dead?!».

Есть и «умеренные» статьи, показывающие, что «меры хороши в меру», что можно найти общий базис для измерения для каскадных и аджайл проектов — см., например, наш перевод «Project Metrics for Software Development».

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

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

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

[на всё окно][свернуть]

Далее три части видео встречи.

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

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

Для подкастеров или просто любителей прилагаем и аудиозапись:

↑ см. Tom DeMarco «Controlling Software Projects: Management, Measurement and Estimation», 1982

Бизнес-метрики в Agile (встреча AgileRussia.ru 2009-09-01)

2010-01-20T17:10:13Z

StasFomin:

1 сентября в нашей компании прошла вторая встреча сообщества AgileRussia.ru, с продолжением темы «Метрики в Agile» (рекомендуем обязательно ознакомиться, с опубликованным нами отчетом по первой встрече). В этот раз, мы решили затронуть бизнес-метрики — в отличие, от более-менее осязаемых командных метрик, штуку более туманную и мистическую, по крайней мере на взгляд собравшихся, в большинстве своем разработчиков, ПМов и тестировщиков, а не бизнесменов.

Вероятно, то, что бизнес-метрики «страшно далеки от народа», объясняется и некоторое плутание коллективного разума при обсуждении — чего и кого только не поминали — от Голдратта до «Теории Ежей». Кстати, по теме рекомендуем почитать наш перевод статьи AgileEVM:_Measuring_Cost_Efficiency_Across_the_Product_Lifecycle с известного Agile-портала InfoQ.

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

Если вы не в курсе, что такое майндмапы («карты памяти», «карты интеллекта», «ментальные карты» — рекомендуем посмотреть наш небольшой доклад по теме майндмапов.

Таким образом, была проведена классификация проблем бизнеса, и этим проблемам были сопоставлены полезные для их решения метрики.

Можно быстро ознакомится с конспектом-результатом встречи, чтобы решить, стоит ли смотреть видео-скрин-под-каст, на котором собственно и происходило построение этого майндмапа (плюс несколько бонусов, как обычно, вставлено при монтаже):

[на всё окно][свернуть]

Видео загружено в высоком разрешении, просьба смотреть его максимизированным (ну, или скачать).

Для желающих — есть аудиозапись встречи:

Репликация: База Знаний «Заказных Информ Систем» → «Бизнес-метрики в Agile (встреча AgileRussia.ru 2009-09-01)»

SECR-2008 (Отчет Стаса Фомина)

2010-01-19T15:46:16Z

BenderBot: 1 версия

GDD2009 (Отчет Клинчаева Олега)

2010-01-15T15:06:01Z

BenderBot: 1 версия

PHP-разгон: серебряная пуля из автомата Комменца-Вальтера (Commentz-Walter)

2010-01-12T17:15:53Z

StasFomin: /* Видео */

Рабочее название: «PHP-разгон: серебряная пуля из автомата Комменца-Вальтера» (Commentz-Walter)».

«Разработка концепции ПО» (семинар UML2.ru)

2009-12-31T16:49:40Z

StasFomin:

26 ноября в нашей компании прошел семинар «Разработка концепции ПО», проводимый в рамках серии семинаров сообщества системных аналитиков UML².ru.

Ведущими были две Ирины: Векленко и Сурова, а аннотация гласила:

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

Понятие концепции (vision). Место концепции в жизненном цикле разработки ПО

Взаимосвязь концепции с артефактами проекта по разработке ПО

Структура концепции

Примеры документа «концепция» в различных методологиях разработки ПО

А у нас все не так! (ответы на вопросы)

Встреча началась с десятиминутного блитц-мульт-разогрева, основанного на нарезке из знаменитой серии Симсонов^[1], иллюстрирующей опасность проектов без внятной концепции, основанных только на следовании пожеланиям клиентов — очень рекомендуем посмотреть, если вы еще не ---.

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

И в результате, удалось увидеть разнообразие концепций — от солидного документа в ворде и составленного совместно с заказчиком кластера статей в вики системе, до простых двух абзацев в Google Docs.

Действительно, бывают концепции строго оформленные по шаблонам «самого Вигерса», из которых ничего невозможно понять, и не приводящие к живым проектам (на встрече рассматривали такие примеры^[2]). А как забавный пример обратного, можно привести историю известной (в узких кругах) игры «EnviroBear2000», успешно реализованной^[3] по одному концепту-абзацу (оригинальная цитата полностью, орфография авторская): «Здраствуйтє, сдєлайтє пажалуста ігру шоб можна била мєдвєдєм кушать ягади і рибу. Да, і шоб мєдвєдь єзділ на машинє. І шоб фізіка била рєалістічная: можна тараніть дєрєв”я, падают шишкі, лістья, оси, скунс. Скунс бєгаєт па машинє, но єво можна схватіть лапай — і викінуть с машини. А іщьо — нада шоби єзділі па лєсу другіє мєдвєді на машинах. С німі можна будєт тараніцца. Всє ричат. На паваротах машину далжно занасіть. Руль крутіть можна лапай. І главнає — шоб нє как в аркадах — пєрєклучєніє пєрєдач ручноє. Ну й пєдаль тада тоже можна лапай жать. Когда мєдвєдь єст рибу — абязатєльна далжни аставцца кості і хвост. Чєрєз пять мінут наступаєт зіма.»

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

↑ «Oh Brother, Where Art Thou?»
↑ См., например, [1]
↑ Адский видеогеймплей можно посмотреть например тут, легко найти и скачать саму игру. А здесь можно увидеть и другие примеры «гениальных концептов геймплея» уровня «можно грабить корованы»

AgileDays-2009 (Technical excelence)

2009-12-18T19:21:53Z

StasFomin:

Представляем краткий отчет и обзор докладов, прошедших на третьем, техническом треке «Technical excelence» конференции AgileDays.ru.

Вообще, мы (Стас Фомин и Андрей Бибичев) осуществляли организационно-техническую поддержку докладов в секции «Technical excelence», в частности, мы сняли и публикуем обработанное видео. Сделали что смогли — цветокоррекция, темпоральная фильтрация шумов, усиление границ (для большей читаемости слайдов), в звуке — нормализация и динамическая компрессия. Некоторую реверберацию (эхо), увы, убрать не удалось (уж очень это трудоемко), сорри.

Видео публикуем и в виде флешвидео (640x512) и отдельно можно скачать видео в оригинальном качестве (720x576). Мы специально оставили изображение слегка вытянутым — и максимум площади из максимально возможного квадрата 640x640 используется, и буквы читаются легче, и люди стройней и симпатичней). Для пары докладов «лекционного» типа, не сильно зависящих от слайдов, мы сделали и аудиоподкасты.

Да, если судить о докладах третьего трека по оперативным отзывам в микроблогах, то отзывов о докладах с остальных треках больше, но это не потому, что доклады тут были самые унылые — просто организованный бесплатный WiFi не добивал до третьего этажа, где проходил трек «Technical excelence», а писать отзывы с мобильников все-таки у нас не так много энтузиастов. К тому же, отзывы в твиттер о конференции, на уже выходят из моды, см. Совет № 3.

Содержание

1 Обзор Agile
2 Обзор Feature-Driven Development и Domain-Driven Design
3 Увидеть лес за деревьями
4 Внедрение Agile
5 8-битный Scrum
6 ОО дизайн: SOLID принципы
7 MS Team System vs IBM Rational Jazz: лучший инструмент разработчика
8 TDD + DDD + MVP + GoF + PoEAA = Love!

Обзор Agile

Докладчик: Никита Филиппов

http://agiledays.ru/reports/themes/view/26/

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

На этом докладе мы рассмотрим:

Плюсы и минусы других процессных подходов: Waterfall, Code & Fix.
Принципы Agile: Anti-code & fix, Anti-Waterfall
Практики Scrum
Чем можно улучшить Scrum?

Это собственно изложение азов ценностей и практик Agile-движения и SCRUM-а в частности, и несмотря на азбучный уровень, доклад оказался весьма полезным. Ведь с одной стороны, на конференции с названием AgileDays, да еще проводящейся не в первый раз, да еще и по теме, которой вроде как уже несколько лет общеизвестна в индустрии, можно было бы ждать, что «все в теме», и «буквари» вроде как издевательство над аудиторией. Но судя по вопросам, в зале было полно людей из параллельных вселенных «мира Дилберта и роговолосых», так что этот доклад оказался незря.

Так что если вы «в теме» — то, скорее всего, ничего нового их этого доклада вы не узнаете. А вдруг слова «Agile» и «SCRUM» незнакомы (или знакомы, но в сомнительном изложении типа «слышал я Карузо…, Рабинович вчера напел…») — то посмотрите или послушайте. «Послушайте» — в смысле эту лекцию можно слушать даже без слайдов — мы выложили подкаст:

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Обзор Feature-Driven Development и Domain-Driven Design

Докладчик: Андрей Бибичев

http://agiledays.ru/reports/view/4/

Эрик Эванс (Eric Evans) в своей книге о Domain-Driven Design (DDD) пишет: «Software development is all design» (Разработка ПО — это всецело дизайн/проектирование). И правда: ведь сборка ПО целиком автоматизируется и не требует ощутимых усилий со стороны проектной команды.

И что же в Agile есть на тему дизайна/проектирования? Scrum об этом молчит. В eXtreme Programming (XP) есть такие практики, как Test-Driven Development (TDD) и Refactoring, но они работают, скорее, на уровне дизайна отдельных классов и их имплементации («микро-дизайн»). А как же быть с архитектурой и «макро-дизайном»?!

«Лучшие собаководы» (гуру архитектуры и проектирования) рекомендуют сочетать проектирование сверху-вниз и реализацию снизу-вверх, то есть макро- и микро- дизайны. Agile-процесс под названием Feature-Driven Development (FDD) как раз базируется на таком подходе. В докладе дается краткое описание как самого процесса, так и его истории. Проводятся параллели с XP и Scrum, дается анализ сильных и слабых сторон, а также области применимости.

Казалось бы, причем здесь Domain-Driven Design (DDD)? В FDD краеугольным камнем является модель предметной области (Domain Model). В DDD — тоже. Но если FDD — это прежде всего процесс, то DDD является подходом к проектированию и реализации, причем этот подход замечательно сочетается с любым Agile-процессом. Кроме того, в DDD много внимания уделено «сшивке» макро- и микро- дизайнов: описаны общие принципы имплементации модели в программном коде, приводятся готовые образцы (patterns) реализации.

Если вы исповедуете Agile-подход к разработке и не используете хотя бы элементы DDD — вы многое теряете и сильно рискуете. Если же вы только присматриваетесь к Agile и пока полны скепсиса, так как в изученных вами материалах по этой теме полно белых пятен, то данный доклад тоже может быть полезен.

Андрей убеждал не останавливаться на тупом, «карго-культовом», внедрении SCRUM-практик, уподобляясь кальсонным гномам, а обязательно развивать архитектурные практики, такие как Domain-driven design и Feature Driven Development, настаивая, что для достаточно большого проекта (от 20 человеко-лет) это не «модное дополнение к SCRUM», а именно необходимый ингридиент.

В целом, аудитория была в теме — достаточно заметить, что на конференции был десант из Нижегородского Интела, где ребята выступали с близким по теме докладом #TDD + DDD + MVP + GoF + PoEAA= Love!, так что четверть часа после доклада шла дискуссия (есть на видео), на темы:

Как избежать анемии доменной модели и бизнес-логики — классически инкапсулировать бизнес-логику в объекты или выносить ее на сервисный слой?
Как должны соотноситься уровень Infrostructure и Domain? Должен ли Domain классически использовать Infrostructure (возможно разделяемую на несколько проектов с разными предметными областями), или, в соответствии с новыми веяниями использовать паттерны «Inversion of Control/Dependency Injection», и Domain ничего не должен знать о Infrostructure, что несколько необычно, но должно давать большой буст при тестировании (можно разгонять тесты, mockiруя тяжелый инфраструктурный слой).
Оправдано ли экономически, играть во все игры с модными паттернами и практиками — понятно, что все это ради качества, но какой ценой? Может это могут позволить себе только очень богатые компании, для inhouse-разработки, или крупные компании для продуктов с огромными тиражами, но ведь в обычной заказной разработке дилемму «скорость-качество», невыгодно радикально решать в пользу последней.

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Увидеть лес за деревьями

Докладчик: Стас Фомин (CustIS)

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

Однако на практике возникает проблема — как быстро и эффективно исследовать этот пласт информации?

Читать логи переписки и коммиты в VCS? То есть разрабатывать «шахту знаний» киркой и мотыгой? Бродить по лесу и считать деревья?
Посчитать метрики? Ненавистные SLOC и иже с ними? В зависимости от глубины детализации можно получить:
- либо пару унылых метрик («KSLOCs в месяц на сферического разработчика в вакууме», то есть в нашей метафоре максимум — «площадь лесного массива»),
- либо многостраничные Excel-dashboardы, заполненные мириадами цифр, в которых почти также бессмысленно лезть человеку, если он не профессор Чарли Эппс из сериала Numb3rs с его верными суперкомпьютерами и волшебными алгоритмами DataMining-a.

Что же делать?

Есть альтернативный способ «увидеть лес за деревьями» и при этом выжать краткую информацию по процессу — Визуализация.

Итак,

Мы покажем модель визуализации коллективной разработки ПО.
Представим portable-фреймворк для такого исследования, адаптированный для максимальной простоты использования — все работает из коробки, просто скормите ему вашу историю.
На выходе — музыкальные ролики визуализации! Их можно смотреть как с исследовательскими целями, так и для удовольствия, радуя себя, команду, и, возможно, приманивая новых сотрудников.
…
PROFIT! Фреймворк раздадим всем бесплатно, и никто не уйдет обиженным!

Собственно, все, о чем был доклад, мы выложили в open-source, и все это можно свободно и быстро попробовать (скачать и запустить на любом проекте — работает из коробки) — ShowTeamWork.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Внедрение Agile

Докладчик: Павел Афанасенко

http://agiledays.ru/reports/themes/view/27/

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

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

Докладчик — известный консультант по вопросам внедрения Agile-практик (SCRUM, eXtreme programming,…), рассказал о нетривиальных проблемах реального внедрения этих практик. Кстати, эту лекцию тоже можно вполне прослушать в отрыве от слайдов:

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

8-битный Scrum

Докладчик: Алексей Омельянчук (Сигма-ИС)

http://agiledays.ru/reports/themes/view/7/

Можно ли использовать гибкие методологии на предприятиях по производству микроконтроллерных устройств? Оказывается, можно!

Представьте, что разработка включает в себя не только написание ПО, но и создание аппаратной платформы, на которой оно будет исполнятся. Более того, процессоры преимущественно используются 8-разрядные, а языки разработки — ассемблер и «чистый» С. Как использовать в этом случае Scrum?

Автор доклада обобщит свой опыт внедрения Agile в трех различных компаниях:

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

Для всех 3-х предприятий характерна выраженная специализация разработчиков, необходимость синхронизации разработки аппаратной и программной части и «размазанный» по нескольким командам Product Owner.

Автор расскажет о том, что сработало, а что не получилось и о том, как помогло применение отдельных методов Lean Development и максимальный упор на раннюю полномасштабную демонстрацию.

Обычно, при словах SCRUM всплывает некоторый стереотип — программисты пишут заказной софт (информационная система, скорее всего с вебинтерфейсом) на основе мощных библиотек и фреймворков, легко удовлетворяя метания бизнес-пользователей за счет заложенной гибкости архитектуры, наслаждаются кроссфункциональностью (в смысле смеются, когда дизайном занимается хардкодер, но в целом все ОК), с энтузиазмом играют во все developers games (ибо в РФ, программист — пока профессия молодых).

А что если нет не то, что лишних пары гигабайт для вечноголодной Жавы, а вообще, есть только 512байт ПЗУ и 32 байт ОЗУ? А если рабочий стол программиста занят не тремя 24" мониторами, а тестерами (в смысле приборами, а не девушками), осциллографами и паяльником? Если специалисты настолько матерые и узкие, что о кроссфункциональности не может быть и речи, а из-за их возраста «standup meetings» приходится отказать?

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

Например, частые демонстрации. Интересно, судя по вопросам, в зале были специалисты из микроэлектронной индустрии, и на их жалобы вида «Как делать регулярное демо (нового прибора), если поставщик только через квартал сможет дать нужную деталь (индикатор)» — докладчик парировал — «Стыдитесь! Для демонстраций и тестирования ~~используйте mock-объекты~~ подключите обычный компьютер с симулятором».

Из отзывов наших сотрудников:

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

Команда его прошла путь от производственного предприятия работающего на МО с жестким Rational Unified Process, через крупного частного производителя контроллеров (крупнейший поставщик АвтоВаза, 2 млн штук в год) до software-предприятия, занимающегося, в основном, программированием, а не железом. На каждом этапе добавлялись новый практики.

Что используются

спринты, ограниченные во времени
демо (по признанию докладчика практика оказалась самой полезной)
планирование. Причем, планируют 120—140 % от запаса времени, с разделением на обязательное и бонусы

Длительность спринта составляет 1 месяц, что было связано со сложившимся на предприятии укладом. Также был «мегаспринт» — 3 месяцы. Эта цифра обусловлена

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

Еще одна особенность — сборные команды. Каждый проект ведется максимум двумя людьми (большему количеству просто нечего делать на устройстве, куда влезает 500 строк ассемблера), команды объединяют несколько проектов. Ни о какой кросс-функциональности речь не идет (одна настройка рабочего места занимает день-два), но таким образом все-таки немного смягчаются риски того, что в случае болезни одного человека, его будет не кем заменить. Scrum-митинги из-за этой специфики проходят на по 15 минут раз в день, а большее время раз в неделю, чтобы было время въехать в чужую предметную область.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

ОО дизайн: SOLID принципы

Докладчик: Дмитрий Кандалов (Deutsche Bank)

http://agiledays.ru/reports/themes/view/17/

В этом докладе я расскажу о SOLID принципах ООП описанных Робертом Мартином (Robert C. Martin) в книге «Быстрая разработка ПО: принципы, паттерны, практики» (Agile Principles, Patterns, and Practices) и что они означают в реальной жизни. Некоторые из этих принципов широко известны в других формах, некоторые очевидны. Но их интерпретация Робертом Мартином одна из лучших и может быть очень полезна для программистов использующих ОО языки.

Докладчик рассказал о наборе принципов софтверного проектирования, скрывающихся за акронимом SOLID:

Принцип единственности ответственности (The Single Responsibility Principle)
Принцип открытости/закрытости (The Open Closed Principle)
Принцип замещения Лисков (The Liskov Substitution Principle)
Принцип разделения интерфейса (The Interface Segregation Principle)
Принцип инверсии зависимости (The Dependency Inversion Principle)

Кстати, если скучно читать эти сухие определения, то посмотрите на набор веселых «демотиваторов» по этой теме. А докладчику дарим бесплатную идею — при следующем выступлении, добавить эти демотиваторы к слайдам.

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

MS Team System vs IBM Rational Jazz: лучший инструмент разработчика

Докладчики: Евгений Злобин (Microsoft) и Тимур Маркунин (IBM)

Как следует из названия, ожидалась совместная презентационная сессия сейлов Microsoft и IBM. Те, кто в кулуарах даже ожидали sales battle, боюсь были несколько разочарованы — никакого экстремального маркетинга не случилось, была последовательная презентация близких по смыслу продуктов, но никакой войны — докладчики очень благожелательно относились друг к другу, иногда даже в ответах на вопросы рекомендуя продукт конкурента.

В некотором смысле разгадка проста. Продукты эти весьма недешевы, причем живут в разных нишах — продукт от IBM, где-то на полпорядка дороже продукта от Microsoft. Так что далеко, не все считают оправданным их приобретение. Да и что говорить, в отличие от 90х годов, где в РФ доминировал («условно-бесплатный») стек разработки от Microsoft (великолепная для своего времени MVS6 — MVC6, MVB6 и т.п.) что соответственно определяло и выбор инструментов (SourceSafe и т.п.), сейчас огромное количество прекрасных бесплатных инструментов организации разработки.

Например, сердцем любого «уникального набора интегрированных систем поддержки разработки» является VCS — система контроля версий. Внутри TFS находится форк известной коммерческой VCS Perforce. Но сейчас появилось много классных централизованных и распределенных систем контроля версий, бесплатных и к тому же open-source, очень активно развивающихся. Недавно мы провели опрос об используемой VCS на центральном IT-портале, где ответило более двух тысяч человек и выяснилось, что коммерческими VCS (подсчет абсолютно по всем вендорам) пользуются менее 4% разработчиков, а в майнстриме среди централизованных VCS — Subversion, а среди распределенных VCS — Git.

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

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

TDD + DDD + MVP + GoF + PoEAA = Love!

Докладчик: Антон Бевзюк (Intel)

http://www.slideshare.net/Nfilippov/tdd-ddd-mvp-go-f-po-eaa-love

Наша команда имеет более чем 6-летний опыт использования гибких методологий.

За это время мы разработали десятки бизнес-приложений. Мы используем передовые практики (Scrum, XP, Kanban) и шаблоны (GoF, PoEAA), доказавшие свою эффективность.

Мы расскажем о том, как мы «поженили» все это разнообразие в одном финансовом приложении. Это приложение спроектировано по Domain-Driven Design (DDD), разработка ведется в строгом следовании парному программированию. Test-Driven Development (TDD) обеспечивает 100 %ное покрытие тестами бизнес-логики, а применение шаблонов MVP и Model-View-Viewmodel позволяет протестировать презентационную логику unit-тестами без применения внешних инструментов для тестирования интерфейса.

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

Отличительной особенностью нашего кода является то, что он вообще не содержит комментариев без ущерба для понимания. Код самодокументирующийся. Мы активно используем DSL для упрощения написания тестов. К настоящему моменту система содержит 4500+ тестов, которые выполняются не более 1 минуты.

Наш доклад раскрывает ряд best practices в области программной инженерии, например:

Автоматизированный деплоймент (на развертывание приложения уходит около 10 минут, делается это одним кликом).
Специализированные парные станции
Совместное использование всех практик XP (синергетический эффект)
Kaizen (постоянный пересмотр как процесса разработки, так и самого кода)
Элементы fun’а

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

Краткое резюме описываемого проекта в цифрах (в стиле заставки сериала «Numb3rs»:

2 года
12 разработчиков
50 человеко-лет (нет, вдумайтесь — это целая человеческая жизнь, по крайней мере, в разумном возрасте, среднего мужчины в РФ)
32 проекта в solution’е Visual Studio
3-хзвенная архитектура (WebForms/WinForms-клиент и MSSQL)
140000 строк
100000 из них — это строки 5000 тестов
20 экранных форм
10 Гб БД.

По нашим меркам, это совсем небольшой проект, с удивительно большими затратами людских и временных ресурсов. Впрочем, читателю лучше сделать самостоятельное сравнение с своими проектами, а для подсчета различных SLOC-метрик рекомендуем использовать утилиту CLOC.

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

Из отзывов наших сотрудников:

С точки зрения архитектуры подход Intel’а отличается от книжного DDD, который описывал в своем докладе и Андрей Бибичев (например, если почитать тут ). Используя принцип Inversion of Control, они изолируют сборку с классами домена от инфраструктуры. Таким образом, домен у них не зависит ни от чего, и поэтому хорошо портируется, тестируется, и легко переносит существенные изменения инфраструктуры. Именно это, «чистый домен», они и ставят во главу угла своего подхода.

…Ребята также показались TDD-экстремистами, не знаю насколько это хорошо или плохо. Их мантры такие

Подумай->Напиши тест, который падает где ты ожидаешь -> Сделай минимальное исправление
Assert, по-хорошему, должен быть один, а исправление — минимальным. Если это не так, скорее всего нужен еще один тест.

… Все-таки они там TDD-маньяки и стремятся оттестировать все, что можно, и что нельзя. С тестированием «чистого домена» все более-менее просто, а дальше они начали тестировать GUI. По опыту прошлых проектов было известно, что ручное и скриптовое тестирование малоэффективно и мучительно. Поэтому они начали думать, как приспособить инструменты и методики unit-тестирования к тестированию GUI. Для этого они начали пересматривать архитектуру GUI-слоя (как неоднократно звучало, TDD — это не тесты, это методика проектирования!)

… Докладчики рассмотрели несколько паттернов устройства GUI (ModelViewController -> ModelViewPresenter -> ModelViewViewmodel). Собственно, смысл этого сводится к тому, чтобы сделать View единственной и максимально простой, зависящей от платформы частью паттерна, а все остальное — покрыть тестами.

… Я так понял, что этот подход позволил им достаточно безболезненно перевести клиента с WinForms на WebForms. С замечанием из зала о том, что для Web-интерфейса с активным использованием JavaScript’а на клиенте такой подход не работает, докладчикам пришлось, …, согласиться.

… Докладчики с гордостью заявляли, что стараются тестировать все, что может сломаться и с чем бывают проблемы: код, конфигурации, хранимые процедуры, даже связывание (binding) GUI. Любопытно, что в тестах они проповедуют принцип «1 тест — 1 assert». Мне не очень понятно, как это можно реально соблюдать, не впадая в безумное дублирование, и какой в этом смысл. Книжное «сразу понятно, что сломалось» смешно — нам почему-то и без этого принципа обычно понятно, что сломалось.

…Реализация DDD-подхода в данном случае состоит в том, что domain описан в отдельной сборке, которая является полностью независимой. Для обеспечения независимости используется прием Inversion-of-Control и одноименная библиотека.

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

…Действительно впечатляющие данные — 5000 тестов у них выполняются за минуту. Около 200 тестов, все-таки требующих наличия БД, у них выполняются минут за 10 и их запускают нечасто.

…Тесты, как известно, должны быть максимально простыми и выразительными. Поэтому они активно используют в тестах всякие практики типа FluentInterfaces, а также забавные методы-расширения, например, для задания дат в виде 11.12.of2009().

… При написании тестов использует свои embedded DSL. Например, вот такое:

var testDate = 11.12.of2009
 
public static class DoubleExtensions
{
    public DateTime of2009(this double date)
    {
        return new DateTime((int)date.Floor(), (int)(date-date.Floor())*100, 2009)
    }
 
}

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

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

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

К сожалению, видео не совсем полное, мудак-оператор (я, Стас Фомин), куда-то задевал конец выступления. Сорри!

Репликация: База Знаний «Заказных Информ Систем» → «AgileDays-2009 (Technical excelence)»

Видеотека

2009-12-13T14:51:46Z

StasFomin: /* 2009-12-09 AgileDays-2009 */

Представляем видеозаписи всех опубликованных семинаров, конференций, проводимых на нашей площадке. Файлы дополняются краткой ссылкой-описанием на отчет о событии (с веб-видео).

~~Файлы размещаются на ресурсе narod.yandex.ru — очень быстрым для скачивания в рунете, порядка гигабайт за 10 минут.~~

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

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

Мы решили навести порядок и избавится от этой промежуточной страницы — теперь все ссылки на скачивание файла (обычно с narod.ru) размещаются под веб-версией видео (которое обычно на vimeo.com), на страницах соответствующих семинаров, докладов и прочих event-ов.

ShowTeamWork

2009-12-08T20:52:16Z

VitaliyFilippov:

Экстремальное программирование (встреча AgileRussia 2009-11-09)

2009-11-26T19:44:55Z

StasFomin:

9-го ноября в нашей компании прошло очередное собрание сообщества AgileRussia.ru, в этот раз была лекция Павла Афанасенко об Экстремальном Программировании (Extreme Programming), одной из концепций-прародителей всего Agile-движения.

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

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

Также прилагаем гибридное видео — видео из зала с обсуждением, параллельно с составлением майндмапа. Видео можно смотреть в вебе, а можно скачать.

Для желающих ненапряжно послушать обсуждение в «фоне», без «полного погружения» — прилагаем подкасты.

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

Deadline (Демарко)

2009-11-11T20:00:39Z

VitaliyFilippov: Массовая правка: замена Категория:Рецензии на Категория:Рецензии на книги, замена Category:Рецензии на Category:Рецензии на книги

Автор: Том ДеМарко (он же Том Де Марко)
Название: «Deadline. Роман об управлении проектами» (The Deadline: A Novel About Project Management')
Читать: http://www.litru.ru/?book=139

Одежка для Subversion - ViewVC и SVNSearcher

2009-11-05T15:13:17Z

BenderBot: 1 версия

Презентацию можно увидеть здесь.

MediaWiki

2009-11-03T18:47:08Z

VitaliyFilippov:

MediaWiki — Серверная вики-система, один из самых мощных вики-движков, написанный специально для Википедии и использующийся во многих других проектах. См. RuPedia:MediaWiki

Все вики-системы в нашей компании, включая CustisWiki, реализованы именно на этом движке.

Статья реплицируется в SMWiki, SBWiki, RDWiki, GZWiki, DPWiki, HRWiki, CBWiki, ORWiki, RAWiki, ITWiki, CRMWiki, NordeaWiki, EvolWiki, TMSWiki.

Репликация: База Знаний «Заказных Информ Систем» → «MediaWiki»

Статья реплицируется в Wiki4IntraNet.

Consolas в консоли

2009-11-02T19:07:19Z

BenderBot: 1 версия

Многим хороша командная строка (в Windows) — одно плохо, придется использовать уродливые raster-шрифты. Как для командной строки, так и для классных приложений с текстовым интерфейсом, типа Far.

По уму, надо бы иметь возможность выставлять для cmd или Far окна нормальные TrueType/Monospace шрифты, типа:

Consolas
DejaVu Sans Mono
подставьте ваш любимый monospace-шрифт.

Оказывается это можно, только нужно, как обычно сделать безумные магические пассы над реестром:

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 00 /d Consolas

и/или

reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v 000 /d "DejaVu Sans Mono"

Фишка в том, что таким образом можно создавать в очередной реестро-эрогенной зоне

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont

последовательность ключей «0», «00», «000», «0000» — куда забивать TrueType-monospace шрифты, которые тогда разрешать для выбора в консольных окнах.

Социально-психологические аспекты Agile (встреча AgileRussia 2009-10-19)

2009-10-26T12:31:17Z

StasFomin:

19 октября в компании Заказные ИнформСистемы прошло очередное собрание сообщества AgileRussia.ru, в этот раз была гуманитарная тема — «Социально-психологические аспекты Agile», а вел/модерировал встречу Сурен Самарчян, известный активной практикой внедрения Agile даже на уровень топ-менеджмента компаний.

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

Можете скачать его и руководствуясь им выделить интересные темы и написать полноценную статью.

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

Subversion

2009-10-26T08:23:48Z

StasFomin:

Subversion — свободная централизованная система управления версиями, созданная в 2000 г. компанией CollabNet Inc.

В 2007 году независимая компания Forrester Research, сравнивая преимущества и недостатки различных систем, оценила Subversion как «единоличного лидера в категории Standalone Software Configuration Management (SCM) и сильного участника в категории Software Configuration and Change Management (SCCM)».

В CustisWiki есть наши переводы статье идеологов этой системы, см. Категория:Статьи о Subversion.

JIRA

2009-10-25T20:13:56Z

AlexanderSokolov:

Atlassian JIRA (http://www.atlassian.com/software/jira/) — система чуть более широкая, чем только багтрекер, это Issue Tracking system — то есть система учета запросов как таковых. Система имеет веб-интерфейс, очень гибко настраивается под конкретный проект.

Distributed Version Control Systems: A Not-So-Quick Guide Through

2009-10-25T20:07:16Z

BenderBot: 1 версия

Перевод статьи «Distributed Version Control Systems: A Not-So-Quick Guide Through» от Sebastien Auvray с портала InfoQ.

Sébastien Auvray — senior software designer и энтузиаст технологий. Его заставляли использовать CVS и SVN, теперь он страдает на работе от ежедневного использования Perforce. Sébastien также один из редакторов InfoQ по теме Ruby.

К моменту перевода прошел уже год, и многие положения статьи изменились — самые очевидные исправлены переводчиком (Стас Фомин) (в частности, исправлены битые ссылки), часть снабжены сносками, указывающими на произошедшие изменения.

После выступления Линуса Торвальдса в Google в мае 2007, просвященного GIT, постоянно растет интерес и число пользователей распределенных систем контроля версий (Distributed Version Control Systems, DVCS).

Тут мы сначала сделаем краткое введение в понятия распределенного управления версиями, посмотрим, когда это стоит использовать, и почему, этом может быть лучше, чем то, что вы используете сейчас, и затем мы взглянем на трех ключевых игроков в этой области: git, Mercurial и Bazaar.

Алан Купер об интерфейсе. Основы проектирования взаимодействия

2009-10-12T20:09:32Z

VitalyKozlovtsev:

Автор: Алан Купер
Страница издательства: http://www.symbol.ru/date/638484.html
Рецензия: http://aboutface.gui.ru/

Психбольница в руках пациентов

2009-10-12T19:25:02Z

VitalyKozlovtsev:

«Психбольница в руках пациентов. Алан Купер об интерфейсах. Почему высокие технологии сводят нас с ума и как восстановить душевное равновесие. Издание исправленное»

Автор: Алан Купер
Страница книги на сайте издательства: http://www.symbol.ru/novelty/666332.html
Рецензия: http://habrahabr.ru/blogs/books/19393/

Методы и алгоритмы вычислений на строках

2009-10-12T18:44:16Z

VitalyKozlovtsev:

Автор: Билл Смит
Страница издательства: http://www.williamspublishing.com/Books/5-8459-1081-1.html
Рецензия: http://www.rsdn.ru/res/book/prog/stringalgs.xml

Репликация: База Знаний «Заказных Информ Систем» → «Методы и алгоритмы вычислений на строках»

SconsDynamicallyAddTargetToExecutor

2009-10-08T18:55:07Z

StasFomin:

[svg]

Consider the following situation.

MainFile includes some GeneratedNN files (count of these files is unknown)
All these GeneratedNN files (+some other files) generated by one Generator file (for example, python script).
All included GeneratedNN files needed to be rescanned after generation (they can include other files).

I scan MainFile, and then I see inclusion of Generated1 file, I add something like this:

    cmd=env.Command(Generated1, Generator, RunMePlease)

But actually I need

    cmd=env.Command([Generated1,Generated2,…,GeneratedN], Generator, RunMePlease)

but I must add targets incrementally during MainFile scan…

So the question is: How to dynamically add targets to Command? I try something like

Generator.executor.targets.append(env.fs.Entry(GeneratedN))

but it seems not working…

Agile-metrics-for-business

2009-09-17T17:15:35Z

VitaliyFilippov:

[на всё окно][свернуть]

FeedOnFeeds

2009-09-16T12:21:07Z

VitaliyFilippov:

FeedOnFeeds («Лента Лент») — серверный многопользовательский RSS и Atom -агрегатор (веб-приложение).

Оригинальная версия мертва. Есть пара живых «форков» — наш и RomanSixty. В нашем форке упор на производительность + мелкие новые фичи, у RomanSixty из фич есть адаптивный расчёт времени обновления.

Репозиторий нашего форка: https://github.com/vitalif/FeedOnFeeds либо http://yourcmc.ru/git/summary/FeedOnFeeds.git
Сайт старой версии: http://www.feedonfeeds.com/
Язык разработки: PHP
Распространение: copyleft, opensource (лицензия GPL).

SuperGenPass

2009-09-10T14:34:31Z

VitaliyFilippov:

«Полное и окончательное решение проблемы паролей в Интернет»

Project Metrics for Software Development

2009-09-05T16:06:21Z

BenderBot: 1 версия

Перевод статьи http://www.infoq.com/articles/project-metrics

Автор: Carlos Sirias.
Перевод: Стас Фомин.

AgileEVM: Measuring Cost Efficiency Across the Product Lifecycle

2009-08-28T15:45:07Z

BenderBot: 1 версия

http://www.infoq.com/articles/agile-evm

Автор: Tamara Sulaiman

Tamara Sulaiman — консультант по управлению в компании SolutionsIQ, специализирующаяся на тренингах по переходу на SCRUM команды и организаций. У Тамары более 15 лет опыта в бизнес-управлении и разработке ПО. Она Certified Scrum Trainer (CST) и Project Management Professional (PMP).

AgileEVM — это некоторая адаптация традиционной практики управления проектами, заключающейся в измерении и сверке текущих значений:

общих затрат (integrated cost);
сроков (schedule);
объема функционала (scope);

с первоначальным планом (baseline plan), используя метрики «Управления Освоенными Объемами» (Earned Value Management, EVM).

Эти методы измерений были модифицированы, чтобы с легкостью вписаться в рамки SCRUM-практик управления проектами. AgileEVM можно использовать для измерения эффективности затрат совместно с традиционными EVM-метриками в течении всего жизненного цикла продукта. Это существенно дополнит Agile-управление на протяжении всего жизненного цикла продукта, заранее предупреждая о нездоровых тенденциях.

Так как «AgileEVM» использует те же метрики, что и традиционные EVM-техники управления освоенными объемами, их обоих можно сочетать, получая комбинированную методологию, дающую результаты на более высоком уровне.

Например, «освоенные объемы», полученные из какого-нибудь Agile-проекта, можно скомбинировать с таковыми, вычисленными для традиционно-планового проекта, или даже портфеля проектов, и получить таким образом общие «освоенные объемы» (earned value).

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

Agile Modeling with Mind Map and UML

2009-08-17T18:44:16Z

BenderBot: 1 версия

Перевод статьи Agile Modeling with Mind Map and UML.

SVNSearcher

2009-07-30T12:38:44Z

VitaliyFilippov: /* Примечания */

SVNSearcher — система полнотекстового поиска по содержимому Subversion-репозиториев, в том числе, и по старым ревизиям файлов. Поддерживает (с минимальными телодвижениями) русскоязычную морфологию и офисные форматы документов, а также разграничение прав доступа к файлам.

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

Для поиска по SVN и CVS репозиториям мы рекомендуем нашу сборку ViewVC вкупе с Apache Tika и поисковым сервером Sphinx.

Сайт: http://svn-search.sourceforge.net/
Распространение: свободная, с открытым исходным кодом^[1].

↑ Единственное упоминание о лицензии на сайте SVN-Searcher — «You can download, use and develope the project according to OpenSource licence». Будем считать, что имеется ввиду according to any OpenSource license.

WikiHelper

2009-07-16T14:54:30Z

BenderBot: 1 версия

WikiHelper — расширение для браузера Mozilla Firefox, позволяющее редактировать файлы из MediaWiki во внешних программах, например, SVG формата — в Inkscape.

Последняя доступная на данный момент версия — 1.0.218 (218 — по номеру последней ревизии Subversion, в которой менялся код). Тестировалась с Firefox/Iceweasel версий 3.0.11 и 3.5, теоретически, должна работать и с более новыми, и с более старыми.

Programmer Insecurity

2009-06-30T21:16:11Z

BenderBot: 1 версия

Programmer Insecurity/Комплексы Программиста

Перевод статьи «Programmer Insecurity/Комплексы Программиста» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

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

Всегда был стереотип, что программисты асоциальны:

 Q: How do you know when an engineer is outgoing?
 A: He looks at your shoes!

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

Мой приятель Фитц и я долго проповедовали о best practices в разработке приложений с открытым исходным кодом — когда человек должен быть открытым и честным с работой другого, воспринимать разбор своего кода и уметь конструктивно критиковать, и, главное, активно общаться с коллегами.

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

У кого есть время, чтобы отрецензировать тысячи строк кода? А что, если там были неправильные архитектурные решения с самого начала? Есть ли теперь смысл указывать на это?

Сбрасывание такой «кодовой-бомбы» в сообщество, редко когда идет проекту на пользу: команда либо должна либо полностью отклонить ее, либо принять и иметь дело с гигантским мутным BLOB-ом, который трудно и понять, и править, и поддерживать. К тому же, это явно двигает проект в некотором направлении без всяких обсуждений или консенсусных решений.

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

Они хотят работать одни, в пещере, и только потом открыть сообществу свой «идеальный» код, как будто бы в нем никогда ошибок и не было.

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

Похоже, они охотно делятся кодом, только когда могут показать, что они «непогрешимы». Хотя, возможно это в природе человека.

Оцените несколько историй, которые я собрал:

Просьбы на конференции «Google I/O»

 Пару недель назад, когда моя команда была на конференции «Google I/O»,
 мы поставили демонстрационный стенд, посвященный сервису поддержки проектов с открытыми исходными кодами.
 Раз за разом, мы получали просьбы типа:

«Ребят, вы можете заставить Subversion в Google Code возможность прятать определенные ветки?»
«Парни, а можно создавать открытые проекты поначалу скрытые от мира, а потом раскрыть их, когда они будут готовы?»

По сути, они говорили одно и то же: «Я не хочу, чтобы люди видели процесс моей работы, пока она не стала идеальной»

Просьбы в список рассылки Google Code

Почистить так или иначе svn-репозиторий на Google Code. Встречаются и разумные причины — например, случайный коммит секретных данных, или необходимость загрузить полностью историю из другого SVN-репозитория.

Но в основном, мы получаем некорректные (да, мы их отклоняем) просьбы вроде «Привет, я хочу переписать свой код с самого начала. Вы могли бы уничтожить историю?». Это значит «Я не хочу, чтобы люди увидели мой старый код, мне так за него стыдно!»

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

Код-ревью воспринимаются как личные нападения

Фитц рассказал смешной анекдот о своем друге, который перешел из мира open-source в корпоративную разработку. Перескажу своими словами:

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

Мораль: рецензии кода далеки от стандартной практики в корпоративном сообществе, более того, большинство программистов не способны отделить свои хрупкие «Я» от кода, который они пишут.

Повторяйте за мной: ты это не твой код!

Использовать распределенный контоль версий — быть в пещере

Один мой друг работает над несколькими проектами, в которых используют git и mercurial. Недавно он рассказал мне следующую историю.

В основном, он работал с двумя командами над проектом.

Одна команда часто публиковала изменения… «… в результате у меня была возможность постоянно просматривать их проект в течении семестра, регулярно предлагая улучшения дизайна и предоставляя рецензии на код… …В результате этого [их проект] развивается на полном ходу и практически функционирует.

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

В прошлое воскресенье один из них зашел ко мне с багом […] и я наконец смог увидеть код, чтобы помочь отладить его. Это мне не удалось, потому что там были 5000 строк мусорного кода, и просмотр лишь одного файла выявил две или три серьезных ошибки в проектировании и дюжину сыро реализованных мест.

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

Я не знаю, боялись ли они опубликовать это, или только не заботились об этом. Но так или иначе, учитывая код, что я видел, практический результат составляет 5 потраченных впустую месяцев.»

Прежде, чем Вы начнете возражать — да да, я знаю, что потенциально cave-hiding («разработка в тайной пещере») и написание кодовых бомб возможно и с использованием централизованной системой управления версиями, такой, как Subversion.

Но у моего друга есть интересная точка зрения:

Я думаю, что этот недостаток имеет место по крайней мере частично из-за того, что DVCS даёт легкий способ обнести себя стеной и забраться в пещеру. Если бы мы использовали svn, я думаю, что «пещерный» барьер был бы слишком высок, и я сразу бы увидел этот код.

Другими словами, да, это было бы в основном социальной проблемой. Команда запуталась в распределении кода.

Но, так как они использовали распределенное управление версиями, у них возникла видимость ложной безопасности.

«Смотрите, мы коммитим изменения в наш репозиторий каждый день … прогресс!»

Если бы они использовали Subversion, то гораздо менее вероятно, что они сидели бы над патчем из 5000 строк в их рабочей копии в течение 5 месяцев; они должны были бы показать работу намного раньше.

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

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

Хорошо, так, каково заключение? — Просто очевидно, что люди боятся показывать незаконченную работу.

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

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

Вот классическая «рекомендация» для системы вроде git (взято из комментария в блоге): «Не надо говорить мне, что я должен сотрудничать с другими людьми в начале и публиковать мои изменения как можно раньше. Я сотрудничаю с другими людьми, но иногда хочу делать определенную часть работы в одиночку.»

Хм, ладно! Только не работай в одиночку слишком долго!

Немного отступая от основной темы, скажу почему я предпочитаю Mercurial Git-у, проделав некоторые исследования и прочитав немного об этих системах.

Git гораздо более склонен к «пещерности», а я этого не люблю.

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

Другой пример: когда приходит время отправки и получения наборов изменений, поведение по умолчанию для Mercurial состоит в том, чтобы обменяться историей с удаленным репозитарием, тогда как git в этом случае только отправляет и получает отдельную ветвь — предположительно ту, которую пользователь счел нужным сделать общедоступной.

Другими словами, git по умолчанию считает, что вся работа «пещерная», и с радостью уничтожает историю. Mercurial же по умолчанию разделяет все, и не может стирать историю.

Я знаю, этот пост получился очень длинным, но дайте мне еще постоять на трибуне из ящика из-под мыла:

Будьте ясными.
Постоянно публикуйте свою работу.
Приветствуйте обратную связь.
Воспринимайте критику.
Дайте возможность другим людям найти ваши ошибки.
Ваш код — это не вы сами.
Не бойтесь ежедневных ошибок — учитесь на них (Как говорят в Google, «не беги от ошибки — ошибайся часто, быстро, и учись!»).
Храни всю свою историю, и удачи, и ошибки.

Все эти приемы — путь совершенствования в программировании. Если вы не следуете им, вы обманываете свое собственное развитие.

Уф-ф! Теперь я чувствую себя лучше.

↑ http://blog.red-bean.com/sussman/?p=96

Subversion или CVS, Bazaar или Mercurial

2009-05-08T16:50:22Z

BenderBot: 1 версия

Перевод статьи «Subversion or CVS, Bazaar or Mercurial» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

↑ John Ferguson Smart, JavaWorld.com, 09/18/07, http://www.javaworld.com/javaworld/jw-09-2007/jw-09-versioncontrol.html

Линус Торвальдс о GIT на Google Talks

2009-05-03T01:53:07Z

BenderBot: 1 версия

Перевод доклада Линуса Торвальдса о системе контроля версий git на «Google Talk» ^[1], выполнен сообществом компании «Заказные ИнформСистемы».

↑ Оригинальное видео доклада http://www.youtube.com/watch?v=4XpnKHJAok8

Darwin Information Typing Architecture

2009-04-06T15:53:20Z

BenderBot: 1 версия

Darwin Information Typing Architecture (DITA) — способ написание технической документации на основе XML разработанный в компании IBM. Данная статья написана в результате исследования технологии DITA, как возможного стандарта документирования в компании.

Используется в компаниях:

IBM
Oracle
Adobe
Autodesk
EMC
Nokia
McAfee, Inc.
Sybase, Inc.
и другими, полный список тут http://dita.xml.org/deployments
так же используется для документирования в проекте Apache Derby (база данных)
существует ряд коммерческих CMS систем поддерживающих DITA

Основные преимущества:

ориентация на темы при написании текста;
ориентация на повторное использование текста;
специализация;
обработка на основе свойств;
использование существующих тегов и инструментов.

Основные свойства:

основана на плоской XML-разметке;
поддерживает произвольные теги разметки;
возможность преобразования в форматы:
- wordrtf
- pdf
- html
- xhtml
- eclipsehelp
- eclipsecontent
- javahelp
- htmlhelp
- xml docbook
- troff

ViewVC

2009-03-27T09:57:18Z

VitaliyFilippov:

ViewVC — система онлайн-просмотра репозиториев систем версионного контроля CVS и Subversion. Ранее называлась ViewCVS.

Сайт: http://www.viewvc.org/, http://viewvc.tigris.org/
Лицензия: Permissive, типа MIT. Free & OpenSource.
Версия с нашими доработками (ViewVC4Intranet): https://github.com/vitalif/viewvc-4intranet
Ниже значком () помечены фичи, присутствующие только в нашей версии.

Оперативное хранилище в АБС – два в одном

2008-09-19T16:27:25Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».
Андрей Таранов, аналитик ООО «Заказные ИнформСистемы».

«Оперативное хранилище в АБС – два в одном»^[1]

Летом 2003 года в Интернете проходила дискуссия экспертов-представителей банков и фирм-разработчиков банковских систем, под названием «Хранилища данных. Для чего они нужны банкам?» (интересующихся подробностями отошлем на сайт).

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

«На данном этапе развития российского рынка банковских информационных технологий уместно ставить вопрос иначе «Хранилища данных. Почему их нет в банках?»…
В области организации управленческого и аналитического учета хранилища данных на текущий момент являются функционально лучшим решением, однако, есть несколько недостатков, которые являются основной причиной весьма ограниченного распространения хранилищ данных в современном банковском бизнесе, прежде всего цена решения и трудоемкость его внедрения.
Вышеуказанные причины приводят к тому, что на текущий день ситуация такова, что бума на установку хранилищ данных в банковском секторе ожидать не приходится. Вместе с тем хранилища данных и системы поддержки принятия решений, нужны и необходимы банкам.»

На наш взгляд, причина сложившейся ситуации лежит в устоявшемся представлении о том, что для автоматизации оперативной и аналитической работы банку необходимы различные системы. Начиная с первых публикаций о хранилищах данных, всегда подчеркивалась разница задач, решаемых OLTP-системами и хранилищами. Эти задачи требовали различных средств и различных, специально оптимизированных для этого, структур. OLTP и хранилище рассматривались как независимо существующие компоненты. Связь между ними односторонняя — данные выгружаются из OLTP в хранилище. Как правило, автоматизация этих компонент — это два различных независимых проекта на различных программно-аппаратных платформах, причем решения выбираются от разных фирм-поставщиков. Соответственно, расходы на приобретение систем удваиваются. Усилия персонала банка на внедрение и сопряжение отдельных систем с трудом поддаются координации.

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

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

К созданию подобного оперативного хранилища (аналитической АБС) нас привел детальный анализ бизнес-задач клиента, показавший, что аналитические данные регулярно используются в процессе оперативного управления. И мы предположили, что аналитическое хранилище не обязательно должно быть физически отделено от OLTP-системы. Более того, хранилище может быть погружено в OLTP-систему и фактически составлять ее базовый компонент. Именно такой вариант реализован в нашей банковской системе GROSS (с сентября 2004 г. CustIS Bank), базирующейся на учетно-аналитическом ядре CustIS Accounting® (одна из торговых марок компании «Заказные ИнформСистемы»).

Конечно, этот подход отличается от классического. Однако следование строгой теории едва ли оправдано тогда, когда речь идет о возможности принципиального удешевления сложных программных решений и, в конечном итоге, о налаживании оперативного управления бизнес-процессами в банке. На сегодня, в обычной банковской практике разрыв между запросом руководителя к аналитику, получением оперативных данных и ответным формированием управляющих воздействий может занимать дни, а то и недели. Пытаясь решить эту проблему, мы пришли к выводу, что совмещение хранилища и OLTP открывает путь к реальному управлению в режиме on-line с непрерывным замкнутым контуром обратной связи.

↑ «Банковские технологии», №7-8.2003, стр. 56-59.

Промышленная биллинговая система в ЖКХ г. Курчатова

2008-09-19T16:11:08Z

BenderBot: 1 версия

Автор

Михаил Татаренков, руководитель направления «Радей» компании «Заказные ИнформСистемы».
«Промышленная биллинговая система в ЖКХ г. Курчатова»^[1]

Город Курчатов, расположенный в Курской области — одно из тех редких мест, где новейшие технологии идут рука об руку с обычной жизнью. Оно и понятно, статус атомграда ко многому обязывает. Наверное, именно поэтому идея коренной модернизации городской системы расчетов за жилищные и коммунальные услуги была встречена здесь как вполне естественное начинание, необходимое для динамичного развития сферы ЖКХ. По той же причине ставка при выборе новой системы была сделана на промышленную технологию, которая уже успела зарекомендовать себя в других городах России.

Так в 2006 году в ЕИРКЦ г. Курчатова был инициирован проект внедрения программно-технологического комплекса «Радей», созданного московской компанией «Заказные ИнформСистемы». С декабря 2006 г. по июль 2007 г. система работала в режиме опытно-промышленной эксплуатации. В июле 2007 г. программно-технологический комплекс (ПТК) «Радей» (www.radey.ru) был сдан в промышленную эксплуатацию. За 6 месяцев в городе с населением более 40 тысяч человек была полностью модернизирована единая общегородская система расчета, приема и учета платежей за жилищно-коммунальные услуги. Нельзя сказать, что обошлось совсем без трудностей. Как это случается практически во всех проектах модернизации РЦ, особые усилия потребовались в ходе внедрения — при выверке и переносе данных в новую систему.

Сейчас программный комплекс «Радей» успешно установлен на сервере в «Едином информационно-расчетном кассовом центре (ЕИРКЦ) г. Курчатова». Он обслуживает пять абонентских пунктов, расположенных в разных частях города. Абонентские пункты взаимодействуют с расчетным центром в режиме on-line. В любом из абонентских пунктов жители города могут оплатить жилищно-коммунальные услуги, получить разъяснения по начислениям и принципам расчета, зарегистрировать изменения на лицевом счете. Каждый пункт оснащен современным оборудованием, которое существенно повысило эффективность работы персонала и увеличило скорость обслуживания населения. Это позволило избавиться от очередей без потери качества обслуживания.

Начисления сумм платежей в биллинговой системе «Радей» выполняются как с использованием нормативных тарифов, так и на основе показаний приборов учета, что в последнее время становится особенно актуально. Система успешно справляется практически с любой расчетной задачей, стоящей перед ЕИРКЦ, будь то перерасчет сумм за отопление по итогам аномально теплой зимы или же учет недопоставки из-за временно неработающего лифта.

В состав единой квитанции, ежемесячно выставляемой населению г. Курчатова, вошли начисления:

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

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

В результате внедрения ПТК «Радей» ЕИРКЦ г. Курчатова получил современную систему автоматизации расчетов и начислений, которая способна оперативно настраиваться под изменения жилищного законодательства. Новый программный комплекс не только заменил собою устаревшее ПО, но также значительно расширил возможности ЕИРКЦ. Экономический эффект от внедрения проявился быстро: уже в первые месяцы эксплуатации системы сбор денежных средств от населения превысил 100%, поскольку жители стали оплачивать не только текущие начисления, но и свои долги по ЖКХ.

Причем, все денежные средства, полученные от населения в уплату за ЖКУ, оперативно направляются МУП «ЕИРКЦ» непосредственно поставщикам ЖКУ в строгом соответствии с договорными обязательствами и объемами оплаты. За счет этого обеспечивается максимально эффективное функционирование городского жилищно-коммунального комплекса в части информационных и финансовых потоков.

В ближайшее время в г. Курчатове планируется внедрить новый модуль «Радей-Паспортный стол». Предполагается принимать плату за услуги гаражных кооперативов (фактически в городе на одну квартиру приходится по одному гаражу), за услуги стационарной телефонии и кабельного телевидения. Планируется также подключить к ПТК «Радей» ближайшие к г. Курчатову населенные пункты. Таким образом, ЕИРКЦ удается одновременно расширить и круг поставщиков услуг, и территорию обслуживания. А это, в свою очередь, ведет к ускоренной окупаемости всех инвестиций в проект модернизации информационной системы.

Не останавливаясь на достигнутом, МУП «ЕИРКЦ» планирует в 2008 году установить у поставщиков жилищно-коммунальных услуг и управляющих компаний (по их желанию) выносные терминалы, обеспечивающие им оперативный доступ к информации о начислении и оплате по предоставленным услугам.

Также в 2008 году МУП «ЕИРКЦ» планирует запустить собственный сайт, обратившись к которому, посетители смогут:

получить общие сведения о деятельности расчетно-кассового центра, узнать режим работы, адреса и контактные номера телефонов отделений МУП «ЕИРКЦ»;
просмотреть информацию по лицевым счетам за жилищно-коммунальные и иные услуги, понять, как формируется оплата за ЖКУ, а также с внедрением системы виртуальной оплаты оплатить свои счета в режиме он-лайн;
узнать о ценах, тарифах и услугах;
ознакомиться с нормативными документами, федеральным, региональным и муниципальным законодательством, согласно которому происходит начисление оплаты за ЖКУ;
узнать о льготах и субсидиях на оплату за ЖКУ;
просмотреть информацию о плановых ремонтах и отключениях в своем доме.

В дальнейшей перспективе МУП «ЕИРКЦ» — обеспечить возможность оплаты гражданами счетов за ЖКУ в режиме он-лайн непосредственно со своего персонального компьютера.

Еще одно отличие данного проекта — технология сопровождения системы. Впервые в истории внедрений ПТК «Радей», а возможно и впервые за всю историю городских расчетных центров успешно применена модель практически полного аутсорсинга услуг сопровождения. Не секрет, что зачастую заказчик опасается оставить за поставщиком решения работы по технической поддержке внедренного решения. Да и в финансовом отношении использование собственной ИТ-службы кажется, на первый взгляд, более выгодным, чем услуги профессиональной команды. Однако в случае Курчатовского ЕИРКЦ заказчик счел возможным положиться на специалистов, и не жалеет об этом. Техническую поддержку и сопровождение ПТК «Радей» в «ЕИРКЦ г. Курчатова» из Москвы оказывает сервисный центр разработчика системы — компании «Заказные ИнформСистемы».

↑ Журнал «Коммунальный комплекс Подмосковья», №1 (февраль) 2008.

Парадоксы развития информационных систем: количественный подход

2008-09-19T16:11:03Z

BenderBot: 1 версия

Автор: Елена Сомина, начальник управления банковских технологий ООО «Заказные ИнформСистемы».

«Парадоксы развития информационных систем: количественный подход»^[1]

Информационная система динамично развивающегося коммерческого банка сама должна быть способна к изменениям. С этим тезисом, кажется, уже никто не спорит, но как оценить этот потенциал программной системы? Как сопоставить скорость развития бизнеса и возможности адекватного развития систем его автоматизации?

Как Вы думаете, с какой скоростью изменяется автоматизированная банковская система (АБС), установленная в Вашем банке? И в каких единицах можно это измерять, в каких терминах оценивать изменение? Например, в терминах числа новых бизнес-задач, подвергшихся автоматизации, или времени, затраченного на разработку новых функций в АБС? Считать ли число измененных за период отчетов и правил ведения документооборота или количество освоенных новых банковских продуктов в АБС?

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

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

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

Работа с метаданными осуществляется компанией-разработчиком и специалистами-технологами банка в рамках самой АБС. История изменения метаданных фиксируется в базе данных и доступна для изучения. При таком подходе банковский продукт или услуга представляется в АБС как декларативное описание на уровне метаданных всех составляющих его жизненного цикла: содержания продукта, последовательности смены его состояний в процессе жизненного цикла, шаблонов для его учета по различным планам счетов, его отражения в отчетах.

Таким образом, изменение набора и содержания метаданных впрямую коррелирует с содержательными изменениями наполнения банковской системы: вводом новых банковских продуктов и изменением уже имеющихся (модификацией документооборота, бизнес — логики и т.п.)

Из большого статистического материала об изменениях всех компонент АБС (интерфейсных форм, программного кода, метаданных), накопленного в процессе ее развития, мы решили использовать сведения о метаданных, приняв в качестве количественной характеристики динамики изменения банковских систем число изменений записей о метаданных. Ее анализ привел нас к выводам, довольно интересным и неожиданным с точки зрения обычной практики выбора и приобретения АБС.

Подробный анализ изменения метаданных мы провели на примере нашей банковской системы CustIS Bank, которая 5 лет функционирует в небольшом стабильно работающем банке, который нельзя отнести к быстро развивающимся. На основании информации о создании, изменении, удалении метаданных за все годы эксплуатации АБС были построены графики зависимости количества модифицированных метаданных от времени. На рис.1 мы можем наблюдать заметную динамику их эволюции.

Рисунок 1.

Точка А₀ — старт «операционного дня» в новой АБС. Первые 8 месяцев длилось развертывание системы, внедрение и адаптация — график демонстрирует увеличение количества метаданных почти в 4 раза. После этого (частки B и С) началось экстенсивное развитие АБС. За 4 года штатной эксплуатации и сопровождения количество созданных метаданных по отношению к точке А₁ составило 85%, а с учетом правок уже существующих метаданных изменения достигли 164%.

В итоге — примерно 40%-е среднегодовое изменение наполнения системы метаданных, отражающее динамику развития бизнес-процессов в банке за период «стационарной» эксплуатации (данные в точке А₂ по отношению к точке А₁). Причем вне этого графика остались изменения программного кода (которые уменьшаются по мере развития системы, поскольку в нашей технологии кодирование формирует «стабильный» фундамент системы), а также изменения интерфейсных форм и внешней отчетности для ЦБ РФ.

Для иллюстрации содержания изменений в АБС рассмотрим участок С — это «бурный» 2004 год. На рис.2 в увеличенном масштабе видны скачки в объемах метаданных, связанные с изменениями требований ЦБ РФ и федеральных законов (валютное законодательство, финансовый контроль). На этот же период пришлась перестройка работы внутри банка, реорганизация, повлекшая изменение бизнес-процессов и документооборота.

Рисунок 2.

Мировой опыт показывает, что динамика изменений требований заказчика при развитии программной системы достигает 2-10% в месяц в период интенсивной разработки и уменьшается на этапе стационарного развития. В приведенном нами примере на эксплуатационном этапе функционирования АБС средняя скорость изменения составила примерно 3.5% в месяц. Поскольку параметры нашего проекта вполне уложились в мировую статистику, мы можем надеяться, что не ошиблись с выбором единицы измерения сложности системы.

↑ «Банки и технологии», №1-2005, стр 24-28.

Современная IТ-стратегия для динамичного банка — исполнение по заказу

2008-09-19T16:10:57Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Современная IТ-стратегия для динамичного банка — исполнение по заказу»^[1]

Заголовок статьи может удивить читателя, привыкшего к тому, что в течение последних лет ему настойчиво предлагают покупать тиражные разработки автоматизированных банковских систем (АБС), да и выбирать сейчас действительно есть из чего. Правда, выбор этот нелегок. Почитав рекламные материалы и поговорив с персоналом фирм-разработчиков, Вы заметите, что на первый взгляд все предлагаемые продукты очень похожи: все «идут от документа», все «работают в технологии клиент-сервер», практически все уже работают на промышленной СУБД и т. д. Да и предлагаемый набор банковских функций практически один и тот же: во всех системах есть все, что нужно, и даже больше того. Однако при более внимательном рассмотрении обнаруживается, что под терминами «клиент-сервер», «документы» и даже «технологии Oracle» понимаются достаточно разные вещи. При детальном изучении функционала, Вы нередко убеждаетесь, что предлагаемая система не полностью отвечает (или полностью не отвечает) потребностям Вашего банка. Естественно, встает вопрос о доработке продукта конкретно для Вас, и бойтесь тех, кто скажет, что это дешево.

В этой статье мы бы хотели представить иную стратегию автоматизации — заказную разработку банковской системы, обосновать ее жизненность и конкурентность по сравнению с традиционным подходом.

Конечно, мы отнюдь не отрицаем целесообразность приобретения банками тиражных систем. Однако, как нам представляется, не для всех типов проектов эта стратегия оптимальна. Поэтому вначале уточним, какие задачи стремятся решать банки, обновляя свои АБС.

↑ «Банки и технологии», № 4-2003, стр. 32-36.

Экономичная стратегия проектов по заказной разработке

2008-09-19T16:10:51Z

BenderBot: 1 версия

Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».

«Экономичная стратегия проектов по заказной разработке»^[1]

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

В книге известного консультанта в области управления Дэвида Майстера «Управление фирмой, оказывающей профессиональные услуги» приводится классификация, которой, на наш взгляд, вполне удовлетворяет и все разнообразие ИТ-проектов. В терминологии автора книги, это проекты типа «мозги», «седина» и «процедуры». Для того, чтобы объяснить логику подобного разделения необходимо ввести понятие «рычаг» проекта.

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

Рис.1. «Рычаг» проекта по Д. Майстеру

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

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

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

Понятие «рычага» — ключевое для анализа экономики проектов и, соответственно, управление разными типами проектов и ценообразование в них совершенно различны.

↑ Журнал Intelligent Enterprise (Корпоративные системы),№ 20, 31 октября 2005, стр.40-43.