Построение инфраструктуры Agile-разработки для NET

[Unlocker]

Всем доброго времени суток!
В обсуждении хотелось бы поднять вопрос обеспечения инфраструктуры
Agile-разработки.
Сейчас в компании действует "водопад", но начальство приходит к выводу
его недостаточной эффективности. Плюс ко всему есть удаленный офис
(филиал в другом городе), при работе с которым хотелось бы настроить и
упорядочить обмен информацией. Сейчас это делается посредством email и
телефона, но на мой взгляд, это неудобно. Разработка ведется на
платформе NET.
Есть ли у участников опыт построения инфраструктуры разработки вкупе с
организацией процесса. Есть ли какие-то важные вехи или этапы, на
которые можно разделить весь процесс (аналог итераций в Agile --
внедрение, использование, корректировка, внедрение ...)?
Буду признателен за высказанные мнения...

--
С уважением,
Максимов Сергей.

[Alexey Korsun]

Доброго времени.

А речь идёт об инфраструктуре коммуникаций? Или об инфраструктуре технической (автоматические тесты, постоянная интеграция)?
Просто очень так объёмно вопрос поставлен.

--
Алексей Корсун

2010/4/2 Unlocker <maksimov.sg@gmail.com>

--
Вы получили это сообщение, поскольку подписаны на группу agile-software-development.

Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу agilesoftwar...@googlegroups.com.
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу agilesoftwaredevel...@googlegroups.com.
О дополнительных функциях можно узнать в группе по адресу http://groups.google.com/group/agilesoftwaredevelopment?hl=ru.

[Unlocker]

Я бы рассматривал оба направления как части одного процесса.
Внедрить всё и сразу -- это фикция чистой воды, т.к. людям нужно
время, что привыкнуть и посмотреть на вопрос критически. Мне интересны
варианты внедренных и работающих конфигураций у участников.

Насколько мне представляется наш вариант (пока только на бумаге)
поэтапно:
1) внедрение связки Subversion + Trac;
2) накрутка плагинов на Trac для обеспечения функционала Agile-
планирования и управления;
3) внедрение CC.NET и интеграция его с трекером, настройка
автоматической сборки и тестирования.
4) ...

В качестве какого стабилизационного периода рассматривать 3-4 итерации
разработки.

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

On 2 апр, 12:22, Alexey Korsun <korsu...@gmail.com> wrote:
> Доброго времени.
>
> А речь идёт об инфраструктуре коммуникаций? Или об инфраструктуре
> технической (автоматические тесты, постоянная интеграция)?
> Просто очень так объёмно вопрос поставлен.
>
> --
> Алексей Корсун
>

> 2010/4/2 Unlocker <maksimov...@gmail.com>

>
> > Всем доброго времени суток!
> > В обсуждении хотелось бы поднять вопрос обеспечения инфраструктуры
> > Agile-разработки.
> > Сейчас в компании действует "водопад", но начальство приходит к выводу
> > его недостаточной эффективности. Плюс ко всему есть удаленный офис
> > (филиал в другом городе), при работе с которым хотелось бы настроить и
> > упорядочить обмен информацией. Сейчас это делается посредством email и
> > телефона, но на мой взгляд, это неудобно. Разработка ведется на
> > платформе NET.
> > Есть ли у участников опыт построения инфраструктуры разработки вкупе с
> > организацией процесса. Есть ли какие-то важные вехи или этапы, на
> > которые можно разделить весь процесс (аналог итераций в Agile --
> > внедрение, использование, корректировка, внедрение ...)?
> > Буду признателен за высказанные мнения...
>
> > --
> > С уважением,
> > Максимов Сергей.
>
> > --
> > Вы получили это сообщение, поскольку подписаны на группу
> > agile-software-development.
>
> > Чтобы добавлять сообщения в эту группу, отправьте письмо по адресу
> > agilesoftwar...@googlegroups.com.
> > Чтобы отменить подписку на эту группу, отправьте сообщение по адресу

> > agilesoftwaredevel...@googlegroups.com<agilesoftwaredevelopment%2Bunsu...@googlegroups.com>

[Alexey Korsun]

Ясно. То есть о технической тоже.

1.) Subversion конечно же в первую очередь.
При этом очень важно обучать людей Agle Version Control:
http://www.infoq.com/articles/agile-version-control
Ещё полезно: http://leansoftwareengineering.com/2009/04/07/feature-crews/ 
и: http://www.deepelement.com/blog/post/2009/04/08/Feature-Crew-Model-for-Small-Agile-Teams.aspx
чтобы никто не боялся мерджей.

2.) По поводу Trac'а - иметь систему для учёта _багов_ стоит, конечно.
Но если у вас команда нераспределённая (или не сильно распределённая - две "полукоманды" ;) ), то задачи и фичи лучше иметь только на Taskboard'е и его сразу и "внедрить". Очень полезная штука безотносительно любого процесса.
Поэтому накручивать Trac не стоит. Я внедрял bugzilla или Trac в нескольких командах только как средство учёта багов.

3.) Определяем роли. Если это Scrum, то кто будет Product Owner, кто Scrum Master. Роли важны, чтобы на совещаниях (следующий пункт) не было споров.

4.) Далее переходим к коммуникациям. Чтобы доска и процесс работал нужны:
a.) ретроспектива - либо каждую неделю, либо раз в две недели. Я бы не стал её делать раз в 4 недели, даже если итерация 4-х недельная. Очень важно получать обратную связь от команды в самом начале. Я вообще считаю ретроспективу самой важной практикой.
б.) ежедневные 10-и минутные stand-up'ы перед которыми нужно обновлять статус задач на доске. Обязательно не более 10-и минут.
в.) планёрка совместная в начале итерации - может занимать много времени (на итерацию две недели в командах, где я ставил Scrum занимала 3-6 часов), но того стоит.

Поработать так 1-2 итерации.

4.) Потом, да - логично сделать CI-систему, чтобы двигаться в направлении постоянного состояния Releaseable для кода. Тут очень поможет пункт 1.

5.) Затем автотестирование. И его интеграция с CI. Постепенно идти в сторону сокращения размеров итераций (к 2-м неделям - оптмум).

6.) Теперь поработать так ещё 1-2 итерации. И на ретроспективах внимательно слушать, что говорят коллеги, и находить корневые причины жалоб итп. А также смотреть, что работает хорошо и стоит усилить.

7.) важный пункт - удобная поддержка рефакторингов. Для .Net это решарпер, например.

Больше технической поддержки в принципе не требуется. Можно автоматически собирать метрики (полезно особенно для больших проектов и больших команд).

2010/4/2 Unlocker <maksimov.sg@gmail.com>

Чтобы отменить подписку на эту группу, отправьте сообщение по адресу agilesoftwaredevel...@googlegroups.com.

[Павел Афанасенко]

Думаю, в качестве технической платформы вам поможет TFS.
В версии 2010 там уже поддержка Agile-разработки.

2 апреля 2010 г. 16:04 пользователь Alexey Korsun <kors...@gmail.com> написал:

> 2010/4/2 Unlocker <maksi...@gmail.com>

[Nikita Filippov]

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

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

2 апреля 2010 г. 18:33 пользователь Павел Афанасенко <pavel.af...@gmail.com> написал:

--
_______________________________________
Nikita Filippov. CEO, Agile Coach at ScrumTrek
Cell: +7 (962) 977 15 46, Skype: nikita_filippov
LinkedIn profile: http://www.linkedin.com/in/nfilippov
Профиль МойКруг: http://nikfilippov.moikrug.ru/
web: http://Scrumtrek.ru

[Андрей Бибичев]

Про TFS:

1. нужно ждать релиза 2010 версии (будет с недели на неделю)

2. нужно покупать, а это бобосы и проволочки

3. там всё из коробки и всё в усмерть заинтегрировано, поэтому придется целиком сидеть на этом (их система контроля версий, их issue tracker, их framework для unit-тестирования, их сборочный сервер и т.д.)

4. для всяких портальных штук придется еще покупать SharePoint

5. для наворотов с тестированием - докупать TestLab

Лично мне больше нравится подход "брать отдельные компоненты по месту".

Например:

- система контроля версий: Subversion + плагин VisualSVN к студии + ViewVC (web-интерфейс)

  *) если надоест, то спокойно перелезете на Git/Mercurial и т.п. -- инструменты миграции есть и отлажены, чего не скажешь о TFS

- сборочный сервер: TeamCity от JetBrains (долго пользовались CC.Net, но он убогий и глючный)

  *) тоже сможете поменять со временем (вопрос исправления конфига)

- фреймворк для Unit-тестирования: NUnit или xUnit.Net

- измерение покрытия кода: NCover

- подсчет метрик по проекту: cloc.exe

- issue tracker: хош Bugzilla, хош RedMine, хош Trac

- wiki: здесь MediaWiki по сути вне конкуренции

- ручное тестирование (тестпланы и т.п.): Testopia

Альтернатива последнем трем пунктам: Google Docs (подходит для небольших команд)

* backlog ведете в Spreadsheet-е

* статьи и базу знаний накапливаете в расшаренных документах

* тестпланы - аналогично

Готовую связку Bugzilla+Wiki+SVNSearch+ViewVC можно попросить у Стаса Фомина (у него и докладов куча на эту тему) :))

А.

2 апреля 2010 г. 19:37 пользователь Nikita Filippov <n.fil...@gmail.com> написал:

[Tatiana Vasilyeva]

Привет всем,

 

Согласна с подходом Андрея. И по инструментам, в целом, почти все пересекается. Небольшой комментарий про scrum-тулы. Я пользовалась в разные периоды времени в чуть разных командах и проектах: Excel (допиленным под наши нужды) -> XPlanner -> ScrumWorks (и light и pro). Как ни странно, но сейчас вообще переехали просто в проектную вику. Ну и Taskboard самый обыкновенный, благо команда в кои-то веки не распределенная.

 

---

Таня

[Askhat Urazbaev]

Тоже согласен.

Но (справедливости ради) надо сказать, что они неплохо поработали в VS2010. Лично меня поразила возможность планировать product backlog и iteration backlog в Excel, с последующим сохранением куда то там в недра TFS.

Мы так с одной командой сделали. Я остаюсь фанатом стикеров и доски задач, но так тоже вроде как получается :-)

Асхат

2010/4/2 Tatiana Vasilyeva <vas...@inbox.ru>

--
Regards,
Askhat Urazbaev
Agile Coach, ScrumTrek
+7 (903) 685 93 62
http://scrumtrek.ru

[Unlocker]

Насчет TFS я уже косвенно высказался, а Андрей Бибичев подвел черту в
своем содержательном посте (за что ему респект :). TFS -- это цельно-
монолитная система, которая требует единовременной настройки всего,
включая и SharePoint (без web-управления распределенный проект теряет
свою прозрачность), build-машину и т.п. Прочитав бегло инструкцию по
развертыванию TFS 2005 (что нашел в сети -- 580 стр.), я понял, что
установка и настройка такого продукта потребует серьезной настройки,
пока не всё не заработает целиком и полностью. Старый добрый Apache,
на котором работает, наверное, большинство багтрекинговых систем, я
считаю более гибким и надежным, нежели SharePoint (есть опыт работы с
местным SharePoint-порталом, на котором с завидной периодичностью что-
то отваливается). Но это только мое личное мнение (не претендую на
истину последней инстанции).
Другой вариант -- блочный. В этом случае команда решает, какие
потребности им надо закрыть в первую очередь при следующей итерации
внедрения. При этом есть возможность пересмотреть первоначальные
взгляды сквозь призму уже работающей системы.
Андрей, если не сложно, то можно поподробнее написать про глюки build-
сервера CC.NET? Т.к. build-сервер будет устанавливаться не на первой
итерации, то хочется узнать о подводных камнях таких продуктов, дабы
иметь возможность сделать осознанный выбор. В чем преимущества
TeamCity перед CC.NET?

[Андрей Бибичев]

Привет!

Недостатки CC.Net:

- с завидной периодичностью не хочет подхватывать изменения в конфиге без рестарта сервиса (хотя должен)

- долго мучили нас его сообщения о сломанном билде, хотя он всего-лишь не мог подключиться к SVN-у (например, админы на выходных резвились с сетью) -- но потом это нашли как запатчить настройками

- достаточно отвратительные mail и web отчеты

- автоматический деплой придется настраивать долго и мучительно

- есть всякие мелкие баги, которые чинятся и появляются от билда к билду

- совсем вяло развивается

- САМОЕ ГЛАВНОЕ: не умеет распараллеливать сборку и прохождение unit-тестов по нескольким машинам (или хотя бы на одной машине в несколько процессов) -- для нас это оказалось критично, так как тесты стали занимать десятки минут, при этом они хорошо параллелятся

- для проектов на Java (у нас было и такое) приходится держать альтернативный сборочный сервер, а хотелось бы единой инфраструктуры

Но справедливости ради: просидели на CC.Net года 4!

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

Если нужно, могу выслать CC.Net, который ставится просто x-copy + нашу внутреннюю инструкцию по настройке с примерами конфигов. Думаю, что с этим делом вы все поставите и настроите за считанные минуты.

А.

3 апреля 2010 г. 12:30 пользователь Unlocker <maksimov.sg@gmail.com> написал:

--

[Unlocker]

Андрей, был бы весьма благодарен за CC.Net с инструкцией по настройке.
Просто нам надо начать пользоваться каким-либо инструментом. Что
касается CC.Net, то на его стороне распространенность среди большого
числа пользователей (много мануалов и примеров для начинающих). А
дальше посмотрим что да как...

[Андрей Бибичев]

Ушло по почте в приват.

А.

3 апреля 2010 г. 17:47 пользователь Unlocker <maksimov.sg@gmail.com> написал:

--