Logo    
Деловая газета CitCity.ru CITKIT.ru - все об Open Source Форумы Все публикации Учебный центр Курилка
CitForum    CITForum на CD    Подписка на новости портала Море(!) аналитической информации! :: CITFORUM.RU
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

26.01.2017

Google
WWW CITForum.ru
С Новым годом!
2005 г

Четвертое измерение или Как обмануть Железный Треугольник

Алистэр Коуберн
Humans and Technology, 4-ое октября 2003

Перевод: К.Максимов, А.Максимова, сайт maxkir.com

Несмотря на то, что первым в Манифесте Гибких Методологий (Agile Manifesto) стоит правило "Люди и их взаимодействие гораздо важнее процесса и средств разработки", сами приверженцы таких методологий тратят на разговоры о процессе довольно много времени. К примеру, Экстремальное программирование (XP) описывает почти что исключительно процесс разработки: "Вы следуете процессу? Сначала тестируете, потом пишете код? Играете в планирование? Парами программируете?" и т.д.

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

Как обмануть Железный Треугольник

Когда речь заходит о руководстве проектами, мы постоянно сталкиваемся с пресловутым Железным Треугольником

iron triangle

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

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

И, несмотря на это некоторые из нас все же обнаруживают, что участвуют в проектах, где все три вершины "железного треугольника" уже заданы. Например, нам говорят, что мы должны разработать определенную функциональность за 18 месяцев с бюджетом 15 миллионов. Один из моих друзей постоянно получает задания, типа "у тебя есть четыре человека и три месяца, чтобы разработать вот такую функциональность". И, пусть с небольшими поправками, мы это делаем!

process - the forth dimension

Секрет в том, что существует еще одна вершина, которую пока еще не оценили по достоинству: процесс разработки.

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

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

Как же обмануть Железный Треугольник?

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

Вот три устоявшихся стереотипа, которые я стараюсь изменить:

  • Cначала нужно получить требования, а потом уже проектировать; сначала проектировать, а уже потом писать код.
  • Лучше описывать все подробно, чем делать приблизительные наброски и обсуждать их.
  • Людям лучше работается в изолированных рабочих помещениях.

Давайте заменим эти правила на другие:

  1. Сочетать различные виды деятельности и одновременно разрабатывать систему. Получить вначале ровно столько требований, сколько нужно, чтобы начать работу над архитектурой продукта (точное количество требований будет варьироваться в зависимости от конкретного проекта). Писать код на самых ранних стадиях проекта, чтобы быстрее получить отзывы о разрабатываемом варианте архитектуры.
  2. Кратко и быстро отражать основные моменты разработки в документации и не забывать сопровождать документацию живым общением.
  3. Дать всем возможность работать в одном помещении.

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

Моя статья слишком мала, чтобы описать все стратегические и тактические приемы, которые они используют. К тому же, об этом можно прочесть в нескольких книгах: "Managing the Design Factory", "Skunk Works", "Theory of Constraints", "Lean Software Development", "Agile Software Development", и "Agile Management for Software Engineering.

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

Пусть все люди работают в одном помещении

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

Некоторые из тех, кого перевели на работу в общее помещение, грустят о мирной и тихой обстановке личного офиса. Однако, как заметил один из таких людей в личной беседе: "Мне очень нравился мой личный кабинет, но если честно, еще никогда в жизни я не работал так продуктивно, как в одной комнате со своими коллегами".

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

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

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

"Тихая гавань и сходные стратегии управления проектами"

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

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

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

Тогда, в качестве последнего средства (сроки поджимают), лидера проекта решают на время перевести в комнату в том же здании, но тремя этажами выше. И - о чудо - за оставшиеся дни он успевает доделать все возложенные на него задачи (потому что ему никто не мешает сконцентрироваться на работе). Оставшаяся без "мозгового центра" команда справляется сама, медленнее, но все-таки справляется.

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

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

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

Здесь мы приводим лишь краткий пересказ статьи. Полностью ее можно прочитать на сайте Алистэра Коуберна: ("Cone of Silence and Related Project Management Strategies").

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

Быстрое документирование плюс обсуждение

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

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

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

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

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

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

Одновременная разработка

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

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

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

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

Временные рамки

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

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

Однако есть и разница: в первом случае, требования "замораживаются" до истечения временного промежутка. Соответственно, в этих условиях команда может спокойно заниматься разработкой функциональности. Такой смысл термину "временные рамки" принято придавать в методологии Scrum (Schwaber, 2001). В другом случае, требования могут свободно меняться когда угодно, подразумевая, разумеется, что те, кто вносят изменения, имеют на это весьма веские причины. Именно так понимают этот термин приверженцы "экстремального программирования".

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

Одно из важнейших правил увеличения эффективности проекта, которое касается механизма "временных рамок", гласит:

Лучше урезать запланированную функциональность системы, но уложиться в сроки, чем тянуть (и тянуть, и тянуть) сроки, чтобы успеть завершить разработку функциональности.

На это существует ровно три причины:

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

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

Сколько это может продолжаться?

Мой коллега Джефф Пэттон (Jeff Patton), который сам использует все вышеизложенные правила, согласен с моими гипотетическими вычислениями: благодаря этим стратегическим уловкам можно сразу же сделать работу на 30% эффективнее. И тут же задал вопрос - можно ли повышать эффективность процесса разработок бесконечно, или же это единоразовая отдача?

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

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

Библиография

(Anderson 2003) Anderson, D.J., Agile Management for Software Engineering, Prentice-Hall PTR 2003.

(Cockburn 2002) Cockburn, Agile Software Development, Addison-Wesley, 2002.

(CoS URL) http://alistair.cockburn.us/crystal/articles/cos/coneofsilence.htm

(Ohno 1988) Ohno, T., Toyota Production System: Beyond Large-Scale Production, Productivity Press, 1988.

(Goldratt 1990) Goldratt, E., Theory of Constraints, North River Press, 1990.

(Poppendieck 2003) Poppendieck, M., Poppendieck, T., Lean Software Development:An Agile Toolkit, Addison-Wesley, 2003.

(Reinertsen 1996) Reinertsen, D., Managing the Design Factory, Free Press, 1997.

(Rich 1994) Rich, B., Janos, L., Skunk Works: A Personal Memoir of My Years at Lockheed, Little, Brown and Company, Boston, MA, 1994.Skunk Works

(Schwaber, 2001) Schwaber, K., Beedle, M., Scrum: Agile Software Development, Prentice-Hall, Upper Saddle River, NJ, 2001 (see also www.controlchaos.com).

© Copyright 2000-2003, Alistair Cockburn
© Copyright maxkir.com, перевод, 2004

Подписка на новости IT-портала CITForum.ru
(библиотека, CITKIT.ru, CitCity)

Новые публикации:

24 декабря

CITKIT.ru:

  • Новогодние поздравления
  • Сергей Кузнецов. Цикл Операционные системы: Ностальгия по будущему:

  • Алексей Федорчук. OpenSolaris 2008.11 Release

  • Сергей Голубев:

  • Евгений Чайкин aka StraNNik (Блогометки):

    17 декабря

  • С.Д.Кузнецов. Базы данных. Вводный курс

    10 декабря

    CITKIT.ru:

  • OpenSolaris 2008.11 Release

  • Альтернативные ОС: две грустные истории (С.Кузнецов)
  • Nokia N810 — доведение до ума
  • CitCity:

  • Платформа 2009: заоблачные перспективы Microsoft

    4 декабря

  • Лекция С.Д.Кузнецова Понятие модели данных. Обзор разновидностей моделей данных

    CITKIT.ru:

  • OpenSolaris 2008.11 Release. Первые впечатления

  • Linux vs FreeBSD: продолжим "Священные войны"?

  • Nokia N810 as is

  • Индульгенция для FOSS

  • Друзья СПО'2008

    26 ноября

  • Нечеткое сравнение коллекций: семантический и алгоритмический аспекты

    CitCity:

    CITKIT.ru:

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • 19 ноября

  • Проблемы экономики производства крупных программных продуктов

  • Язык модификации данных формата XML функциональными методами

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Заметки к книге:

  • FreeBSD: монтирование сменных устройств и механизм HAL
  • Текстовый редактор ee

    12 ноября

  • Правило пяти минут двадцать лет спустя, и как флэш-память изменяет правила (Гоц Грейф, перевод: Сергей Кузнецов)

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:
  • OSS в России: взгляд правоведа (В.Житомирский)

  • Новая статья из цикла С.Голубева "Железный марш":

    29 октября

  • О некоторых задачах обратной инженерии

  • Веб-сервисы и Ruby

  • Тестирование web-приложений с помощью Ruby

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

  • PuppyRus Linux - беседа с разработчиком (С.Голубев)

  • Сергей Кузнецов. Заметка не про Linux

    22 октября

  • Обзор методов описания встраиваемой аппаратуры и построения инструментария кросс-разработки

    CITKIT.ru:

  • Сергей Кузнецов. Почему я равнодушен к Linux

  • Глава из книги А.Федорчука
    Сага о FreeBSD:
  • Что надо иметь
    3. Базовые познания

    CitCity:

  • Управление IT-инфраструктурой на основе продуктов Microsoft

    15 октября

  • Методы бикластеризации для анализа интернет-данных

    CitCity:

  • Разъемы на ноутбуках: что они дают и зачем их так много?
  • AMD Puma и Intel Centrino 2: кто лучше?

    CITKIT.ru:

  • Новый цикл статей С.Голубева
    Железный марш:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    8 октября

  • Автоматизация тестирования web-приложений, основанных на скриптовых языках
  • Опыт применения технологии Azov для тестирования библиотеки Qt3

    Обзоры журнала Computer:

  • SOA с гарантией качества
  • Пикоджоуль ватт бережет
  • ICT и всемирное развитие

    CitCity:

  • Пиррова победа корпорации Microsoft

    CITKIT.ru:

  • Главы из книги А.Федорчука
    Сага о FreeBSD:

    Статья из архива:

  • Я живу в FreeBSD (Вадим Колонцов)

    Новые Блогометки:

  • Перекройка шаблона Blogger или N шагов к настоящему
  • Blogger. Comment style
  • Screenie или глянцевый снимок экрана

    2 октября

    CITKIT.ru:

  • Сага о FreeBSD (А. Федорчук)

    Zenwalk: пакет недели

  • Банинг — интеллектуальное развлечение (С.Голубев)

    CitCity:

    25 сентября

  • Клермонтский отчет об исследованиях в области баз данных

    CITKIT.ru:

  • Пользователям просьба не беспокоиться... (В.Попов)

  • Снова про ZFS: диск хорошо, а два лучше
  • Командная оболочка tcsh (А.Федорчук)

    Zenwalk: пакет недели

    17 сентября

  • T2C: технология автоматизированной разработки тестов базовой функциональности программных интерфейсов
  • Технология Azov автоматизации массового создания тестов работоспособности

    CITKIT.ru:

  • FreeBSD: ZFS vs UFS, и обе-две — против всех (А.Федорчук)

    Zenwalk: пакет недели

  • Дачнет — практика без теории (С.Голубев)

    10 сентября

  • За чем следить и чем управлять при работе приложений с Oracle
  • Планировщик заданий в Oracle
    (В.Пржиялковский)

    CITKIT.ru:

  • Microsoft: ответный "боян" (С.Голубев)

  • Причуды симбиоза, или снова "сделай сам" (В.Попов)

  • Файловые системы современного Linux'а: последнее тестирование
  • Zsh. Введение и обзор возможностей
    (А.Федорчук)

    Описания пакетов Zenwalk: Zsh, Thunar, Thunar-bulk-rename, Xfce4-places-plugin, Xfce4-fsguard-plugin

    Блогометки:

  • Google Chrome
  • Лончер для ASUS Eee PC 701

    3 сентября

    CITKIT.ru:

  • Заметки о ядре (А.Федорчук):

    Добавлены описания пакетов Zenwalk: Galculator, Screenshot, Gnumeric, Pidgin

    В дискуссинном клубе:

  • И еще о Википедии и Google Knol

  • Лекция для начинающего линуксоида (С.Голубев)

    26 августа

  • Транзакционная память (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Открыт новый проект Zenwalk: пакет недели

  • Статья Текстовые процессоры и их быстродействие: конец еще одной легенды?

    21 августа

    CITKIT.ru:

  • Почему школам следует использовать только свободные программы (Ричард Столлман)
  • Беседа Сергея Голубева с учителем В.В.Михайловым

  • Википедия или Гуглезнание? Приглашение к обсуждению (Алексей Федорчук)
  • Народная энциклопедия от Google (StraNNik)

  • Обзор Mandriva 2009.0 Beta 1 Thornicrofti
  • Новичок в Линукс: Оптимизируем Mandriva 2008.1

  • Книга Zenwalk. Приобщение к Linux:

    13 августа

    CitCity:

  • Мирный Atom на службе человеку. Обзор платы Intel D945GCLF с интегрированным процессором
  • Обзор процессоров Intel Atom 230 на ядре Diamondville

  • iPhone - год спустя. Скоро и в России?

    CITKIT.ru:

  • Интермедия 3.4. GRUB: установка и настройка (из книги Zenwalk. Приобщение к Linux)

    6 августа

  • СУБД с хранением данных по столбцами и по строкам: насколько они отличаются в действительности? (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • Интермедия 2.2. Что неплохо знать для начала (из книги Zenwalk. Приобщение к Linux)

  • И снова про шрифты в Иксах (А.Федорчук)

  • 20 самых быстрых и простых оконных менеджеров для Linux

  • Дело о трех миллиардах (С.Голубев)

    30 июля

  • OLTP в Зазеркалье (Пересказ: С. Кузнецов)

    CitCity:

  • Будущее BI в облаках?
  • Тиражные приложения и заказная разработка. Преимущества для заказчика
  • Дискуссия со сторонниками заказной разработки

    CITKIT.ru:

  • Новые главы книги Zenwalk. Приобщение к Linux:
  • Глава 8. Пакеты: средства установки, системы управления, системы построения
  • Глава 9. Zenwalk: репозитории, пакеты, методы установки

    23 июля

    CITKIT.ru:

  • Все против всех. 64 vs 32, Intel vs AMD, tmpfs vs ext3
  • Две головы от Intel

  • Zenwalk: обзор штатных приложений (глава из книги "Zenwalk. Приобщение к Linux")

  • Нормально, Григорий...

    16 июля

    Обзоры журнала Computer:

  • Перспективы и проблемы программной инженерии в XXI веке
  • Большие хлопоты с большими объемами данных
  • Перспективы наноэлектроники

    CITKIT.ru:

  • Интермедия о лицензиях (А.Федорчук. "Zenwalk. Приобщение к Linux")

  • Есть ли будущее у KDE?

  • Linux в школе: альтернативный вариант в задачах

  • Шифр (приключения агента Никодима)

    10 июля

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия вступительная. Linux или GNU/Linux? Как вас теперь называть?
  • Глава 5. Среда Xfce
  • Глава 6. Xfce: приложения и плагины

  • ZUR (Zenwalk User Repository) FAQ

    2 июля

  • Персистентность данных в объектно-ориентированных приложениях (С. Кузнецов)

    CITKIT.ru:

  • Новые разделы книги А. Федорчука Zenwalk. Приобщение к Linux:
  • Интермедия 1.2. Дорога к Zenwalk'у. Период бури и натиска
  • Интермедия 3.3. Немного о Linux'е и "железе"
  • Глава 4. Настройка: инструментами и руками
  • Интермедия 4.1. Zenpanel и конфиги: поиски корреляции

  • Интервью с Жан-Филиппом Гийоменом, создателем дистрибутива Zenwalk

  • Linux в школе: первые итоги (С. Голубев)

    25 июня

    CITKIT.ru:

  • Zenwalk. Приобщение к Linux (А. Федорчук)

  • Логика и риторика (С.Голубев)

  • Технология Tru64 AdvFS

  • Ханс Райзер предлагает отвести полицейских к телу Нины

    18 июня

  • Проекты по управлению данными в Google (Пересказ: С. Кузнецов)

    CITKIT.ru:

  • ОС и поддержка "железа": мифы и реальность (А. Федорчук)

  • Linux в школе: другие дистрибутивы

  • Пинок (С. Голубев)

    4 июня

  • Ландшафт области управления данными: аналитический обзор (С. Кузнецов)

    CITKIT.ru:

  • Linux в школе: слово заинтересованным лицам

  • SlackBuild: пакеты своими руками

  • Linux от компании Novell. Установка и обзор openSUSE Linux

    Все публикации >>>




  • IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

    Информация для рекламодателей Пресс-релизы — pr@citcity.ru
    Послать комментарий
    Информация для авторов
    Rambler's Top100 This Web server launched on February 24, 1997
    Copyright © 1997-2017 CIT, © 2001-2017 CIT Forum
    Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...