Процесс разработки Visual Studio 2012. Agile. Часть 3.
- modified:
- reading: 5 minutes
Не знаю точно, но предполагаю, что большинство команд внутри Microsoft используют Agile, как процесс разработки их продуктов. Я не особый Agile проповедник, и не могу заострить внимания на всех тонкостях нашего процесса, поэтому расскажу кратко. Спринт у нас - это 2 или 3 недели, зависит от того, над чем работаем, и через сколько от нас народ будет ожидать хоть какие-нибудь версии или обновления, которые можно уже попробовать. В основном мы пытаемся синхронизироваться с командами-партнерами, с которыми работаем над каким-нибудь продуктом совместно. В начале спринта мы выносим задачи, которые хотели бы выполнить за этот спринт, оцениваем их, выбираем только те, которые считаем, что реально можем выполнить, и делаем некий приоритет задачам. Наши Проект Менеджеры (PM) обладают знаниями о том, что от нас ожидают команды-партнеры (которые зависят от нашего продукта или API), что от нас ожидают пользователи (на ранних версиях - это internal пользователи внутри Microsoft), поэтому мы можем четко определять, что действительно необходимо выполнить в ближайшем будущем. Так же разработчики (Devs) и тестировщики (QAs) пытаются продавить задачи по улучшению процесса тестирования, кодирования, да и, вообще, все, что связано с процессом разработки. Ну, и понятное дело, что в этот текущий спринт попадают еще задачи из предыдущего, которые не выполнены, и мы их переоцениваем заново.
В конце спринта, обычно, бывают демо-презентации того, что выполнили за спринт. Презентуем мы все нашему менеджменту, а так же командам внутри нашего подразделения. Подразделение наше раньше называлось Visual Studio Ultimate (часть Visual Studio). Не путать с версией Visual Studio Ultimate Edition, так как многие продукты нашего подразделения присутствуют, начиная с Express версии. Так, например, под Visual Studio Ultimate находилось: Profiler, Debugger, IntelliTrace, Unit Tests, My Work, Code Review и что-то еще, явно забыл. Команды Profiler, Debugger и IntelliTrace – это еще одно маленькое подразделение, называемое Diagnostics Tools. Сейчас у нас была небольшая реорганизация, и названия немного поменялись. Что хочу сказать – все команды, как видите, часто очень сильно не зависимы друг от друга, поэтому всегда интересно посмотреть, что сделали ребята из соседнего офиса.
Как вы знаете, до того, как мы выпустили Visual Studio 2012 RTM, мы еще выпускали Beta и RC версии. Но мало кто знает, что на самом деле версии выпускаются примерно раз в месяц и они имеют названия, вроде, CTP (Community Technology Preview) и даже LCTP (Limited Community Technology Preview). Какие версии кому попадают, я не знаю. Помню, что, когда был MVP, то часто получал доступ к CTP версиям SQL и VS. Идея в том, что раз в месяц мы всегда делали огромный упор на то, чтобы отшлифовать версию так, что ей точно можно было бы пользоваться. То есть команды, которые писали, например, Windows Live Essentials, могли использовать последнюю версию VS2012 для написания своих новых версий Windows Store Apps c обновленным Metro UI. Ну и конечно, нам это очень необходимо для получения информации о том, как удобно или неудобно пользоваться нашими новыми версиями, что нравится или не нравится, что работает или не работает. Чтобы выпустить такой отшлифованный продукт, команды переходят в режим только исправления багов, называется это "пытаемся достигнуть ZBB" (Zero Bug Bounce, на Wikipedia зачем-то удалили статью о ZBB), то есть отметки 0 в количестве известных багов.
Ежедневно мы проводим StandUp Meeting, наша команда выбрала 4-30 как оптимальное время для этого. Время выбрано ближе к вечернему, думаю, так как большинство остальных совещаний (это правильный перевод слова Meeting?) проходят до 4-5 часов. Есть такое внегласное правило, что не стоит устраивать совещания после 4-5 часов, так как кто-то может на работу приходить около 7-8 часов, а уходить уже около 4-5. Нужно уважать чужое время. В StandUp участвуют все, на данный момент это, например, у нас 1 PM, 5 разработчиков и наш лид, 3 тестировщика и их лид, когда у нас есть интерны, они тоже посещают StandUp совещания. Обычно StandUp проходит за 10-15 минут. Каждый очень быстро рассказывает, что сделал за последние 24 часа, что собирается делать в следующие 24 часа. Если человеку нужно уйти раньше этого совещания, или все же у него другое совещания на это время – он просто пишет письмо о том, что сделал, и что собирается сделать.
Внутри команды есть еще понятие Triage – это PM + Dev (разработчик) + QA (тестироващик), обычно Dev и QA в Triage – это лиды команд. Когда они в отпусках, их подменяют кто-то из разработчиков и тестировщиков. Ежедневно Triage оценивает баги, которые были открыты тестироващиками нашей команды, а так же баги, которые открыты пользователями. Они оценивают, что мы собираемся исправлять сейчас, а что уходит в список багов, которые будем исправлять в будущих спринтах или версиях. Часто бывает, что баги – это просто Suggestions (предложения), которые часто не имеет смысла исправлять, так как мы знаем, что через месяц мы все поменяем, и в финальной версии все будет по-другому. Некоторые баги могут быть незначительные на данный момент, так как его очень тяжело воспроизвести, или он не приносит большого вреда для пользователя, но исправление может стоить много времени или быть рискованным на данном этапе. Мы не делаем оценок, какие баги «простые», а какие «сложные» - все они проходят через один и тот же процесс: исправить, скомпилировать, проверить тесты, визуальное подтверждение того, что баг исправлен от QA. Чем ближе мы к выпуску продукта, тем жёстче Triage фильтрует баги, так как любой фикс любого бага может вызвать другой набор багов, которые могут иметь более значительный вред для пользователей, поэтому мы становимся аккуратнее.