Планирование релиза

В предыдущих постах я рассказывал о том, как мы используем TFS для реализации процессов.
В этом, мы поговорим о том, как мы планировали релиз.
В записи рабочего элемента Feature (Функционал) мы добавили закладку «Planning» (Планирование):

Данный и последующие топики с таким названием являются переводом блога Грегга Боера (Gregg Boer) из Microsoft Development Division, в котором Грегг рассказывает об использовании Team Foundation Server в процессе работы над проектом «Orcas».

Часть 8 (Работа с Quality Gates)

В предыдущей публикации мы говорили о контроле рисков в нескольких проектах одновременно. Сегодня мы поговорим об отслеживании качественных характеристик (Quality Gates).
Давайте задумаемся об этом на мгновение. Скажем, когда мы приступали к разработке Orcas (Visual Studio 2008), кто-то на самом верху давал указания:

1. VS2008 не будет иметь производительность хуже, чем VS2005.
2. Мы покроем 70% кода автоматическим тестированием.

Это всего лишь два требования, но зато самые большие. Как можно быть уверенным в том, что 3,000 человек добавит сотни новых функций в следующие 2-3 года, и эти указания будут выполнены?
Нашим ответом были Quality Gates. При работе над Orcas мы установили 16 таких ворот, от простых, как «Вы должны иметь письменные спецификации», до численных, например: «70% кода должно покрываться автоматическим тестированием».
В рабочем элементе типа Feature мы посвятили Quality Gates целую форму.

Отслеживание множества проектов.

Сегодня я собираюсь показать вам, как наш программ-менеджер отвечает за управление всеми проектами при помощи TFS, используя отчеты для отслеживания изменений в нескольких проектах сразу.
Для начала, позвольте мне рассказать вам немного о самом процессе.
Каждую неделю мы проводили встречи менеджеров, целью которых была проверка здоровья проектов, над которыми мы работали.
Проводил эти митинги Джим Бойл (Jim Boyle), который являлся программным менеджером нашей группы. Он – великолепный программ-менеджер с огромным опытом контроля за выполнением работы.
Каждую неделю Джим показывал нам отчет, который выглядел как этот. Он отображал все проекты, над которыми мы работали.

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

Мы используем рабочие элементы (work items) для отслеживания информации, представленной ниже.

Одной из проблем, с которой Майкрософт столкнулся при работе с большими объемами данных, была такой: когда мы управляли 1200 различными тех. заданиями, все они работали на основе единого базового кода. При таких объемах невероятно трудно управлять качеством базового кода, пока отдельные команды сосредоточены на выполнении собственных задач в то же самое время. Наш ответ — модель функционирования команды. Эту модель мы позаимствовали у команды разработчиков Microsoft Office.

Следующие электронные книги стали доступны для загрузки:

Алексей Федоров. Знакомство с Microsoft Visual Studio Team System 2008
Командная разработка с использованием Visual Studio Team Foundation Server

Эти и другие бесплатные книги можно скачать здесь.

(Эта заметка является завершением серии постов, в которую вошли «Технический долг», «Синдром рефакторинга» и «Эффект второй системы»)

В чем польза паттернов проектирования? (*) Это, прежде всего, повторное использование проверенных архитектурных решений, а также упрощение коммуникаций между разработчиками. Но ведь помимо паттернов проектирования существует и масса других паттернов: существуют паттерны кодирования, тестирования, модификации кода (a.k.a. рефакторинг), существуют архитектурные паттерны и многие другие. Поскольку мы, на самом деле, редко делаем что-либо по-настоящему новое, то проверенные типовые решения существуют для огромного количества областей. И поскольку большинство проблем, с которыми сталкиваются команды разработчиков, также не отличаются разнообразием, то и поведение этих людей также весьма однообразно.

«Технический долг», «синдром рефакторинга» и «эффект второй системы» — это типовые ситуации, с которыми периодически сталкивается команда разработчиков. И главная польза от них как раз и заключается в том, чтобы увидеть проблему и доказать ее существование нужным людям. Если вы сами поняли, что технический долг проекта слишком велик, то используя денежную метафору будет уже значительно проще доказать важность этой проблемы менеджеру или заказчику. А затем взвешенно показать ему альтернативные пути развития событий: (1) оставить все, как есть; (2) уменьшить технический долг путем разумного рефакторинга или (3) переписать все нафиг.

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

Именно поэтому, хотел бы вам предложить изменить эту схему. А именно — несколько рекомендаций из библиотеки ITIL. Они-то и станут тем фильтром, на который осядет весь неизбежный негатив нашей профессии. Если вам еще интересно – добро пожаловать под кат.

Добрейшего.

В октябре в Москве проходила очередная конференция «Разработка ПО». Поехать не смог (да и узнал слишком поздно), однако почитать темы и тезисы докладов, послушать отзывы — такая возможность имелась. Я хоть и в берлоге на берегу моря живу, но инторнеты у нас тоже имеются, да.

Решил узнать, что нынче говорят про SCM в кругах разработчиков — это моё профессиональное хобби. Выяснилось, что почти ничего. Однако был на этом празднике жизни один доклад, который таки оправдывает существование конференции :) Более того, он сильно перекликается с одной из моих старых заметок.

Issues and Challenges with Industrial-Strength Product Composition (Проблемы и спорные вопросы сборки продуктов промышленного уровня). Докладчики — потомки суровых викингов, Лар Бендикс (адъюнкт-профессор из Lund University) и Андреас Горансон (сотрудник Sony-Ericsson).

Что же так порадовало?

Добрейшего.

Набрёл на неплохой текст от команды Microsoft Team Foundation Server: Branching Guidance
Будущим и нынешним пользователям обозначенной системы предлагается:

1. проникнуться важностью ветвления и слияния изменений для работы больших команд;
2. узнать, какие типы веток бывают и как строить изоляцию работы на их основе;
3. посмотреть на практических примерах как надо правильно отращивать и мёржить изменения.

В этой статье рассматривается настройка continuous integration процесса с метриками кода. Предполагается работа с java кодом и библиотеками: junit, cobertura, findbugs. В качестве системы сборки используем ant, а сам процесс будет управляться из cruise control. В качестве scm будет немного git'а.

Что мы получим в итоге? Ява проект с ant'овским сценарием сборки. Итогом сборки будет откомпилированный проект и набор метрик: отчеты по junit тестам, процент покрытия кода тестами и отчет о потенциальных ошибках. В дополнение, весь процесс сборки будет проходить ежедневно в автоматическом режиме и вся история метрик сохраняется для групповых отчетов.

Прошло много времени, прежде чем я созрел на написание второй части статьи, посвященной управлению конфигурациями. Тому, что это наконец таки свершилось способствует тот факт, что не так давно мне посчастливилось выступать на конференции PHPCONF 2009 8 октября (Web Architect Workshop Day) с мастер-классом «Метод организации репозитория исходного кода». Для выступления были заблаговременно подготовлены презентация, а также текст доклада. Несмотря на отличную организацию мероприятия, для публичного доступа так и не были выложены материалы докладов, входящих в программу конференции. В качестве компенсации я решил таки опубликовать материал, использованный в моем выступлении. Кроме данной статьи, (которая является логическим продолжением предыдущей), посвященной конфигурационному менеджменту, для публичного обозрения доступны слайды презентации.
В данной статье пойдет речь об инструментах, использующихся при управлении конфигурациями. Поэтому в первую очередь хотелось бы заострить внимание на том, как инструменты, использующиеся в разработке могут влиять на процесс создания ПО.

Как разрабатывать большое ПО? Ни для кого не секрет, что потребность в разработке больших и сложных программных продуктов была всегда и также всегда была независимой от уровня технологий, существующих на тот или иной момент времени. Но исследуя и анализируя существующие подходы к девелопменту, я так и не смог ответить на самые простые вопросы, связанные с «правильной» разработкой качественных программ. Одним из простейших вопросов, который я перед собой ставил, был вопрос о том, как назначать номера версий выпускаемому программному продукту.

И снова здравствуйте.

Продолжаю публиковать цикл статей о SCM — управлении конфигурацией ПО.
3 предыдущие заметки можно прочитать в этом же блоге.

Сегодня расскажу о том, с чем работает большинство читателей — о контроле версий.

Disclaimer

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

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

Так вот — о формализации. Намедни провёл опрос с целью выяснить — какие метрики народ использует в своих проектах. Выяснилось страшное. Из тех, кто вообще решил что-то выбрать (т.е. без воздержавшихся) — половина не просто не собирает метрики, но и не собрается. Надо полагать, с документированием процессов всё ещё хуже.

Стало быть, адресую сегодняшнюю заметку тем, кто немного задумывается над тем, куда движется его проект и насколько эффективно работает команда.

Приветствую. Как и обещал — продолжение цикла заметок об управлении конфигурацией ПО, в простонародье называемом Software Configuration Management. Весь цикл можно найти по ссылке на тэг CM. Из ещё неохваченного осталась буквально пара заметок.

Сегодня речь пойдет о довольно спорном и в чём-то провокационном вопросе — распределенных системах контроля версий. Знаю, что подобные системы популярны среди хабравчан, так что заранее готов в обсуждению. Более того — призываю не проходить мимо и высказаться, если есть что сказать по делу.

Cigarettes and coffee, man, that's a combination.
© «Coffee and Cigarettes», Jim Jarmush

Сам я не курящий, однако для книжки, про которую пойдет речь, это вполне подходящий эпиграф. Потому как книжка — про соединение двух очень связанных областей — это гибкие методологии разработки (a.k.a. Agile) и управление конфигурацией (a.k.a. SCM).

Речь пойдет о книге Adapting Configuration Management for Agile Teams: Balancing Sustainability and Speed за авторством Марио Морейры (Mario E. Moreira). Название можно перевести как "Применение SCM в командах с гибкими методиками разработки: в равновесии между устойчивостью и скоростью". Что по-русски, что по-английски — одинаково громоздко, однако смысл понятен.

Перед прочтением опасался, что книжка будет похожа на героев старого анекдота про морскую свинку, однако опасения были напрасными. И про Agile, и про SCM там — в полном объёме.

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

Ниже речь пойдет о следующих вещах:
— Рабочие продукты и конфигурации;
— Компонентная разработка;
— Продуктовые линейки;
— Стабилизация результатов работы;
— Baselines AKA базовые конфигурации;
— Конфигурации при компонентной разработке;
— Конфигурации при наличии продуктовых линеек.

Добрейшего.

Не так давно я озадачился поиском книжек по управлению конфигурацией ПО. В результате получился обзор литературы по SCM, преимущественно англоязычной. Финалистами стали 3 книжки, которые было решено приобрести и изучить. И первой из них — как по «интересности», так и по авторитетности лично для меня — стала книга Configuration Management Best Practices: Practical Methods that Work in the Real World, написанная Бобом Айелло (Robert Aiello) в соавторстве с Лесли Сакс (Leslie Sachs). На русский название можно перевести как "Лучшие практики управления конфигурацией: практические методы, работающие в реальном мире".

Пока заказывал и дожидался — успел прочитать в электронном виде (пиратство — страшное зло!), однако потраченных денег не жалею — труд автора должен быть оплачен. Да и книжка весьма приятна внешне и внутренне. О чём же она?