Showing posts with label Development Team. Show all posts
Showing posts with label Development Team. Show all posts

Tuesday, May 29, 2007

SVN for Distributed Development Teams

Сегодня-завтра на CMcrossroads намечается пара интересных вебинаров, посвященных использованию Subversion для работы распределенных команд разработчиков:

  • Globally Distributed Development Using Subversion
    Сегодня, 29 мая в 22:00 по Москве (поздновато).
    Докладчики:
    Blair Zajac, Principle, OrcaWare Technologies
    Jim Campigli, Executive VP, Product Management & CTO, WANdisco
    Patrick Egan, Editor-in-Chief, CM Journal
  • Subversion for Enterprise Distributed Teams: Why, When and How?
    Завтра, 30 мая в 18:00 по Москве.
    Докладчики:
    Carey Schwaber, Senior Analyst, Forrester Research, Inc.
    Auke Jilderda, Senior Collaboration Consultant, CollabNet, Inc.
    Mark Phippard, Director, Subversion Engineering, CollabNet, Inc.

Вопрос Source Control Management для распределенных команд один из наиболее проблемных. Надеюсь будут интересные идеи не только по SVN, но и по SCM в целом.

И вообще, здесь довольно много интересных вебинаров. В частности еще ожидаемые по Distributed Development:

Прошедшие вебинары доступны в течении 6 месяцев on-demand.

Friday, December 22, 2006

Автоматизатор, автоматизируй себя сам

Среди более чем 400 примеров внедрения продуктов Microsoft исчезающе мало внедрений в сфере IT и среди них, в основном, телекоммуникационные компании.

Konstantin Starovoytov дал ссылку на Конкурс внедренческих проектов на iOne.ru. 39 компаний, в основном производственные, но нет ни одной IT компании-разработчика.

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

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

Мне очень нравится проект виртуального офиса компании СладКо (описание на microsoft.com, описание на iOne). Первый раз я о нем прочитала примерно года 2 назад. Первой мыслью было – звучит очень заманчиво и слишком красиво чтобы быть правдой. А второй мыслью было – почему это сделала кондитерская компания, а не IT? Т.е. возможно есть крупные IT компании, существующие без офиса, но я о них, к сожалению, не слышала.

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

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

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

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

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: ,

    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: ,

    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: ,

    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:

    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: , ,