Thursday, November 30, 2006

Хаос наступает

IT стремится к хаосу. SOA – хаос в архитектуре систем. Agile (XP и, особенно, Scrum) – хаос в производстве систем.

Причем хаос - это не мое видение. SOA и Agile позиционируются как методологии жизни в хаосе.

Новые методологии отрицают планирование, никаких планов развития. Они все сиюминутны.

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

Чем методология разработки более гибкая тем больше ее сейчас любят. Каждая следующая методология оставляет все меньше места планированию и контролю. Roy Osherove, agile консультант, пишет что Scrum продается лучше чем XP в основном потому, что Scrum более настраиваемый, требует меньше управления и не содержит страшного слова "Extreme". Т.е. разработчик наслушавшись как все может быть хорошо с agile, где ему не надо ни за что отвечать ведется и хочет применить это на себя. Причем выбирает методологию – чем проще звучит тем лучше.

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

Без отсутствия изначальных требований к разрабатываемой системе (а аgile отрицает любые планы далее чем на одну итерацию) нельзя оценить результат разработки. Никто не сможет сказать сделали ли то, что было нужно или не то. В любом случае разработчик не виноват – он только выполнял пожелания заказчика.

Disclamer: Не бейте меня сильно! Описание ситуации немного утрировано, но, иногда, карикатурная утрированность помогает взглянуть на ситуацию по новому.


technorati tags: , , ,

Wednesday, November 29, 2006

Microsoft тоже хочет мой номер телефона

Пару недель назад Google придумал как выманивать номера телефонов у пользователей.

Microsoft решил не отставать.

Кликните по картинке для увеличения

Но у Google была уловка, и для использования сервисов Google указание телефона не обязательно. Microsoft же теперь без указания номера телефона в Live ID не пускает к данным на их сервере. Хотела посмотреть презанташку на www.microsoft.com/rus, но с таким подходам мне эта презенташка не нужна.

Как то мне совсем не нравится такая тенденция.


technorati tags:

Sunday, November 26, 2006

Жизнеобеспечение проекта. Часть 3.

Про обещанного аналитика, и еще про технолога.

Предыдущие части: Часть 1 (введение), Часть 2 (про службу поддержки).

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

Кликните по картинке для увеличения

Аналитик анализирует новый требующийся функционал (check function overview) и возможные технические проблемы проекта (check possible bug), выявленные пользователями и службой поддержки. Т.е. неформализованную информацию из Help Desk. На основе этого он составляет технические задания (technical project) для разработчиков. ТЗ, как и вся информация по проекту, складывается в Wiki. Задания разработчикам записываются в Bug Tracking со ссылками на источник задания в Help Desk и на ТЗ в Wiki.

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

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

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

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

    Кликните по картинке для увеличения

    Технолог – главный специалист в своей предметной области (subject area). Он работает на неформализованном уровне проекта. Всю информацию, которая требуется для решения конкретной задачи технолог кладет в Wiki и ставит на нее ссылку из Ticket-а Help Desk.

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

    В следующей части - Project Manager.

    В начало


    technorati tags: ,

    Wednesday, November 22, 2006

    Крамольный прогноз развития корпоративных IT систем

    В связи с высказанной разнее крамольной мыслью у меня появился крамольный прогноз: через несколько лет опять начнут набирать популярность самописные корпоративные IT системы.

    Историческое обоснование:

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

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

    Теперь пришли SOA и SaaS. SaaS не рассматриваю т.к. он хотя и сервисный, но, скорее, метод распространения. А вот SOA является явной альтернативой крупным и дорогим ERP. Она выигрывает и по скорости и по стоимости внедрения. Но скоро всплывут все проблемы использования разномастных приложений. Плюс опять же начнет дорожать стоимость внедрения – модные специалисты всегда дорожают.

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


    technorati tags:

    Крамольная мысль

    У меня появилась крамольная мысль почему идея SOA так популярна в корпоративном сегменте и так активно пиарится.

    Исхожу из 2-х посылок:

    1. SOA (сервисно-ориентированная архитектура) - это набор небольших сервисов, которые, как предполагается, должны быть замечательно друг с другом интегрированы.
      Какие плюсы корпоративной SOA рекламируются:
      1. Сервисы небольшие они "лучше продуманы и реализованы оптимальнее чем соответствующие модули крупных ERP систем".
      2. Если нужен новый сервис его просто встроить в "конструктор" SOA, чем в крупную ERP.
      3. Если у вас уже есть много разных систем, то с помощью SOA они начнут работать слажено.
    2. Корпоративные информационные системы продаются вендорами, которым надо сначала убедить что их система самая-самая, потом внедрить систему (своими силами или с помощью сторонней компании) и потом бороться с просачиванием негативной информации о системе и результатах ее внедрения (а у любой крупной системы будут негативные отзывы какая бы она ни была реально).

    Итак крамольная мысль: Вся шумиха вокруг SOA в корпоративных системах очень выгодна вендорам.

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

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

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

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

    P.S.: К идее SOA я отношусь хорошо, но, imho, она, в основном, полезна не для корпоративных систем, а для конечнопользовательских наборов сервисов и продуктовых линеек.


    technorati tags: ,

    Стандарт по проектированию UI для Vista

    Стандарт здесь.

    Мне нравится подход Microsoft к проектированию приложений (правда далеко не все приложения MS соответствуют их же рекомендациям). Начинается все не с самого проектирования UI, а с моделирования поведения пользователя. Даны общие рекомендации, рекомендации как сделать UI более простым в использовании, описаны стандартные ошибки.

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

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

    Так же не забыты рекомендации по применению контролов. Например, советуют чтобы объектов в RadioGroup было от 2 до 7 (раньше, кажется, было до 5). И напоминают, что если в выпадающем списке есть пустое значение, то запись не надо оставлять пустой, а надо ее пометить специальным значением (например (none)).

    А еще (спасибо Алексею Копылову) рекомендации по тому как должна вести себя иконка в трее.

    И еще много всего разного.


    technorati tags: , , ,

    Tuesday, November 21, 2006

    Новые технологии и Модные термины

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

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

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

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

    Т.ч. идти надо не от технологии, а от нужд бизнеса.

    А вообще по поводу места IT технологий в бизнесе хорошо написано у Джима Коллинза в книге "От хорошего к великому" (глава 7 «Технологии как акселераторы»).


    technorati tags: ,

    Sunday, November 19, 2006

    Жизнеобеспечение проекта. Часть 2.

    Начало здесь.

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

    Кликните по картинке для увеличения

    Одна из основных функций Help Desk – поддержка пользователей (user support). Если у пользователя возникает проблема, он обращается в службу поддержки (request for support). Служба поддержки отвечает на запрос пользователя (reply for request). Довольно часто пользователи обращаются с однотипными проблемами. Для оптимизации ответов службы поддержки на однотипные проблемы удобно использовать шаблоны ответов (templates for support), хранящиеся в Wiki.

    Основное предназначение Wiki – база знаний (knowledge base) проекта. На данном этапе интересны 2 "части" базы знаний – Help и технические особенности реализации (technical specifications). Разделение на части условно т.к. все должно храниться вместе, но разграничиваться на уровне прав доступа к статьям и частям статей.

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

    Разумно организованный, постоянно обновляющийся и дополняющийся online help поможет снизить количество обращений пользователей в службу поддержки. Организация Wiki очень удобна для хэлпа т.к. перекрестные ссылки позволяют избежать дублирования информации в разных разделах. Однако классическую организацию wiki удобно дополнить иерархической структурой меток (tags), соответствующей разделам хэлпа, и каждую статью помечать соответствующими метками. Это поможет пользователю быстрее находить нужную информацию в хэлпе.

    Если пользователь хочет новый функционал, информацию об этом служба поддержки передает (inform about request for new function) управляющему проекта (его роль будет рассмотрена позднее).

    Если служба поддержки выявляет проблемы в функционировании проектом, то она информирует о ней (inform about bug) аналитика. При этом, если проблема была выявлена при разборе запроса пользователя, должна быть связь между ticket-ом запроса пользователя и ticket-ом бага. Почему служба поддержки для информирования о проблеме использует Help Desk, а не добавляет новую задачу сразу в Bug Tracking? Делается это для четкого разделения работы с неформализованной и формализованной частями проекта. Help Desk содержит неформализованные задачи по проекту, Bug Tracking – формализованные. Связью между ними является аналитик. О роли аналитика в следующей части.


    technorati tags: ,

    Thursday, November 16, 2006

    Это уже было в Симпсонах

    Офтоп.

    Жизнь:
    Недавно в Нью-Йорке у статуи Вашингтона украли голову.

    "The Simpsons":
    Барт украл голову у статуи основтеля города (The Telltale Head (1990) - Season 1, Episode 8)

    Ну что тут еще можно сказать? Это уже было в Симпсонах! ("South Park" The Simpsons Already Did It (2002) - Season 6, Episode 7)


    technorati tags: , ,

    Tuesday, November 14, 2006

    Жизнеобеспечение проекта. Часть 1.

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

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

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

    • Help Desk
    • Bug Traking
    • Source Repository
    • Wiki
    • CRM

    Реализаций этих приложений огромное множество. Но появляется сложная проблема выбора:

    • Каждое приложение должно быть наиболее удобно в своем классе.
    • Должна быть обеспечена интеграция приложений друг с другом.

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

    Без диаграмм вариантов использования тут не обойтись :-) (для проектирования использовался бесплатный oss продукт StarUML)

    Первое приближение. Определяем набор ролей в команде и взаимодействие между приложениями.

    Кликните по картинке для увеличения

    Итак.

    Интеграция приложений:

    Help Desk использует CRM для получения данных об обращающемся пользователе и продукте, который использует пользователь. (CRM ID - идентификатор записи в CRM)

    Так же Help Desk использует Bug Tracking для отслеживания реализаций задач. (BT ID - идентификатор задачи в Bug Tracking)

    Bug Tracking, в свою очередь, использует Help Desk для отслеживания источника задач. (HD ID - идентификатор Ticket-а в Help Desk. Извиняюсь, не могу подобрать хороший русский аналог к Ticket)

    Еще Bug Tracking использует Source Repository для определения, в какой версии файла исходника хранится изменение, внесенное для решения конкретной задачи. (SR ID - ссылка на версию файла исходника в Source Repository)

    Роли:

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


    technorati tags: ,

    Saturday, November 11, 2006

    SaaS великий и могучий

    Написала коммент к посту Даниила Фейгина "Модель продаж SaaS" и получился он таким большим и довольно развернутым, что я решила его здесь перепостить.

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

    Механизм "нравится -- берите, желательно у нас не спрашивая" это мечта любого разработчика!

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

    1. SaaS, в подавляющем большинстве, это тонкий клиент. А в браузере работать неудобно. Особенно с текстом. Это подтверждается большим количеством толстых приложений по управлению контентов блогов (как Windows Live Writer, BlogJet).
    2. Приложения, используемые для автоматизации предприятий, должны быть интегрированы друг с другом (частично в эту тему Intel выпускает SuiteTwo). При использовании различных сервисов интеграцию их обеспечить нельзя.
    3. Далеко не все фирмы готовы размещать свои приватные данные практически неизвестно где и у кого (ведь вначале постулировалось "желательно у нас не спрашивая"). Причем не только данные клиентов, но и всей внутренней кухни - базы знаний, управление проектами (как текущими так и будущими), логистика, финансы (какая фирма без финансов, а финансы еще хорошо бы подружить с CRM и управлением проектами) и т.д.
    4. Возвращаясь к данным клиентов... Мне тут видятся 2 основные проблемы:
      1. Возможная утечка грозит фирме не только, собственно, потерей данных, но и исками от своих клиентов, т.к. именно фирма, использующая сервис гарантирует клиентам приватность данных, а не IT компания этот сервис предоставляющая.
      2. С CRM должны дружить большинство остальных модулей, а CRM должна уметь делиться ID-ками, автоматически добавлять данные (парсить email-ы и xml).

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


    Tags:

    Wednesday, November 08, 2006

    Enterprise 2.0 Suite от Intel

    Intel выпускает новый продукт SuiteTwo, объединяющий wiki, блоги и rss агрегаторы и нацеленный на корпоративное использование.

    Явный плюс SuiteTwo в том, что будет единая точка управления всеми продуктам.

    Сайт продукта, к сожалению, очень аскетичный. Описание возможностей SuiteTwo очень скудное.

    Обещают возможность вести отдельные блоги по каждому продукту и интеграцию email, mobile и rss ленты в wiki.

    Нет никакой информации о разделении доступа к статьям и частям статей в wiki. Для корпоративного использования wiki это необходимо, т.к. основное предназначение wiki – это база знаний для обмена знаниями внутри команд, между отделами, а так же предоставление постоянно обновляемой информации пользователям. Т.е. требуется вести не только публичную информацию, и без разделения прав доступа информация «внутреннего использования» не будет попадать в wiki. Кроме того разделение прав должно быть многоуровневым, с возможностью раздела доступа по отделам и должностям. Без этого использование wiki становится однобоким (только публичным или только внутренним) и резко падает эффективность от использования.

    Более подробную информацию по продукту обещают прислать после регистрации на сайте. Как продукт выглядит не понятно вообще – нет ни демо, ни скриншотов.

    Цен на сайте так же нет, но на Terralab есть информация о 175-200 долларов в год или 15-17 долларов в месяц в расчёте на пользователя. С одной стороны 15-17 долларов в месяц не много, но, с другой стороны, доступ нужен большинству отделов (суппорт, разработчики, маркетинг и т.д.), соответственно большому количеству пользователей, а это уже может вылиться в довольно крупные суммы. При большом количестве бесплатных и недорогих платных движков wiki и блогов финансовая выгода SuiteTwo как единой точки доступа, на мой взгляд, не очевидна.

    Будем следить за развитием.


    Tags:

    Monday, November 06, 2006

    Google хочет мой номер телефона

    Google придумывает все новые способы, как выманить у нас наши private данные.

    При открытии нового акаунта в Gmail (по ссылке из Picasa) Google первым делом спрашивает... номер телефона. На который предлагает прислать invitation code.

    Хотела сделать screenshot со страной Russia, но оказалось, что Google знает всего 9 стран :-)

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

    Saturday, November 04, 2006

    SOA в Amazon.com

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

    Как сделать так, чтобы большая компания оставалась мобильной и быстро реагировала на изменения запросов клиентов знает Werner Vogels - CTO в Amazon.com.

    Успешный рост Amazon.com был обеспечен сервисно-ориентированной архитектурой (SOA). На текущий момент Amazon.com является набором разнообразных сервисов, разрабатываемых и поддерживаемых независимо друг от друга.

    Компания не является монолитной, а состоит из большого количества маленьких agile команд (2 pizza teams), раскиданных по всему миру. Каждая команда занимает свое место в сервисно-ориентированной структуре. Подобная организация дает Amazon.com быстроту реакции маленьких компаний.

    Процесс определения требований к продукту Werner Vogels описывает как работу "задом наперед" (working backwards). Для соответствования услуг нуждам пользователей, процесс определения требований к услугам ведется начиная с документации, которая потребуется при запуске (пресс-релизы и FAQ), затем переходя к документации, относящейся непосредственно к продукту (руководство пользователя и прототип поведения пользователей). В результате получается набор документация полностью описывающий продукт. Эти наборы документации позволяют легко передавать знания о продуктах между отдельными командами внутри Amazon.com.

    Здесь можно посмотреть интервью Werner Vogels, данное для ACM Queue magazine.


    Tags: , ,

    В чем искусство?

    Я очень люблю всяческие стандарты и шаблоны.

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

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

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

    Порядок ведения проекта и взаимодействия команды определяется выбранной методологией разработки ПО (Agile, Waterfall, RUP, BDUF).

    Тестирование, делающееся по стандартному плану, делается быстрее, чем без плана и с меньшей вероятностью что-либо забыть.

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

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

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

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

    Полезные ссылки:
    Martin Fowler - один из лучших авторов на тему методологий разработки ПО.
    maxkir.com – сайт Кирилла и Саши Максимовых с замечательной подборкой переводов книг и статей на темы процессов, методологий, анализа, проектирования и т.д. от таких авторов как Мартин Фаулер, Рон Джеффриз, Алистэр Коуберн.
    Стандарт кодирования на Delphi.
    Главы книги "Наука отладки".


    Tags: , ,

    Thursday, November 02, 2006

    Windows Mobile коммуникатор vs. ноутбук

    Михаил Козлов дал ссылочку на статью о преимуществах использования коммуникаторв с Windows Mobile платформой.
    Хорошо описаны возможности Windows Mobile. Но преимущества показаны так, как будто у компаний вообще еще нет информационных систем. "Устройства Windows Mobile позволяют повысить производительность персонала за счет автоматизации бумажного документооборота".
    Не хватает важного компонента - в чем преимущество использования коммуникатора с Windows Mobile по сравнению с ноутбуком. Ноутбуки становятся все меньше и легче. А использовать их для того, чтобы "получать доступ к нужным данным, даже находясь за пределами офиса" все-таки удобней.
    В предлагаемой связке пользователям придется именно работать на коммуникаторах. Но у коммуникаторов слишком маленький экран и клавиатура. Коммуникатор не эргономичен, значит будут потери по времени и, возможно, по качеству работы.
    Если в день сваливается несколько сотен писем их удобней разбирать на ноутбуке и пакетно, а не на телефоне по мере поступления. "Писать заказы" и т.д. тоже удобней на ноутбуке.
    Упоминание ноутбука встречается только в статье с мнением компании IDC и выглядит, скорее, как рекламный оборот: "Where laptops simply allowed workers to move the location from where they would do their work, handheld devices are changing how the work gets done".
    Есть какая либо статистика о замене компаниями у разъездных сотрудников ноутбуков на коммуникаторы?

    Tags: ,