Agile Chronicles # 6: инструменты, дополнительный день слияния и отложенные переходы
Agile Chronicles — это набор статей, документирующих мой опыт использования Agile- процесса ( Scrum ) в разработке программного обеспечения для моего текущего проекта Flex.
- Часть 1 — Стресс
- Часть 2 — Рефакторинг кода
- Часть 3 — Ветвь Workflow
- Часть 4 — POC, стратегия и проблемы дизайна
- Часть 5 — Критерии приемки и оценка
- Часть 6 — Инструменты, дополнительный день слияния и отложенные переходы
- Часть 7. Ошибки, модульное тестирование и пропускная способность
- Часть 8. Демонстрация, выгорания и жонглирование
- Часть 9 — Сфера Creep
- Часть 10 — Выводы
Эта статья посвящена определению того, какие инструменты мы используем для общения в географически распределенной команде, почему мы добавили дополнительный день для слияния кода в магистраль между ветвями и почему мы отложили разработку переходов.
Фон
Читатель попросил меня описать инструменты, которые мы используем для общения, и, таким образом, удаленно использовать процессы Agile в нашем текущем проекте. Если вы читаете об Итеративной разработке , Непрерывной Интеграции и Scrum, то общая тема, которая продолжает появляться, — это «общение» не только между разработчиками, но и членами команды. Хорошее общение в лучшем случае приводит к хорошему проекту, или, по крайней мере, никаких сюрпризов для плохих.
Чтобы подвести итог процесса, мы используем итеративный подход в нашем процессе разработки Agile. У нас есть 2-недельные рабочие циклы, называемые Sprints, где мы работаем над тем, чтобы в конце Sprint было готовое к использованию программное обеспечение, практически готовое к работе. В первый понедельник на нашей сессии планирования мы планируем приоритетные пользовательские истории для Sprint, делаем оценку задач и времени для этих пользовательских историй и расставляем приоритеты. Первый четверг — наш первый день слияния (см. Ниже), за которым следует еще один в следующую среду. Во 2-ю пятницу мы проводим UAT, приемочное тестирование пользователей, и проходим то, что мы сделали / не выполнили. Исключая сессию планирования и UAT, наше собрание Scrum проводится каждый день около 10:00 по тихоокеанскому времени / 13:00 по восточному времени. На этой встрече мы объясняем, что мы сделали, что планируем делать в течение (оставшейся части) дня,и любые потенциальные блокираторы (вещи, мешающие вам прогрессировать). Они длятся от 5 до 10 минут.
Клиент состоит из генерального директора / программиста, старшего архитектора и двух фронт-энд-бэк-эндов разработчиков. Они расположены в Калифорнии (кроме одного члена, который я забыл). Остальная часть команды находится в Атланте, штат Джорджия. Хотя у обеих команд есть офисы, дизайнер и разработчики Flex обычно работают дома. У нас разница во времени 3 часа; ака 4 разных часовых пояса. Делает даты отладки веселыми. В начале проекта у нас был один Biz Dev, один Market Analyst, один User Experience Designer, один Designer и существующий менеджер проекта. Теперь, когда мы находимся в разработке, это тот же Менеджер проектов, тот же Дизайнер (иногда участвующий), Разработчик Flex, и я, другой Разработчик Flex.
Инструменты торговли
Есть много инструментов, которые составляют процесс, поэтому, чтобы убедиться, что я охватил все, я собираюсь охватить все (кроме серверных вещей, потому что это не моя слабость и не ответственность).
2 разработчика Flex используют Flex Builder 3 в качестве основного инструмента кодирования. Мы разрабатываем все наши ActionScript, MXML и CSS в нем, а также компилируем как наши отладочные, так и релизные сборки. Наши тестовые наборы GUI и (начинающие) модульные тесты, использующие fluint, запускаются из множества файлов Application.mxml основного уровня. Мы вручную меняем, какие основные файлы помечать как основное приложение. Мой коллега использует 2 компьютера с Windows XP с автономной установкой Flex Builder, и я использую автономный Flex Builder 3 на 1 компьютере с Windows XP и 1 MacBook Pro с OS X 10.5.5. Я считаю, что он использует Flex SDK v3.1 и меня v3.2.
На наших компьютерах мы используем клиент Tortoise Subversion для проверки нашего кода. На моем Mac я использую Версии . Мы говорили о внедрении Cruise Control или другого, который начинается с H на сервере для автоматических сборок, но просто никогда не обходится без него. На моем ПК я использую BeyondCompare для слияния моего кода в репозиторий и слияния его кода с моей локальной сборкой. Я использую то же самое на своем Mac, работающем через CrossOver (позволяет запускать приложения Windows на вашем Mac без установки Windows). Для отладки веб-трафика я использую HTTP-прокси Charles . Это помогает мне видеть вызовы AMF Flash Remoting, которые я делаю в Python, который использует PyAMF .
Наш дизайнер использует Flash CS4 и Illustrator для всех наших скинов. Он сэкономит на CS3, так как мой коллега и я все еще используем CS3. Он также отправит нам большое количество PDF-файлов и несколько SWF или MOV, иллюстрирующих более сложные переходные состояния приложения. Раньше мы использовали Basecamp для активов примерно одну неделю, но никто на стороне разработчиков, похоже, не использовал его. Большинство наших скинов являются векторными в FLA; очень немногие являются растровыми, если они не должны быть. Как обычно, мы используем пользовательские шрифты, и опять же, как обычно, это полная боль в заднице.
Мы все пытаемся использовать Jira для отслеживания ошибок, что сопряжено с трудностями при записи дефектов в Первую версию и последующем переходе.
Мы используем Djangoна заднем плане. У каждого разработчика есть своя песочница, которая обычно работает на своем собственном порту. Песочница — это ее собственный экземпляр, и каждый разработчик может поразить свою собственную песочницу, не беспокоясь о вмешательстве какой-либо другой разработчика. Каждая песочница имеет свою собственную версию серверного и клиентского кода из Subversion. Разработчик должен развернуть код и запустить / остановить экземпляр из веб-интерфейса Django. Я не уверен, что каждая песочница получает свою собственную нить, но я знаю, что, как только Apache подключится, мы сможем без проблем подключиться к одной и той же песочнице. До Apache он был однопоточным, и приложение замедлялось до ползучести, если все мы одновременно попадали в песочницу (во время UAT). Обычно я экспортирую сборку релиза, проверяю bin-релиз в Subversion, захожу в веб-интерфейс и нажимаю «Deploy Code» для моей песочницы.Затем я очищу кеш браузера и протестирую приложение по адресу http://server.com:9002. Я сделал приложение Flex способным выяснить, к какому порту он подключен, и использовать его для ServiceLocator следующим образом:
if(Application.application.url.indexOf("file://") == -1)
{
DebugWindow.debug("Application.application.url: " + Application.application.url);
var path:String = Application.application.url;
var sub:String = path.split("http://")[1];
var main:String = sub.substring(0, sub.indexOf("/"));
var finalURL:String = "http://" + main + "/gateway/";
ServicesLocator.instance.setRootURL(finalURL);
}
Мы все используем мгновенный обмен сообщениями в качестве основного способа связи, с дополнительным телефоном и третьим по электронной почте. У большинства из нас есть учетные записи в AIM , MSN , Yahoo , Skype и Gmail (кроме меня, я отказываюсь использовать свою учетную запись Gmail для чата, мне нужна новая… и Skype тоже). Пользователи Mac используют Adium , а пользователи ПК обычно используют Trillian, Эти программы позволяют нам объединить все наши учетные записи IM, кроме Skype, в одну программу. У всех нас есть 1 или 2 телефонных номера, по которым обычно можно позвонить, один из которых является мобильным, а другой — стационарным. Наша электронная почта обычно предоставляется компанией, и мы либо используем домены Google для компании, либо маршрутизируем через интерфейс Gmail (поскольку Gmail может подключаться к любой учетной записи POP). Это позволяет нам объединять наши электронные письма в один интерфейс и использовать Документы Google .
Мы все используем Документы Google в той или иной форме. Хотя с их текстовыми процессорами и приложениями для работы с электронными таблицами не всегда легко работать, у них есть три привлекательные функции, которые привлекли нас к их использованию. Во-первых, они бесплатны. Во-вторых, они позволяют нам сотрудничать в режиме реального времени или в наше время. Поскольку мы можем обмениваться документами и редактировать их вместе в режиме реального времени, это очень помогает в документации API и последующих ссылках. То же самое можно сказать об отслеживании задач и времени с использованием электронных таблиц. Это то, что я использовал в течение последних 3 лет, портируя свое время на любое приложение, которое какая-то компания использует для меня, чтобы отслеживать свое время (SAP, NetSuite, VersionOne и т. Д.). В-третьих, он интегрируется с интерфейсом электронной почты Gmail, что упрощает отслеживание.
Для управления проектами мы используем первую версию . Я запишу то, над чем я работаю, и когда я начну и остановлю что-нибудь в течение дня, в электронной таблице Документов Google. В конце дня я запишу свое время, потраченное на задачи, в Первую версию и создам новые задачи для любой задачи, которую я не планировал во время сеанса планирования. Я должен использовать Firefox, так как он не работает ни в Safari, ни в Camino .
Добавление дня слияния
За последние два спринта произошли две проблемы, и мы решаем их в следующем спринте с новым днем слияния. Менеджер проекта не может определить статус пользовательских историй без быстрой проверки качества последней сборки. Если он не может определить статус пользовательских историй, он не может установить ожидания клиентов и дать им прозрачность относительно того, где мы находимся в статусе приложения. Хотя первая версия должна быть в состоянии предоставить вам этот показатель, если ваши разработчики последовательно и точно вводят свои задачи и время, это НЕ гарантирует, что история задачи / пользователя соответствует критериям приемлемости. Поскольку менеджер проекта готов к отправке завершенных пользовательских историй, именно он проводит первоначальное тестирование качества, чтобы убедиться, что пользовательские истории фактически завершены, а если нет, то выяснить, почему,и / или информирование клиента о точном прогрессе.
Он может сделать это только с работающей сборкой. Будучи моим первым знакомством с Agile-процессом, я не впервые делал итеративные сборки. Я начал делать это самостоятельно, увидев, как раннее получение билета в чьи-то руки привело к более высокой степени фактической поставки достойного продукта. Несмотря на это, теперь, когда у меня было целых 6 полных дней, я мог кодировать содержимое своего сердца и не беспокоиться, если что-то не скомпилируется, на самом деле вызывает проблемы. Премьер-министр не может держать клиента на 100% информированным, не искренне доверяя разработчикам точную оценку того, где мы были с нашими пользовательскими историями. Мы не можем сказать «хорошо», потому что в День слияния все меняется, например, что-то ломается или не работает «правильно».Наличие одного дня для точной оценки, которая может не обязательно совпадать с прошедшими полторы недели, плохо для клиента, плохо для премьер-министра и, как правило, плохо для проекта.
Во-вторых, клиент — это тот, кто выполняет работу веб-службы. Поскольку мы небольшая команда, они хотели убедиться, что большинство веб-сервисов, которые они для нас создали, находятся в хорошей форме, чтобы им было удобно переходить к другим вещам. Я не мог дать им исчерпывающий ответ, потому что я был занят другими пользовательскими историями и не мог собрать их достаточно быстро для них. Это вызвало у них неуверенность, потому что они никогда не знали, работают ли они, действительно ли они работали, и подчеркивали их, работая над другими пользовательскими историями. Одно дело, когда парень на стороне сервера грызет тебя; это другое, когда это клиент. Технически, не должно быть разницы, так как вы в одной команде и пытаетесь помочь друг другу. Это то, что дало мне идею слиться ранее. С тех пор как я облажался на прошлой неделе,отсутствие полностью работающих веб-сервисов на выходных заставило меня отчаянно пытаться спасти работу на выходных в День благодарения и найти что-то, что можно было бы продемонстрировать для моих усилий. Итак, я слился рано. Это значительно упростило День слияния с обычных 2 часов до 15 минут и было намного менее напряженным (ну, слияние было менее напряженным, я все еще подчеркивал потерю большого количества времени в первую неделю спринта).
Я поднял предложение в нашем посте UAT, где мы обычно говорим о том, что прошло хорошо, что нет, что мы можем реализовать, чтобы улучшить положение вещей, и что еще не реализовано, что, как мы сказали, мы сделаем в прошлом спринте. Премьер-министр и мой коллега не работали, поэтому я предложил провести первый четверг в Спринте в контексте: «Разумно предположить, что вы сможете получить рабочую сборку за 4 дня». Технически это 3 полных дня, но что угодно. Таким образом, премьер-министр может получить точную оценку своего местоположения в первые 4 дня и увидеть подтверждение своих предположений на следующий день перед выходными. Это дает более уверенное чувство предоставления точных обновлений клиенту и более раннего понимания того, как проходит спринт, или как проходит 1 или 2 пользовательских истории. Дополнительно,это дает мне время, чтобы разработчики на стороне сервера могли закрыть свои пользовательские истории.
Отложенные переходы
Переходы в нашем приложении служат важной цели. Наш графический интерфейс очень динамичен, и у нас есть несколько представлений для просмотра одних и тех же данных с более высокой точностью. От тонких переходов, чтобы указать изменение, многословие, используемое, чтобы привлечь внимание пользователя, у каждого есть свое место. Так же, как они важны, они также чрезвычайно сложны. Я дал (хотя и слишком драматичный) показатель: «10% моего времени тратится на то, чтобы что-то работать, в то время как 90% тратится на то, чтобы правильно перейти». Они в реальном времени, даже с использованием встроенных переходов Flex. Это из-за следующих причин.
First off, they aren’t defined. The Designer has them in his head, and he articulates during design comp reviews. I then forget what he said since I’m focused on too many things, and either don’t implement it right, or just don’t implement it with confidence. My co-worker has done a better job of creating quick mock-ups to ensure he has the visual right, and then having an informal call to get feedback. I’ve been trying to get these in a real build instead, which while noble, takes too much time. For some of the more complicated ones, the Designer created a a Flash SWF, and for another a Quicktime Movie in AfterEffects. These were immensely helpful in communicating how something should work.
Regardless, as the design changes naturally over Sprints, so to does the need to constantly re-address how something transitions, if at all. It’s not like Wireframes or Design Comps which are more easily documented; transitions are fluid, using real components so it’s not something that you can quickly create, or quickly create yet justify the work. My guess is this is part of what Adobe is hoping Catalyst will help with. The Designer can create the transitions, which in turn produces MXML that the Developer can use. Seems like a pipe dream to me, but I’m still keeping an open mind.
So, we’ve decided to forego all transitions for now, and allocate time later to implement them once the design has solidified a little more. No point in spending a lot of time fading something, and timing it well with others if it’ll change next Sprint, thus negating all the time spent. Better to get something working first to ensure the design even works once actually developed. Besides, the Designer is more accurate when I actually have something to show; he can more easily articulate how it transitions, and I can better understand since I already know how that something works… or doesn’t work (yet).
The good news is that I won’t have to fear the time sinks that transitions are in Flex. On the flip-side, I’m really paranoid about how I can architect for them. Right now, I’m of the opinion that once the PM allocates some time in a future sprint, I’ll remove all the damn Containers and replace them with Canvas’s, and layout everything by code that I write; code that’s smart enough to handle the timing of multiple transitions and different states. Even that sounds too easy. And if it sounds too easy in software…