Pull to refresh

Comments 31

А кроме как Burndown, что здесь еще agile специфичного?
Организация кода в SVN, например.
Можно сказать, что любой из приведнных компонентов легко заменяется альтернативным без ущерба. А вообще очень типичный наборчик и не для agile. Даже для «водопада» вполне водходящий
Вообще говоря не набором единым определяется agile :) От того, что он подойдет для водопада, хуже явно не будет :)
Поделитесь, пожалуйста, информацией про альтернативы. Очень заинтересовала меня эта тема.
Например:
Eclipse — IntelijIDEA
Redmine — заменяется Trac или другой (JIRA, Bugzilla, Mantis, etc) приличной системой багтрекинга (можно с отдельной Wiki, а ее выбрать отдельно)
Maven 2, M2, Nexus — IvyDE, Ivy, IvySvnResolver (Кстати экономия на инфраструктурных единицах)
TeamCity — CruiseControl, Hudson, etc
Subversion, etc — любая система контроля версий (в частности для agile, мне кажется наиболее подходящей DVCS)
TestNG — JUnit
> Про интеграцию Subversive и Mylyn см. документацию
Так все-таки Subversive или Subclipse?:)
для такого подхода к использованию системы контроля версий git будет удобнее
Мы использовали очень похожую схему, поэтому предлагаю несколько улучшений:
1. Артефакты в должны попадать в Nexus после сборки в TeamCity, после того как прошли юнит-тесты и функциональные тесты в независимом окружении, а не на машине разработчика, как нарисовано у вас на диаграмме. В Вашей диаграмме получается, что в репозиторий Maven могут попасть библотеки, которые содержат классы, которые не были добавлены в Subversion(что явно расстроит ваших колег). Кроме того TeamCity может корректно проставить версию вашему jar файлу, который будет добавлен в репозиторий Nexus, а иначе версионирование Ваших библиотек недетерменировано.

2. Хорошим решением является интерграция баг-трекера с системой контроля версий, это позовляется закрывать задачи в багтрекере, просто коммитом с правильным комментарием — номером issue. Не уверен насчет возможностей Redmine, но если баг-треккер поддерживает управление релизами, то можно привязывать к релизу в багтреккере привызывать определенный бранч — для багфиксов, этим решается проблема документации, к какому релизу привязана какая ветка. (Соглашения соглашениями, а если есть простая возможность получить документирование проекта — имхо, нужно пользоваться)

3. Если у вас тестирование(функциональное и нагрузочное), и правда, автоматизированно, то по результатам сборки, результаты этих тестов, неплохо бы получать, как минимум, в виде артефактов в TeamCity, а лучше в баг-треккере/вики, потому что тогда у вас вся документация по закрытым багам и результатам тестов будет привязана к конкретной сборке/релизу

4. <юмор>ну и если уж у Вас Scrum, то неплохо бы стрелочку между разработчиком и тестером нарисовать, все таки коммуникации в agile превыше всего</юмор>

P.S. За Redmine спасибо — не знал о таком продукте.
Поделитесь, пожалуйста, опытом, как красиво интегрировать TeamCity-SVN-JIRA так, чтобы номер тега в SVN при успешной сборке билда становился бы сразу «видным» в JIRA в виде отдельного поля «build version». Идея в том, чтобы закрывать таски с JIRA с указанием номера сборки, в которой этот таск (баг) был закрыт. Нужно для тестировщиков. Если есть альтернативные мысли как связать сборки и таски, буду рад Вашим мыслям.
Огромное спасибо за статью. Очень хочется наладить работу в проекте, участником которого я являюсь. Буду очень благодарен за ссылки на полезные материалы.
Как вариант, большая часть плагинов заменяется функциональностью Cruise Control.
Не увидел статического анализа кода, например PMD.
Согласен.
Team City тоже умеет делать анализ кода.
Хотелось бы услышать о системе документирования кода. Конечно, код должен документировать сам себя. Но все же желательно иметь какой-нибудь инструмент, который будет обеспечивать автоматической формирование документации, на основе хорошо написанного кода :)
А javadoc чем не хорош для этой цели?
Я не из мира java, возможностей javadoc не знаю :). Сам использую ndoc и ghostdoc.

Но хотелось бы иметь примерно следующее.
Имеется написанный код, методы и классы названы в соответствии с Agile принципами(тесты тоже :)).
После очередного «коммита», все это собирается, само документируется(ghostdoc или аналог) и выкладывается, например в wikki. В результате получаем готовое описание кода без лишних хлопот.
Помимо javadoc мы еще широко используем Wiki
Да я про burndown в редмайне и вообще все что с ним связано (с переводом багов в нужные статусы и т.п.). А что у вас за аджайл? Скрам?
Зато согласитесь, burndown — это один из очень удачных инструментов отчетности высшему руководству :)
Соглашусь:) Мы чертим фломиком на бумажке, которая прилеплена магнитом на доске. Гораздо нагляднее:)
Aptana пользовался, инструмент так сказать «швейцарский нож», но для меня она показалась глючной (ломала установку обновлений для eclipse на раз). Для манипуляций с html,jsp и проч. начал использовать
Jboss Tool. Есть удобный редактор web.xml
Присоединяюсь ко всем заметившим, что данный набор технологий почти никак с аджайл не связан.

Мы используем следующие инструменты:
Intellij IDEA. Здесь я описывал, чем она лучше Eclipse.
— Для CSS, JavaScript, HTML — всё та же IDEA. Платная версия прекрасно с ними справляется.
— Для работы с SVN и GIT — всё та же IDEA. Она поддерживает эти системы из коробки, не нужно инсталлировать дополнительные плагины. И интерфейс у IDEA для DIFF и COMMIT гораздо более удобный.
— RunJettyRun — хорошая вещь, но мы предпочитаем писать свою запускалку. Здесь процесс описан подробно.
— Для Continuous Integration используем Jenkins. Не знаю, лучше ли он TeamCity, но по крайней мере бесплатный.
— Для управления задачами используем PivotalTracker. Вот это реально аджайлный продукт, Jira рядом с ним отдыхает.
— Для UI тестов — Selenide (в случае Java) или WatirSplash (в случае Ruby).
— Для зависимостей используем Ant+Ivy либо Gradle. Maven не любим.
Sign up to leave a comment.