Станислав Горнаков: Дмитрий здравствуйте! Спасибо что согласились дать интервью нашему журналу! Насколько я знаю, вы уже давно работаете в Microsoft. Расскажите, как вы получили возможность работать в этой компании?
Дмитрий Андреев: Признаться честно, работать в Microsoft я мечтал с тех самых пор как начал изучать технологии этой компании. Но одно дело мечтать, а другое дело каким-то образом двигаться к этой цели. С 2001 года я работал в крупном Российском интеграторе, руководителем группы прикладных решений на базе технологий Microsoft. Посещал семинары и конференции, проводимые Российским представительством, познакомился с массой замечательных людей. Появлялись совместные проекты. И в 2003 году мне позвонили из кадрового агентства, сказав по секрету что «вашей кандидатурой интересуется крупная западная компания». Само трудоустройство заняло очень долгое время, я прошел за полгода пять или даже шесть интервью. В один момент мне даже показалось что все, шанс упущен. Тогда в Российском представительстве работало очень небольшое количество людей, в основном в подразделениях связанных с продажами и маркетингом. И только с расширением консалтинговой группы, которая занимается техническими проектами, в 2004 году я получил заветный оффер на позицию технического консультанта по разработке прикладных решений.
Вопрос: Но сейчас вы работаете на другой позиции и в другом подразделении?
Ответ: Да, с 2004 по 2007 год я работал консультантом. За это время был реализован не один десяток проектов, в которых я участвовал. В том числе это были крупные внедрения SharePoint Server и Project Server. До сих пор знания и навыки, которые были приобретены, являются фундаментом для многих вещей, которыми приходится заниматься сейчас. В первую очередь это проектная и процессная организация, подходы по реализации программных проектов.
В 2005 году вышла в свет первая версия Team Foundation Server – инструмента организации командной работы. У меня был очень большой интерес к этому комплексу, я повышал свою экспертизу в области организации процессов разработки, проводил семинары по внедрению TFS. И в 2007 году перешел на позицию Эксперта по Архитектуре информационных систем в департамент стратегических технологий. На английском языке наше подразделение называется Developer and Platform Evangelism, и моя должность соответственно Evangelist.
Вопрос: Чем вам приходится заниматься сейчас? Каков технологический интерес?
Ответ: Чтобы ответить на этот вопрос следует разделить два важных момента, которые есть в нашей работе. В Microsoft принята культура четкого «целеполагания» которое можно выразить через метрики. Например – нам надо чтобы за год было проведено столько то мероприятий, было подготовлено столько то статей и вебкастов, их посмотрело столько то людей. Это напрямую влияет на другие наши цели, как к нам, как вендору, относятся программисты. Все это тоже измеримые показатели. Достижение этих целей, а точнее целевых значений – это проекты в которые вовлечены все сотрудники нашего подразделения, а часто и других отделов. Эти проекты уже детализованы до того уровня, который позволяет понять что надо делать чтобы добиться тех самых результатов. Очень часто бывает так, что сотрудник ведет один или несколько таких проектов, организует людей и в тоже время участвует в других проектах в силу своей экспертизы и навыков. Соответственно сейчас я занимаюсь активностями, связанными с подготовкой контента – технологических статей и вебкастов, работой над некоторыми разделами сайта MSDN, над направлением связанным с нашим клиентским стеком технологий, взаимодействую со студентами в рамках программы MSP и сообществом MVP, участвую в организации крупных мероприятий.
С другой стороны у всех наших евангелистов, в том числе и у меня, есть технологический фокус – несколько технологий и продуктов в которых мы отлично разбираемся. Таким основным продуктом для меня являются наши средства разработки – Microsoft Visual Studio и Team Foundation Server. Этим направлением я занимаюсь уже не один год, провожу тренинги по коллективной разработке, семинары, мероприятия, подготавливаю своими силами и с помощью сообщества статьи. В том числе я привлекаюсь к работе над внедрением этих продуктов у заказчиков. Это позволяет получать реальный опыт, подкрепляя теоретические знания.
Вопрос: Microsoft, как один из грандов индустрии, несомненно имеет колоссальный опыт коллективной разработки. Делитесь ли вы этим опытом или же это тщательно охраняемый секрет?
Ответ: Замечательный вопрос. Очень часто на семинарах и презентациях меня просят рассказать о том, как организованы процессы разработки в Microsoft, в надежде на то, что эти знания позволят сделать все пусть и не идеально, но с видимым результатом. В первых это никакой не секрет и в основном внутри Microsoft используется подход Microsoft Solutions Framework и Security Development Lifecycle. Но как обычно, «дьявол в деталях». Годами выстраиваемый процесс породил массу уникальных дополнений и решений, которые специфичны именно для нашей компании. Приведу пример – Team Foundation Server и Visual Studio создаются на базе их же самих. Шаблон процесса для TFS, который используется DevDiv (подразделение по созданию Visual Studio) модифицирован. В описании бага присутствует, по меньшей мере, на сорок полей больше по сравнению с тем, который входит в комплект поставки TFS «из коробки». Можно конечно попробовать заполнять все эти поля, например в стартапе из трех программистов, и у них все будет организовано как у Microsoft. Но скорее это внесет ненужную никому бюрократию. Это все равно, что какому-нибудь автомобильному тюнинговому ателье перенять практики у автомобильного концерна. Возможно, что для тюнинга у них останется процентов пять времени, все остальное будет занято соблюдением процессных формальностей.
Вопрос: Так как же быть? У кого перенимать опыт и делать процесс коллективной разработки правильным? Или может быть совсем отказаться от процессов, коль скоро они вносят столько бюрократии?
Ответ: Следует четко разделять процессы от целей, которые перед нами стоят. Процесс ради процесса это, вообще, ужасная вещь. Но нам-то с вами надо создать программный продукт, выпустить его в свет и наладить сопровождение. Другими словами наладить жизненный цикл, и управлять им. Здесь мы плавно переходим к такому понятию как управление жизненным циклом программного продукта – Application Lifecycle Management. В рамках ALM одним из важных моментов является механизм прозрачности и понимания того что происходит на проекте в любой момент. Сколько багов сейчас у вас на проекте? В каком модуле их больше всего? Каков процент покрытия кода тестами? Сколько требований осталось реализовать? Сколько строчек кода добавлено в модуль? Сколько времени потребует выполнение задач на текущей итерации? Перечень таких вопросов на реальном проекте значительно больше. Но зная эту информацию, вы можете в любой момент ответить на очень важный вопрос. Как у нас идут дела? Может быть, мы отстаем от графика, и надо привлекать дополнительные ресурсы? Другими словами вы постоянно осведомлены и готовы бороться за успех проекта с помощью реальных действий. Очень важным моментом при этом является снижение объема субъективных показателей в этой информации. Люди часто переоценивают свои возможности и оптимистичны в оценках. Если вы будете их просто опрашивать о том, как идут дела на проекте и доверять их мнению, то может оказаться что у вас на проекте все до последнего было просто идеально, но в день презентации продукта окажется что половина функций не работает, а половина содержит ошибки.
Возвращаясь к заданному вопросу становится понятно, что процессы коллективной разработки – это набор предсказуемых действий и некоторых правил которые позволяют вам в последствии иметь ценную информацию. Рассматривайте процессы разработки как документооборот. Вам остается только найти баланс между предсказуемостью (обеспечивается процессом и бюрократией) и прозрачностью (обеспечивается метриками).
Вопрос: У меня сразу же возник вопрос. Как же найти баланс между предсказуемостью и прозрачностью в процессе коллективной разработки, который подходит для конкретной команды? Звучит это конечно просто, но не совсем понятно с чего начать.
Ответ: Тут-то нам на выручку и приходит опыт индустрии в целом. Основные шаги, итерации, действия, которые возникают на любом проекте, уже давно известны. Разработаны десятки методологий, начиная с Waterfall и заканчивая экзотикой вроде You Ain’t Gonna Need It (YAGNI). Я, конечно, не призываю изучать их все, среди этих методологий явно есть фавориты, такие как подход Agile, рекомендации Scrum и CMMI. Конечно, в случае CMMI объем документации, которую придется изучить, может быть неожиданно большим. С другой стороны Scrum Guide это документ в 17 страниц. Начните применять эти методологии и процесс как есть, без особой оглядки на ваше возможное непонимание каких то моментов. Обратите внимание на то, какие потенциальные метрики в последствии вы получите. Если вам кажется что прозрачности и понимания текущего состояния недостаточно, вносите изменения в процесс, делайте шаги, которые дают вам эту информацию. Этот подход может быть итеративным и постепенно нужный баланс будет достигнут.
Вопрос: Но не приведет ли такой подход к тому, что команда хотела использовать подход Agile, а получилось у них совсем не то, не так и совсем не по канонам Agile?
Ответ: Еще один замечательный вопрос, который мне самому нравится задавать на конференциях и семинарах. Звучит он примерно так – «Кто из вас в зале считает, что применяет для разработки подход Agile, хотя бы частично?» После того как часть людей поднимает руку, я задаю следующий вопрос – «Кто из вас считает что вам удается применять Agile максимально полностью?». В этом случае количество поднятых рук значительно меньше. Подвох заключается в том, что нет никакого «истинно верного Agile». Суть самого слова Agile – «гибкий», подразумевает, что вы можете в своих процессных подходах вносить (или не вносить, или вообще что-то не делать) необходимые изменения. Agile всего лишь декларирует ваши цели – создать нужный программный продукт. Не документ с требованиями. Не базу данных с багами. Не веб-сайт с отчетами о времени выполнения задач. Agile – это манифест с тремя абзацами текста. Это не процесс, не методология, не рекомендация. Но при этом существуют реализации процессов опирающихся на принципы Agile, например это шаблоны процессов MSF/Agile и Scrum/Agile которые поддерживаются Team Foundation Server. Если вы используете этот шаблон процесса на проекте, но при этом не следуете всем шагам, которые в них рекомендованы, это совсем не значит что вы делаете что-то не так. Как однажды сказал Брайан Харри в своем блоге – «наш процесс, ваш процесс, или никакого процесса». Рассматривайте этот вопрос через тот самый баланс между предсказуемостью и прозрачностью. Если вы получаете нужные метрики, которые позволяют вам отвечать на вопрос «как идут дела» значит вы на верном пути.
Вопрос: Каким образом формируются метрики? Откуда их брать и как обрабатывать?
Ответ: Сбор и анализ метрик это задача инструментария, который вы используете. Извлечь информацию о количестве багов вы можете из багтрекера, количество добавленных строк кода – из системы контроля версий. Возможны, какие то дополнительные источники информации, связанные с требованиями, тестами и так далее. Важно понимать, что если у вас есть взаимная увязка этих показателей между собой, отслеживаемость данных (traceability), то вы обладаете более точными сведениями. Чем более интегрированы ваши подсистемы контроля версий, списка требований, багов и другие компоненты – тем больше синергии в этих данных. Но интеграция этих компонент может требовать времени и дополнительных усилий, возможно проще использовать готовые решения, такие как Team Foundation Server. В документации к TFS подробно описан перечень метрик, которые формируются на основании сбора данных из всех подсистем и вносимых туда изменений на основе процессов. Какая-то часть из них вообще не требует усилий по сбору, вы просто работаете с системой, а «первичная бухгалтерия» заполняется за вас. И вам остается только открыть отчет, чтобы посмотреть текущее состояние дел. Собственно в этом вся суть TFS. Это инструмент, который позволяет вам узнавать, как идут дела и принимать решения. А уж попутно он содержит интегрированные компоненты по багтрекингу, контролю версий, управлению задачами, требованиями, процессом и так далее.
Вопрос: И еще один вопрос, чего ожидать в будущем в контексте организации командной разработки? Что нам ждать в будущем от Microsoft в этом контексте?
Ответ: На мой взгляд, ожидать каких-то методологических прорывов в области процессов командной разработки в ближайшем будущем не приходится. Если начать изучать эти вопросы более подробно, то мы неизбежно наткнемся на области не связанные с IT. Это изучение работы социальных групп, психология, вопросы мотивации. Скорее надо ожидать улучшений в инструментах. В первую очередь повышение уровня автоматизации процессов, боле тесная интеграция, уменьшение количества рутины. Что же касается наших продуктов, то мы готовим некоторое количество нововведений как в среду Visual Studio, так и в TFS и средства тестирования. Уже несколько месяцев функционирует тестовая версия «Облачного» TFS и возможно кто-то из читателей получил промокод и может попробовать его возможности. Но боюсь, что рамки интервью не дадут мне возможности ответить на этот вопрос более подробно.
Дмитрий, спасибо за интересное интервью, было очень интересно пообщаться!
И вам спасибо за отличный и интересный журнал и возможность высказать свои мысли на его страницах!
На заметку
Уют в интерьере вашего дома или квартиры добавит камин лидера российского рынка каминов Компании САГА. Компания предлагает большой выбор современных моделей каминов различных мировых брендов.