Новостные каналы

В журнале Intelligent Enterprise (№4/2012) опубликована статья руководителя проектов и архитектора Виктора Яницкого, посвященная ИТ-поддержке реструктуризации бизнеса.

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

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

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

Мы публикуем полную версию статьи.

И снова видео. Снова с конференции. Теперь с межгалактической международной SQADays-11, прошедшей месяц назад в Киеве.

И хотя прилагательное «международный» сейчас значит очень мало, в данном случае, тут важно, что на конференции действительно было много докладчиков из Украины и Белоруссии, где, скажем честно, индустрия разработки и тестирования развивается гораздо активней, чем в РФ, и в частности в Москве^[1]. Т.е. если нужно слушать практиков, а не тренеров-преподавателей-маркетологов-кабинетных методологов, то вот, это самое то. Конечно, многие доклады могут показаться наивными, но это практика, это хардкор. Вот неплохой характерный отчет о конференции: [1], [2], рекомендуем глянуть, если вы еще не.

Для нас же, «международность» была дополнительными рисками, ибо пришлось тащить кучу видеооборудования через границу, рискуя расстаться с ним, а потом, в поте лица, организовывать видеосьемку, за считанные минуты обучая волонтеров из киевского QA-сообщества^[2], ранее этим не занимавшихся… Да, благодарность за хорошую операторскую работу^[3], надо направлять им. Условия для сьемки, были, как обычно, ужасные → затемненные залы, чтобы было видно экран, «черные докладчики в контровом свете экрана…»…

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

Собственно, публиковать видео мы начали сразу после конференции, через неделю уже была опубликована половина, но сейчас мы хотели бы «задеплоить релиз» из более полусотни видео, собственно это практически все доклады, за исключением тех, от которых докладчики, выступавшие на своих ноутбуках не прислали скринкаст^[4], одного повторного доклад англоговорящего автора, повторившего свой доклад с SQADays-10, и пары докладов, которые то ли не снимали, то ли утеряли кассеты.

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

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

---

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

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

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

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

Так это или нет? Давайте посмотрим.

1. ↑ Ну мало кто аутсорсит разработку и тем более тестирование в Москву, по понятным причинам. Да и законодательство в IT-области в этих странах либеральней
2. ↑ Ребята, можете присылать ваши контакты-ссылки на профили → вставлю благодарность со ссылками
3. ↑ И, разумеется, недовольство плохой…
4. ↑ «Нет времени на это» ©

В рамках благородной миссии распространения актуальных околоIT-шных знаний, мы выбрались за пределы чистой разработки-тестирования в область менеджмента, причем менеджмента продуктов. А именно, сняли и опубликовали видео с конфренции неконференции^[1] ProductCampSPB.

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

Темы выступлений, круглых столов, семинаров и тренингов:

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

Product Management — штука достаточно новая, и из-за слова «management» еще далеко не все способны отличить спокойного, как слон, «линейного менеджера проектов», следящего, чтобы все было «тихо и вовремя», от безумных визионеров, пытающихся угадать, ЦЕЛИ, каким быть продукту, на что клюнут пользователи, и пойдут стройными рядами, под дудочку Гамельнского Крысолова, а за что их будут ненавидеть: «Идиоты из XXX, верните как БЫЛО! Какой *** придумал YYY? Как это взбрело в его ***?». Собственно на последние вопросы и можно получить ответ, просмотрев этот баркэмп в записи, ибо среди докладчиков было полно ЛПР^[2] по развитию известных массовых сервисов, которыми с вероятностью чуть более чем полностью, пользовался каждый пользователь интернета.

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

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

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

---

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

Успешного просмотра, не переключайте канал, оставайтесь с нами!

---

1. ↑ Организаторы упирают на инновационность, и альтернативность формата по сравнению с «обычными» конференциями — event, т.е. barcamp был бесплатен для участников, и формат был таков, что почти каждому желающему дали возможность высказаться (крепость eventа, т.е. процент докладчиков среди участников достигал 40%). Однако теперь, для видеозрителя докладов, разница невелика — есть доклады, мастер-классы, круглые столы, с аннотациями/слайдами, и их можно смотреть.
2. ↑ Лиц Принимающих Решения
3. ↑ Известны случаи, когда такие позиции можно было получить, прочитав по дороге на собеседование «предисловие» к какому-нибудь учебнику по маркетингу, а спустя несколько лет давать с высоты топ-позиции интервью в «Рунетологии». Сейчас «предисловие» наверно не покатит, а вот свежая конференция — вполне…
4. ↑ Как обычно, с аннотациями, инфографикой развернутых по площади слайдов и т.п.
5. ↑ В плеере VLC — кнопка «]»

Наш следующий семинар из цикла семинаров для студентов состоится 24 мая в 18.30, место встречи изменить нельзя — Конференц-зал компании «CUSTIS». Проведет семинар Андрей Моисеев.

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

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

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

Для регистрации на семинар, как всегда, нужно отправить заявку на адрес hr@custis.ru с указанием:

• дата семинара,
• ФИО,
• вуз/факультет,
• ваш мобильный телефон.

Ждем всех желающих!

И снова анонсируем наш очередной семинар, который состоится 17 мая в 18.30, место встречи — Конференц-зал компании «CUSTIS», ведущий семинара — Павел Музыка.

Семинар состоит из двух тематических частей. В первой части доклада мы представим обзор технологии Windows Presentation Foundation, расскажем об истории и перспективах ее развития, вторая будет посвящена техническим аспектам технологии: будет представлена архитектура WPF, основы технологии, показаны примеры реализации различных сценариев использования.

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

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

Для регистрации на семинар нужно отправить заявку на адрес hr@custis.ru с указанием:

• дата семинара,
• ФИО,
• вуз/факультет,
• ваш мобильный телефон.

Приходите! Скучно не будет!

Привет от HR-службы «CUSTIS»!

На следующей неделе в четверг (10 мая), сразу после праздников, пройдет первый семинар из цикла организуемых нами семинаров для студентов. Читать будет Роман Корешков.

Ждем всех желающих в 18:30 в Конференц-зале компании «CUSTIS».

Вы думаете, что JavaScript — это не серьезный полу-язык программирования для быстрого переключения картинок на веб сайте? Современные примеры интерактивных веб-приложений (facebook, gmail, google docs, office 365…) доказывают обратное. JavaScript вкупе с HTML 5 набирает обороты, ведущие вендоры (Microsoft, Oracle, IBM) все больше внимания уделяют этой технологии, каждый день рождается все больше библиотек, подходов, механизмов на JavaScript.

На семинаре мы расскажем вам о наблюдаемом развитии от Web 1.0 к Web 3.0, его истоки и причины. За короткий промежуток времени мы продемонстрируем вам как изменялись подходы к применению JavaScript-а на протяжении десятилетий, и какой подход использует наша компания в веб проектах.

На семинаре будет показано как правильно «приготовить» JavaScript, чтобы он стал полнофункциональным объектно-ориентированным языком. Среди ингредиентов — библиотека ExtJS, которая достойно отвечает вызовам современного тренда, и позволяет разрабатывать крупные приложения с богатым и удобным пользовательским интерфейсом, не уступающим по качеству desktop-приложениям.

Напоминаем, что для регистрации на семинар нужно отправить заявку на адрес hr@custis.ru с указанием:

• дата семинара,
• ФИО,
• вуз/факультет,
• ваш мобильный телефон.

Приходите, будем рады!

В журнале IT News (№ 7/2012) опубликована статья «Автоматические модульные тесты при разработке корпоративного ПО» ведущего разработчика Андрея Ковалева.

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

Андрей Ковалев: «Автоматические тесты экономят время как первоначального тестирования кода разработчиком (открытие форм, ввод данных, ожидание…), так и последующего регрессионного тестирования (благодаря таким тестам, его можно частично автоматизировать, то есть избавиться от избыточности).

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

Мы публикуем полную версию статьи.

В журнале «Коммунальный комплекс России» (№3/2012) опубликована статья «Взаиморасчеты в ЖКХ: кто виноват и что делать?» ведущего аналитика нашей компании Татьяны Лисиной.

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

Татьяна Лисина: «Огромное преимущество ЕРЦ состоит в том, что качественные информационно-расчетные услуги становятся доступными для малых и средних управляющих компаний, а значит, и для граждан, которых они обслуживают.

Дополнительные преимущества получает при этом и муниципалитет. В базе данных ЕРЦ объединяются и структурируются данные по всему городу и даже региону. За их правильностью и актуальностью следит само население, заинтересованное в корректном начислении оплаты, в учете аварий и других недопоставок, в достоверности сведений о показаниях счетчиков, о работах и услугах управляющих компаний. Расчетный центр с современной биллинговой системой является для органов муниципальной власти надежным и удобным источником достоверной и актуальной информации о происходящих в ЖКХ процессах».

Мы публикуем полный текст статьи.

Хватить о конференциях, не хватает времени написать о действительно важных вещах, касающихся и компании, и наших добрых знакомых^[1].

Пишет Стас, так что будет много букв…

---

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

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

И было очень непросто подобрать офис, в котором можно выстроить комфорную среду для гуманной разработки. О чем идет речь? Ну вот, например, на выбор очень креативные проекты ITшного офиса. Но мы-то знаем, что комфортной разработки в open-space быть не может, времена typing pools должны остаться в прошлом веке или в странах третьего мира. И мы усиленно искали просторный офис, с высокими потолками и кабинетной системой, чтобы каждой команде^[2] — отдельный кабинет, с окнами, вентиляцией и звукоизоляцией, удобной мебелью. Офис в центре^[3], в пятиминутной^[4] пешеходной доступности от нескольких магистрально-транспортных веток (метро-электрички).

Итак, теперь мы живем на Лесной 43, в историческом здании с интересной судьбой^[5].

Добираться до него легко — пять минут от Белорусской или семь от Менделеевской/Новослободской (обратите внимание на нетривиальный оптимальный путь от нее) → карта. Многим удобно добираться на электричках Белорусского и Савеловского вокзала.

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

Тут по-уму нужны фотки, но фотоаппарата у меня нет, а в своих способностях «снимать красиво на телефон» я несколько сомневаюсь. Поэтому просто поверьте, что внутри все отремонтировано «у лучшем виде», сверкают шиком переговорки, команды в уютных комнатах, в коридорах полезные штуки типа принтеров-сканеров, кулеров^[6], банкоматов и т.п.

В общем, готово почти все.

Единственно, что не совсем готово и наверное самое важное для тех, кто у нас [еще] не работает, а только гостит на открытых семинарах — это конференц-зал.

И это повод, показать вам немного креативных картинок, рассказать о планах, и по возможности, выслушать советы.

На старом месте у нас был неплохой, творческий и адаптированный под IT-семинары конференц-зал, с комфортом, хорошей акустикой и близостью всех зрителей к экранам.

На новом месте, под конференц-зал выпало пространство несколько неправильной формы, так, что трудно придумать альтернативу вот такому одноэкранному размещению:

Но мы приложили максимум усилий, чтобы максимизировать этот единственный экран, сделали его максимально большим (4 метра шириной), и даже «расхачили» потолок, чтобы повесить его повыше.

Планируется хитрое освещение перед сценой, с стеной темного цвета, направленными светильниками на натянутых ниже проволочных штангах (см. картинку), чтобы не «засвечивать экран» и при этом осветить и выделить докладчиков^[7].

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

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

Как такая идея?

Идея дополнительных сидушек на креслах для задних рядов…

•  Гениальна
•  Хороша
•  Терпима
•  Бред, Unusable
•  Не знаю, хочу посмотреть результаты…

Кстати, если кто знает, где их купить — пожалуйста, напишите мне или в комментарии.

---

Теперь поговорим, о таком незаметном и на первый взгляд незначительном предмете, как правильный компьютер в конференц-зал.

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

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

Сначала несколько опытных фактов.

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

• Маркерная доска — нифига не видно дальше первого ряда, дикий гемор и низкое качество, если записывать на видео.
• Набор слайдов, перещелкиватель «вперед-назад» и лазерная указка:
  • Мало возможностей, связаны руки — нельзя показать ничего живого, порисовать.
  • Указание лазерной указкой не видно на скринкасте — в таких случаях приходится показывать (и записывать) и вид экрана через камеру, и скринкаст.
• Докладчик, активно управляющий компьютером (гуд!), но спрятавшийся от зрителей за монитором (буу!).

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

Чего только не пробовали:

• Гиромышь Logitech Air — жутко неудобная и утомляющая штука.
• Беспроводной трекболл и беспроводная клавиатура с тачпадом

• Беспроводной планшет Logitech Wacom.

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

Тогда мы перешли к экспериментам с устройствами типа «указываю, где касаюсь-пишу».

• Полусамодельный маркер «интерактивная доска на экране проектора» на базе приемника от Nintendo Wii:

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

Потом мы завели тачскрин-накладку на 24" монитор, который у нас был в конференц-зале.

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

Но и этот вариант оказался неидеальным:

• Накладка не прилегала вплотную к экрану, а отстояла на пару сантиметров, в результате, ухудшалось качество изображения (напоминало дебильные накладки на ЭЛТ, типа «Русский Щит», для защиты от «вредных излучений»).
• «Тачевость» была неидеальной, надо рисовать чем-то жестким, ногтем или ручкой — однажды весь тачскрин на докладе исписали обычной шариковой ручкой, я одурел, пока его очистил.
• Штука кстати, была дорогой, целиком монитор с тачскрином, был бы не сильно дороже.
• Но! Эксперимент с этой штукой показал, что и обычный тачскрин-монитор — это тоже неправильно. Ибо обычный монитор также:
  • Побуждает докладчика сидеть, стоя неудобно смотреть (не говоря уже о том, чтобы писать-рисовать). А ведь важная функция монитора — чтобы докладчик никогда не поворачивался к проектору передом, и соответственно к зрителю задом.
  • И даже сидя, рисовать не очень удобно, ибо малый вес монитора приводит либо к качаниями-дрожанию, либо к дополнительной нагрузке на точное удержание стилуса.

Решения есть!

Первое — носимый компьютер. Нет, речь не идет о безумных киборг-шлемах, а скорее о трансляции видеосигнала по воздуха с планшета (Ipad → AppleTV → HDMI…), или, даже с обычного ноутбука^[8].

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

Фишка в том, что он

• более массивный, чем обычный монитор (проблема тачскрин-монитора, как и монитора с тачскрин-накладкой — неустойчивость, дрожание,…)
• и адаптирован под разные углы — т.е. его можно выставить под 30%, и прекрасно видеть то, что на экране (не надо оборачиваясь к экрану и не садясь «за монитор»), рисовать на нем из положения стоя, причем, думаю, вполне смогут и несколько активных участников.

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

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

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

Как такая идея?

Идея здорового тачскрин-моноблока, как идеального конференц-компьютера:

•  Гениальна
•  Хороша
•  Терпима
•  Бред, Unusable
•  Не знаю, хочу посмотреть результаты…

Замечания? Предложения? → Welcome в комментарии.

Ибо хотелось бы сделать все правильно, ведь ожидаются и встречи сообществ, и семинары для студентов, и … чтобы нам самим было удобно проводить внутренние семинары и демонстрации.

---

1. ↑ Бывших и будущих сотрудников, тех, кто посещал наши семинары и прочие события
2. ↑ Впрочем, мне одному в кабинете тоже неплохо…
3. ↑ Это справедливо и удобно для большинства сотрудников, добирающихся со всех сторон света московского метрополиса
4. ↑ Несколько офисов вполне пешеходной, по моим оценкам доступности, были забанены простым юнит-тестом «представь себя девушкой на каблуках зимой в гололед»…
5. ↑ Ходят слухи, что там была женская тюрьма, и если задержаться на работе ночью, могут приставать призраки женского пола… Или это были не призраки?
6. ↑ Не знаю, может это уже и норма, но у нас кулеры могут делать и газировку! Я вот люблю газированный горячий чай — такого за деньги не купишь!
7. ↑ Вечная неразрешимая проблема почти всех офисных конференц-залов
8. ↑ См. [1]

Дмитрий Морозов, ведущий системный инженер нашей компании, рассказал журналу Intelligent Enterprise об эффективном внедрении частного облака. Что дает перевод инфраструктуры в облако и как его проводить в условиях непрерывности бизнес-процессов компании? Своим опытом Дмитрий делится в комментарии к статье «Незаметная революция» (о внедрении облачного решения в РГТЭУ).

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

Мы публикуем полный текст комментария.

Опять эти конференции…

Итак, завтра-послезавтра наши будут на Software People-2012.

От нас будут следующие доклады:

Коля Гребнев

«Разработчик, аналитик, заказчик — как найти общий язык?»

Максим Цепков

DDD: Реализуем проект «Вавилонская башня»

Стас Фомин

«Корпоративный Болливуд» или Видеопоток знаний на конвейере

Встретимся на Software People!

Завтра-послезавтра наши будут на AgileDays. Будет и доклад Коли Гребнева, но можно и так вволю пообщатся в свободном зале (open-space).

Например, Максим Цепков хотел бы обсудить тему корпоративного управления знаниями.

Будет и Стас Фомин, который с удовольствием поговорит на тему эффективных инструментов, и может даже что-нибудь покажет.

Встретимся на AgileDays!

В конце книги Мартинов «Принципы, паттерны и методики гибкой разработки на языке C#» я наткнулся на перепечатку прелюбопытнейшей статьи 1992 года «Что такое проектирование программного обеспечения» («What is software design»), Jack W.Reeves, C++ Journal.

Я хотел всего-лишь сослаться на эту статью на русском языке и только привести несколько примечательных фраз, но о ужас:

• я не смог найти электронной версии этой книги (ни yandex, ни google не помогли — неужели совсем стали лавочки прикрывать :O, да простят меня блюстители всего лицензионного)
• я не смог найти этой статьи на русском языке. Есть лишь ужасный перевод в Computerra.

Пришлось отсканировать, ибо оно того стоит.

Для тех, кто не ленится учить родной язык IT индустрии (а таких, к сожалению, немного), статья в оригинале: http://www.developerdotstar.com/mag/articles/reeves_design.html

---

Похоже, объектно-ориентированные методики, и язык С++ в частности, покоряют мир программного обеспечения. Появились многочисленные статьи и книги о применении новых технологий. Вопрос о том, не является ли ООП очередной рекламной шумихой, сменился обсуж­дением, как извлечь из этой технологии максимум выгоды с мини­мальными усилиями. Объектно-ориентированные методики появились не вчера, но этот взрыв популярности представляется не совсем обыч­ным. Откуда такой внезапный интерес? Предлагались самые разные объяснения. По правде говоря, нельзя назвать какую-то единственную причину. Возможно, сочетание различных факторов достигло критиче­ской массы и началась реакция. Тем не менее похоже, что самым зна­чимым фактором на этом последнем этапе революции в мире ПО стал сам язык С++. У этого явления, наверное, тоже есть много причин, но я хочу взглянуть на него под несколько иным углом зрения: С++ при­обрел популярность потому, что облегчает как проектирование ПО, так и программирование.

Возможно, мое замечание показалось вам странным, и это неслучайно. В этой статье я как раз и хочу рассмотреть связь между программирова­нием и проектированием ПО. Уже почти 10 лет меня не оставляет ощу­щение, что индустрия программного обеспечения в целом не улавливает тонкого различия между разработкой проекта программы и тем, что на самом деле представляет собой такой проект. Я полагаю, что из ра­стущей популярности С++ можно извлечь важный урок о том, что нам нужно сделать, чтобы стать лучшими инженерами-программистами. А заключается он в том, что суть программирования — не изготовление программного обеспечения, а его проектирование.

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

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

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

У взгляда на код как на проект программы есть одно следствие, затме­вающее все остальные. Оно настолько важно и очевидно, что для по­давляющего большинства организаций, занимающихся программным обеспечением, оказывается мертвой зоной. Речь идет о том, что изго­товление ПО стоит очень дешево. Его даже нельзя назвать недорогим; оно дешево настолько, что уже почти бесплатно. Если исходный код - это проект программы, то ее изготовлением занимаются компилято­ры и компоновщики. Мы часто называем процесс компиляции и ком­поновки полной программной системы «сборкой». Капитальные вло­жения в оборудование для изготовления ПО низки — требуется лишь компьютер, редактор текстов, компилятор и компоновщик. Если все необходимое имеется, то для сборки программы требуется лишь немно­го времени. Может показаться, что компиляция программы на С++ из 50 ООО строк занимает вечность, но подумайте, сколько времени ушло бы на изготовление аппаратной системы такой же сложности, как про­грамма на С++ из 60 ООО строк?

Еще одно следствие взгляда на код, как на проект программы — тот факт, что создать проект программы относительно легко, по крайней мере, если говорить о механическом труде. На написание (то есть проектиро­вание) типичного программного модуля длиной от 50 до 100 строк обыч­но уходит всего пара дней (его отладка — совсем другое дело, но об этом ниже). Так и хочется спросить, есть ли еще какая-нибудь инженерная дисциплина, позволяющая порождать проекты такой сложности, как программы, в такое же короткое время. Однако сначала надо понять, как измерять и сравнивать сложность. Но в любом случае очевидно, что программные проекты довольно быстро становятся очень большими. Учитывая, что программные проекты относительно легко выпускать, а изготовление ПО практически бесплатно, неудивительно, что проекты оказываются невообразимо большими и сложными. На первый взгляд факт тривиальный, но при этом часто игнорируют размер задачи. Учеб­ные проекты часто насчитывают несколько тысяч строк кода. Есть от­крытые программные продукты размером 10 ООО строк. Но мы давно уже прошли тот этап, когда простые программы могли представлять значительный интерес. Проекты типичных коммерческих продуктов состоят из сотен тысяч строк, а есть немало таких, где строк миллио­ны. К тому же проекты программ почти всегда постоянно изменяются. Даже если текущий проект насчитывает всего несколько тысяч строк кода, на протяжении жизни продукта могло быть написано во много раз больше.

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

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

Общее мнение таково, что когда настоящий инженер завершает проект любой сложности, он уверен, что изделие будет работать. Кроме того, он уверен, что изделие можно изготовить, применяя общеприня­тые методы производства. Для достижения такой уверенности проек­тировщики оборудования тратят много времени на перепроверку и до­водку проекта. Возьмем, к примеру, проект моста. Перед тем как его возводить, инженеры рассчитывают прочность конструкции, строят компьютерные модели, создают выполненные в масштабе макеты и про­дувают их в аэродинамической трубе или испытывают иным способом. Короче говоря, проектировщики делают все возможное, чтобы удостове­риться в качестве проекта еще до того, как приступить к его изготовле­нию. Конструирование нового самолета еще более трудоемко; тут нужно построить прототип в натуральную величину и испытать его в воздухе, подтвердив тем самым заложенные в проект характеристики.

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

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

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

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

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

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

Если уж заимствовать что-то из японских методик управления, то пре­жде всего то, что наказание рабочих за ошибки приводит к обратному результату. Вместо того чтобы силой заставлять разработчиков при­держиваться неверной модели процесса, мы должны пересмотреть сам процесс и сделать так, чтобы он помогал, а не препятствовал созданию более качественного ПО. Это лакмусовая бумажка в инженерном про­ектировании ПО. Когда мы говорим «инженерный», то имеем в виду организацию процесса, а не то, что для получения окончательного про­ектного документа необходима САПР.

Основная проблема разработки ПО заключается в том, что все являет­ся частью процесса проектирования. Кодирование — это проектирова­ние; тестирование и отладка — тоже часть проектирования. И то, что мы привычно именуем проектированием ПО, — всего лишь часть про­ектирования. Да, изготовление программного обеспечения обходится очень дешево, зато его проектирование невероятно дорого. ПО настоль­ко сложно, что существует множество аспектов проектирования, а зна­чит, и способов взглянуть на него. Проблема в том, что все эти аспек­ты взаимосвязаны (как, впрочем, и в проектировании оборудования). Как было бы здорово, если бы проектировщики верхнего уровня могли игнорировать детали алгоритмов модулей. Или если бы программи­сты могли забыть о проекте верхнего уровня, когда проектируют вну­тренние алгоритмы модуля. Увы, аспекты одного уровня проекта про­никают в другие. Выбор алгоритмов работы отдельного модуля может оказаться для общего успеха системы столь же важным, сколь и любая из сторон проекта верхнего уровня. Не существует иерархии важности аспектов проекта программы. Ошибка в проекте модуля самого нижне­го уровня может оказаться такой же фатальной, как и на самом верх­нем уровне. Проект программы должен быть полным и правильным во всех отношениях, иначе программа, построенная по этому проекту, будет содержать ошибки.

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

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

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

Например, недавно я работал над проектом, где между модулями А в В была обнаружена временная зависимость. К сожалению, внутренний механизм модуля А был скрыт абстракцией, не позволявшей вызывать модуль В в нужной последовательности. Естественно, к моменту обна­ружения этой проблемы было уже поздно изменять абстракцию модуля А. Как и следовало ожидать, далее последовал сложный набор «исправ­лений» внутренней структуры А. Еще до того, как мы закончили рабо­ту над версией 1, у всех появилось чувство, что проект разваливается. Каждое новое исправление грозило разрушить предыдущие. Это нор­мальное явление в проекте разработки ПО. В конце концов мы с кол­легами решились изменить проект, но, чтобы уговорить руководство, пришлось согласиться на неоплачиваемую переработку.

Такие проблемы гарантированно возникают в любом программном проекте типичного размера. Как ни старайся, что-то существенное обя­зательно упустишь. Здесь мы видим разницу между ремеслом и инже­нерным подходом. Опыт может подсказать нужное направление. Это ремесло. Но идти, полагаясь на опыт, можно лишь до тех пор, пока не вступишь на неизведанную территорию. А дальше нужно взять то, с чего мы начали, и улучшить его путем контролируемых уточнений. Это инженерный подход.

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

В инженерном проектировании ПО нам отчаянно нужен хороший про­ект на всех уровнях. И в особенности — качественный проект верхнего уровня. Чем он лучше, тем проще будет заниматься детальным проек­тированием. Проектировщики должны использовать все, что может по­мочь. Структурные диаграммы, диаграммы Буча, таблицы состояний, языки описания проекта и т. д. — если это помогает, пользуйтесь. Но нужно иметь в виду, что сами эти инструменты и нотационные системы не есть проект программы. Рано или поздно нам предстоит создать истинный проект, и он будет выражен на языке программирования. Поэ­тому не бойтесь кодировать проект, когда он начинает вырисовываться. Просто нужно быть готовым к уточнению по мере необходимости.

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

Вероятно, лучше изначально дать проектировщикам возможность пи­сать код, чем нанимать кого-то, кто переведет независимый от языка проект на язык программирования. Что нам нужно, так это унифици­рованная нотационная система, пригодная для всех уровней проекти­рования. Другими словами, нам нужен язык программирования, спо­собный передавать также проектные идеи. Вот тут-то и вступает в игру С++. Это язык программирования, пригодный для создания реальных программ, но также и выразительный язык проектирования ПО. На С++ можно непосредственно передать высокоуровневую информацию о компонентах проекта. Это упрощает как первоначальное составление проекта, так и его дальнейшее уточнение. Наличие строгой проверки типов также помогает выявлять ошибки проектирования. Тем самым мы получаем более надежный проект, или, если хотите, лучше инже­нерно проработанный проект.

Рано или поздно проект программы должен быть представлен на не­коем языке программирования, а затем проверен и уточнен с помощью цикла сборки/тестирования. Притворяться, что это не так, просто глу­по. Подумайте сами, какие средства и методы разработки программ получили наибольшее распространение. В свое время прорывом счита­лось структурное программирование. Его популяризовал язык Pascal, который и сам приобрел популярность. Объектно-ориентированное проектирование — новое повальное увлечение, и в центре него находит­ся С++. А что не сработало? CASE-средства? Популярны, но не универ­сальны. Структурные диаграммы? То же самое. А также и диаграммы Уорнера-Орра, диаграммы Буча, диаграммы объектов — список може­те продолжить сами. У каждой технологии есть свои сильные стороны и один общий недостаток — это не настоящий проект программы. На самом деле единственной нотацией для проектирования ПО, которую можно назвать распространенной, является язык PDL и все, что на него похоже.

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

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

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

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

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

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

Подведем итоги:

• Реальная программа выполняется на компьютере. Это последова­тельность нулей и единиц, записанная на каком-то магнитном носи­теле. Это не листинг программы на С++ (или каком-то другом языке программирования).
• Листинг программы — это проектный документ. А сам проект изготавливается компилятором и компоновщиком.
• Изготовить реальную программу очень дешево и по мере увеличе­ния быстродействия компьютеров становится все дешевле.
• Спроектировать реальную программу безумно дорого, поскольку программы невероятно сложны и практически все этапы создания программного продукта — это части процесса проектирования.
• Программирование — это разновидность проектирования. Хорошие проектировщики поняли это и, не колеблясь, кодируют, когда необходимо.
• Кодировать имеет смысл чаще, чем многим кажется. Зачастую про­цесс представления проекта в коде выявляет упущения и влечет за собой дополнительное проектирование. Чем раньше это случится, тем лучше окажется проект.

• Коль скоро изготавливать ПО так дешево, формальные инженерные методы проверки работоспособности проектов не слишком востребо­ваны. Гораздо легче и дешевле изготовить, а потом протестировать проект, чем тратить усилия на доказательство его корректности.
• Тестирование и отладка — эквивалент проверки и уточнения проекта в других инженерных дисциплинах. В правильном процессе разра­ботки важность этих этапов не принижается.
• Есть и другие виды проектирования ПО — можете называть их про­ектированием верхнего уровня, проектированием модулей, струк­турным проектированием, проектированием архитектуры или как-то еще. В правильном процессе проектирования они учитываются и осознанно включаются соответствующие шаги реализации.
• Все виды проектирования взаимосвязаны. Правильный процесс разработки предусматривает — порой радикальные — изменения про­екта, если на каком-то этапе проектирования выясняется, что это необходимо.
• В процессе проектирования потенциально полезны разнообразные нотационные системы — в качестве вспомогательной документации или средства для упрощения проектирования. Однако они не явля­ются частью проекта программы.
• Разработка ПО по-прежнему является скорее ремеслом, нежели ин­женерной дисциплиной. В основном это объясняется недостатком строгости в критически важных процессах проверки и улучшения проекта.
• В конечном счете достижения в области разработки ПО зависят от успешного развития методов программирования, что, в свою оче­редь, означает дальнейшее совершенствование языков программи­рования. С++ можно считать таким совершенствованием. Он завое­вал популярность потому, что оказался основным языком програм­мирования, непосредственно поддерживающим проектирование ПО.

• С++ — шаг в правильном направлении, но этого недостаточно.

---

Эта мысли, думаю, могут прояснить спор между Владимиром Рахтеенко и Мишей Заборовым на тему, чего больше в программировании — рутины или творчества. Примерно в том же соотношении, что и у проектировщика моста (или автомобиля) в конструкторском бюро, только время от проектирования до результата много меньше. Соответственно и плотность и рутины, и творчества — больше.

---

Вуаля! А вот и продолжение, 13 лет спустя: http://www.developerdotstar.com/mag/articles/reeves_13yearslater.html

Вкратце, Джек Ривз только убедился в своей точке зрения. Однако, (да обратят внимания поклонники test-first programming concept, и слепо верящие в то, что итеративность и гибкость в agile решают все проблемы!) значимость архитектуры, или проекта верхнего уровня, серьезно возросла.

«Проектировать ПО 'в целом' трудно, и ни новые языки программирования типа Java или C#, ни графическая нотация типа UML не помогут человеку, который не знает, как за это взяться. … Отсюда следует, что важно делать правильно с первого раза, причем тем важнее, чем крупнее задача.»

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

---

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

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

Мы публикуем полный ответ Евгении.

Руководитель службы персонала Евгения Удалова рассказала порталу «Планета HR» об инструментах управления вовлеченностью сотрудников. С чего начать целенаправленную работу с вовлеченностью? Почему так важна информированность персонала и как ее повысить? Как привлечь сотрудников к процессу принятия решений различного уровня? Своим опытом поделились HR-директора различных компаний.

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

Мы публикуем полный текст комментария Евгении.

Руководитель службы персонала Евгения Удалова рассказала порталу E-xecutive.ru об особенностях работы с «корпоративными долгожителями». Ценят ли современные работодатели сотрудников-старожилов? Что дает работнику многолетняя преданность одной компании? Долгожители в отделе — надежная опора или головная боль для руководителя? На эти и другие непростые вопросы о сотрудниках-старожилах ответили HR-специалисты нескольких компаний.

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

Мы публикуем полный текст комментария Евгении.

Добро пожаловать на AgileDays’12!

Прогрессивный IT-мир согласен, что настало время отказаться от тяжелых и громоздких схем в пользу гибких методологий, качественного продукта и партнерских отношений. Конференция AgileDays’12, которая пройдет 23–24 марта в Москве, станет для вас глотком свежего воздуха, открыв новые возможности в IT-разработке.

Мы приглашаем как новичков, которые только слышали о гибких методологиях, так и тех, кто уже давно использует Agile. Талантливые и опытные коучи и докладчики поделятся результатами новейших разработок со всего мира. Неоценимой помощью для тех, кто внедряет Agile у себя в компании, станут примеры реальных историй от тех, кто уже сделал свой выбор в пользу Agile. AgileDays’12 — прекрасная возможность для новых бизнес-знакомств с самыми продвинутыми представителями IT из России, стран СНГ, Европы и США.

Будьте на острие событий с AgileDays’12!

Присоединившись к нашему Agile-фестивалю, вы услышите выступления передовых экспертов индустрии разработки ПО, таких как: David Hussman, Асхат Уразбаев, Никита Филиппов, Дмитрий Лобасев, Сергей Дмитриев, Максим Дорофеев, Борис Вольфсон, Андрей Бибичев и других.

Приглашенный гость конференции David Hussman — ключевой докладчик AgileDays’12 — истинный Agile-евангелист, продвигающий Agile как образ мышления (mindset), а не следование практикам конкретных методологий, в избытке представленных в современном Agile-сообществе.

Программа AgileDays’12 будет состоять из:

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

Уже сейчас вы можете ознакомиться с формирующейся программой конференции.

А если у вас есть интересный опыт в сфере Аgile, поделитесь им с нами, став докладчиком AgileDays’12. До 31 января мы ждем ваши заявки!

Действуют специальные предложения для партнеров мероприятия. Мы предлагаем целый ряд возможностей для активного участия вашей компании в конференции AgileDays’12, а это 500 участников из более чем 300 компаний.

Не откладывай регистрацию на потом, стань участником AgileDays’12 прямо сейчас!

Узнайте больше и поделитесь своим опытом внедрения Agile, общаясь в неформальной обстановке с докладчиками и участниками со всей России, стран СНГ, Европы и США.

Все самые передовые идеи, подходы и лучшие практики индустрии разработки ПО будут обсуждаться именно здесь, на AgileDays'12!

http://agiledays.ru/
https://twitter.com/#!/AgileDays
http://www.facebook.com/AgileDays

Дата и место проведения: 23-24 марта, Москва, ул. Шипиловская, д. 28, бизнес-отель «Милан»
Телефон: +7 (495) 991-69-20 (Ирина Цыбденова)
E-mail: irina@scrumtrek.ru

Руководитель направления «Финансовые институты» Сергей Тихомиров принял участие в обсуждении проблем делегирования, организованном на портале E-xecutive.ru. Умеют ли современные менеджеры среднего и высшего звена делегировать полномочия? Почему иногда руководителю «проще сделать самому»? Когда выполнение работы за подчиненного оправдано и даже необходимо? Об этих и других аспектах взаимоотношений руководителей и подчиненных журналисты E-xecutive.ru поговорили с топ-менеджерами нескольких компаний.

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

Мы публикуем полную версию интервью с Сергеем.

В 2011 году руководители различных компаний и организаций, в том числе и генеральный директор CUSTIS Владимир Рахтеенко, в интервью BFM.ru рассказывали о проблемах подготовки квалифицированных «айтишников» и путях их решения. Проанализировав ответы, Марина Эфендиева подготовила статью Российский кадровый рынок изголодался по «технарям».

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

Ответы Владимира Рахтеенко на вопросы BFM.ru мы приводим полностью: Российский кадровый рынок и IT.

Не успели мы до конца опубликовать записи с UXRussia-2011, как наступил непрерывный марафон конференций — WUD-2011, SPMConf-2011, SQADays-10, AgileKitchen — юзабилити, менеджмент, QA/тестирование, agile development. И снова нас позвали все это снимать.

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

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

• Категория:WUD-2011 (наша запись)
• Категория:SPMConf-2011 (наша запись)
• Категория:SQADays-2011 (наша запись)
• Категория:Собрания AgileRussia.ru

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

---

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

→ продолжить чтение…