Статьи

21 сентября, накануне PnP Summit Russia, я взяла интервью у трех представителей одной из самых интересных команд Microsoft – p&p team, Аджоя Кришнамурти, Дона Смита и Григория Мельника (На фото сверху вниз).

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

Дон, Аджой и Григорий - действительно блестящие профессионалы и, кроме того, очень веселые и дружелюбные люди. Они увлечены своим делом и всегда полны юмора и оптимизма. Они неустанно подкалывают друг друга. Дон Смит, похожий на веселого чертика своей прической и острыми клыками, для работы использует огромный Мас, а в качестве screen saver у него светящиеся грибы. « Дон, - спрашиваю я его, - а тебя наверно все время спрашивают, почему у тебя грибы на заставке?» «О, да», - радостно улыбается Дон. «И это главная причина, почему они у него на заставке», - язвительно комментируют другие.

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

Елена. Что для вас лично самое ценное в работе в команде p&p? Что для вас значит эта работа?

(хором) Это очень хороший вопрос. Очень хороший. Нам такого вопроса не задавали!

Дон. Для меня самое главное – дух нашей команды, дух того, что мы делаем. Наша главная цель, наша миссия – сделать разработчика счастливее. То, что мы делаем, бесплатно для разработчиков. У нашей команды нет целей по доходам. Мы просто решаем, что является наиболее важным для .Net разработчиков и как сделать их проекты более успешными. Мы предоставляем исходные коды бесплатно, очень быстро решаем проблемы. Как это может не нравиться? Это великолепная команда и то, что мы делаем, дает очень большое удовлетворение от работы.

Аджой. Я хочу разделить тут два уровня: Во-первых, индивидуальный. Нам приходится общаться с людьми по всему миру, как правило, это сильнейшие архитекторы и разработчики. И это очень здорово и интересно. На втором уровне в качестве человека, отвечающего за планирование работ (planner), мне приходится общаться с клиентами из различных компаний и разными командами внутри Майкрософт (командами, разрабатывающими продукты, а также консалтинговыми подразделениями), чтобы решить, что попадет в наш лист задач (backlog). Также важно понимать роль команды на рынке. Это очень интересный опыт для меня.

Григорий. Дух команды - это что-то очень особое, я такого не встречал нигде. Надо сказать, что я очень разборчив в своей карьере. Перед тем как начать работать с p&p team, я вел очень счастливую жизнь университетского профессора. У меня был отпуск 3 месяца во время каникул и также очень много вещей, которых я лишен в Майкрософт. Я пришел не просто на работу в Майкрософт. Именно работа в p&p team меня привлекла. Я по-прежнему провожу много исследований и провожу консалтинг, как и на моей прежней работе. То есть я сохранил многое из того, что мне нравится. Я общался со многими членами команды и, когда появилась возможность стать ее членом, я сказал – конечно, почему нет! И я скажу, я уверен, что я не ошибся. Начиная с того, как мы общаемся с разработчиками и клиентами, как мы выполняем задачи и разрабатываем код – мне все очень нравится. На личном уровне – это общение, связь, дружба с разработчиками по всему миру. Это напоминает семью, распределенную по всему миру.
В команде p&p мы очень уважаем каждого и доверяем друг другу. Я думаю, что это очень важно. Каждый сам вправе выбирать задачи, определять правильный процесс и детали, и даже определять рамки (scope) проекта.

Дон. Каждый в команде имеет право совершать ошибки и учиться на них. И мы поощряем это. Я имею ввиду, поощряется не совершение ошибок, а извлечение уроков их них. Каждый может эскалировать проблему на усмотрение руководства и при этом очень часто слышит: ты можешь сам с этим справиться. И это делает команду очень сильной.
Григорий. Я знаю многих людей, которые хотели бы стать членами нашей команды и совсем немного тех, кто хотел бы уйти. В Майкрософт поощряется то, что люди работают в разных командах и меняют их, и как правило, люди меняют подразделение время от времени. Здесь это правило не работает. Никто не хочет уходить из p&p team. Ну и для меня очень важно, что я по-прежнему занимаюсь исследованиями и работаю с сообществами, журналами и т.п., использую инновации и технологии, чтобы понять, стоит ли их включать в руководства или нет. То есть я не замкнут в коробке.

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

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

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

Дон. Вы, ребята, говорите о размерах и форме чего-то. На самом деле наиболее подходящая документация это то, что больше всего подходит всем участникам команды. У нас, например, в достаточно маленькой команде – это не только диаграммы и презентации, но также и просто вербальное общение. Люди сами должны выбрать наиболее подходящую форму для общения внутри команды. Так же при общении с заказчиками, например, - это может быть определенная спецификация. Я могу рассказать, как мы это делаем, но это очень специфично и подходит именно для нашей команды. Самое главное в документировании архитектуры, это быть уверенным, что она НЕ БОЛЬШЕ того, что необходимо. Не тратьте времени на это больше, чем нужно.

Григорий. Не просто потеря времени, но это еще и может ввести людей в заблуждение.

Аджой. С точки зрения общения и документации, в том числе и, например, документации для пользователей, будьте уверены, что ее ровно достаточно (just enough).

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

Eлена. А как поддерживать документацию в актуальном состоянии, когда проект развивается и изменяется?

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

Аджой. К тому же ряд диаграмм вы можете создать прямо из кода.

Eлена. А какие нотации вы используете? Вы работаете под Visual Studio, где поддержка UML появится только в версии 2010. Используете ли вы UML в вашей работе?

Дон. Мы используем нотацию, понятную каждому.

Eлена. И что это за нотация?

Дон. Часть работы мы делаем с помощью UML-образных вещей. Например, при мозговых штурмах в команде проекта мы используем Sequence и Activity диаграммы. Для общения с тестерами иногда используем Use Case диаграммы. Когда говорим о стратегии, используем deployment диаграммы. Мы почти не используем диаграммы классов. Для проектирования как такового эти диаграммы не очень полезны. Я не говорю, что они вообще не нужны, я говорю конкретно о том, что мы используем в своей работе. Нам при проектировании достаточно sequence, activity и use case диаграмм. При этом, по правде говоря, мы не слишком заботимся о точном следовании нотации. Признаться, я не потеряю сон, если буду использовать не тот шрифт (прямой вместо курсива) или забуду про подчеркивание где-то. (Остальные поддерживают одобрительными возгласами). Проводя мозговой штурм, не так важно быть совершенным в деталях. Если в дальнейшем нужно будет добавить эту диаграмму в документ, мы сделаем аккуратную и точную диаграмму.

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

Аджой. Но при этом многие наши клиенты делают это. Мы же стараемся делать минимум документации.

Григорий. Люди часто делают вещи, потому что кто-то когда-то решил делать именно так. Был приобретен инструмент в поддержку работы и был установлен процесс и doc flow. И люди рады продолжать это делать, и никто не задумывается о том, почему это было выбрано. И многие решения, которые принимаются, принимаются только потому, что так делали в прошлом. И многие вещи делают только потому, что «мы всегда делаем это». И никто не задумывается о том, что раньше мы делали критически важные системы (mission critical system), а теперь создаем сайт. И теперь нам совсем не нужен тот же уровень документирования и деталей. То же самое касается и архитектуры. Часто я спрашиваю – «Зачем вам этот модуль, почему это сделано именно так?» И ответ:–«О, это потому, что это позволяет нам коммуницировать с другим модулем.» И вопрос:–«А зачем вам коммуницировать с этим?» И люди не осознают, что мир изменился и причины, по которым они это делали раньше, больше не существуют. Делайте что-то лучше. И время от времени задавайте себе вопрос «зачем»?

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

Нет, нет – это не религия (Хором).

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

Григорий. Это определенное руководство, но это не религия и не методология.

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

Григорий. Например, если говорить о рефакторинге: вам нужно понимать, зачем вы его делаете, - – мне нужно поддерживать эту систему, я хочу сделать больше юнит-тестов, и т.д. Если вы делаете демо для выставки, то понятно, что рефакторинг вам не нужен, вы не собираетесь поддерживать эту систему. И для демо вам не нужны юнит тесты.
Итак, еще раз, Agile - это набор практик, которые помогают вам работать эффективнее. Но главный вопрос, который вы должны задавать себе, –зачем мне это нужно.

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

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

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

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

Дон. Я бы назвал это руководство картой для архитектора приложений. Но направление, куда двигаться, он выбирает сам. Я даю инструкции, как сделать то-то и то-то. То есть у архитектора есть карта, как именно он может попасть из одного пункта в другой, что ему для этого нужно. Если вы спрашиваете, достаточно ли этого для успеха, - я бы сказал, нет. Конечно, это зависит от вашего определения слова «успех». Мы даем понимание архитектурных ограничений и деталей. Архитектура – это всегда процесс принятия решений. Обычно это принятие решений о структуре решения. Что является наиболее критичным для принятия системы, будет ли это производительность, безопасность или это приложение должно прожить более 20 лет? Будет ли это приложение разработано с помощью новых подходов и технологий. Например, команда, которая разрабатывает приложение, – команда очень талантливых разработчиков, но поддержку системы будут осуществлять junior программисты. Также важно понимать затраты на разработку. Это наиболее важные вещи, которые влияют на принятие решений. Когда мы разрабатывает решение, мы должны принимать во внимание тысячи вещей. Здесь так много изменяющихся составных частей. Производительность, безопасность, юзабилити – нужно понять, что является наиболее важным, чтобы принять верное решение.
То, в чем помогает руководство – это не забыть чего-то важного. И это то, о чем я буду говорить завтра. Существует много вещей, которые надо держать в голове, руководство помогает не забыть что-то важное. Мы хотим добиться, чтобы создав решение, людям не пришлось делать обратной работы и переделывать несколько раз уже созданное. Обычно вам нужно перепроектировать систему, если вы забыли что-то. Иногда это происходит потому, что требования изменились.
Первая часть руководства посвящена очень общим вещам. Это то, что архитектор должен знать. Это часть помогает понять основные принципы, архитектуру в целом. Далее идут уже конкретные детали по архитектуре. Важно понимать особенности технологий при разработке архитектуры, будь то Java, .Net и т.д.

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

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

21 сентября 2009 года