IDEA in eXtreme Programming

I think IDEA is very suitable for XP. IDEA integrates Ant,JUit,XPlanner plugin,dashboard for CruiseControl and so on. All principle in XP can be found in IDEA. Now we are using IDEA for XP development.

Not to mention the very nice feature of being able write your tests ahead of your classes.

type

new SomeClassThatDoesntExistYet();

It will be coloured red - because it isnt defined. Alt-Enter - and it will create the class...

-Nick

Thanks for the reply.

I never worked in XP environment. Working together with another programmer on a single system -- Is it Fun :) ?

What kind of ProjectManagement tools do you use? May be there is none, but there should be some kind of planning tools should be there; right?

Haven't used it myself, but there is XPlanner http://www.xplanner.org/

Hi,

Although I am not against XP per se, I think someone has to be careful to believe all the success stories the XP'ers promote. At least reading the book "Extreme Programming Refactored: The Case Against XP" made me think much more carefully to consider the introduction of it as a process.

Instead, I think the aim should be to find a way helping to introduce some degree of agility / flexibility in your SW development process, which helps to deal with unforseen circumstances in your project or the necessity to accept requirement changes to some extent during development.

Whether the XP practices like

- Do only what you need now
- Confine documentation and upfront design to a minimum
- customer on- site
- pair programming
- constant refactoring

are really suitable for your project or the situation it is currently in, is questionable.

Well, we rather have a "developer-on-site" here at our organization (German governmental agency).

I don't think that it has a big importance, whether IntelliJ "supports" or is "suitable" for XP, as this methodology will be replaced sooner or later by something with more hype anyway.

An effective support of UnitTests has only marginally something to do with XP, as Unit Test are usefull in other processes also.

The main thing is that IntelliJ remains intuitive and generates productivity, regardless of the SW process conducted.

As to project planning tools, there is no commercial I found useful or productive. In particular, using MS-Project lead to a too granular planning pattern, which caused a tremendous maintenance and adjustment effort, and sometimes / possibly often it (re-)calculates the plans in a way not transparent, at least to me.

So I ended up doing the planning in a custom Access database using a calendar week as the level of granularity and doing control via determining resource availability in percent of calender week. The quotient of time assigned and availability in a particular week gives me a hint then, if the resource is planned in a reasonable way. Of course there is no dependency checking and I have problems handling things lasting longer than a week, but the whole thing still suites me better than the MS-Project mess.

(Maybe MS-Project isn't that messy, but the learning curve to do it right, is possibly to steep for me and my time budget).

I should mention that our project is lower mid-size (up to 20 team members).

If someone knows of really good SW-planning tool I am interested too.


Regards

Thomas Gülden
Munich, Germany

Thomas,

Wow, Thats really helpfull information. Thanks.

Actually I started of thinking a plugin to IDEA for XP management. Long agao I implemented a thing called JMission, a collaborative project management tool which sits in side IDEs, but unable to go on due to some issues.

I am now thinking of writing something for XP and maily targetting IDEA, because it has lots of features that XP requires and I have idea on how to write IDEA plugin ;).

Not sure whether it is worth to spend time for it. My imagination is -- all programmers will use IDEA and installs this plugin, admin like user creates project information (User stories, tasks etc) using a stand-alone so called AdminConsole, and, each programmer can sig-up for tasks from IDE and change their progress as and when they are done with it (which will be updated for all the users so that everyone knows instatly whats happening) ... , all communication happens thorugh a simple socket based centralized server ... Something like that. This is just a start of this plugin idea. I am sure more things required.

Any comments or suggestions :) ?? Feel free to say "Waste of time & effort" :).

Thanks
Anki.N

Hi,

I am not sure if an IDE is the right place to do / report some sort of planning, whether in XP or some other process. At least in my project, by far not all activities deal with coding (the ultimate activity in an IDE) but coding depends on the success of these activities. Other development efforts aren't done via the IDE, but with other, equally important tools (such as UML-Modelling with Together).

Some people won't have installed the IDE anyway, so planning activity and viewing the project plan should not rely on having an IDE installed together with a particular plug-in.

If there is a planning tool, equally intuitive as IntelliJ, which uses an abstraction level, which is not tight to a certain process (i.e. using a rather neutral terminology such as "requirement" instead of "user story"), where I can determine the level of planning granularity myself and which does planning adjustment more like a "plan refactoring" with a preview as in IntelliJ's refactoring support rather than recalculate everything into a complete mess, then I would condsider using it.

My planning model is currently based on "Features" to be included in the to be developed release. The description of the features is hold in a requirement management SW (we use Doors, which I do not find very productive, due to its very old fashioned GUI). Each feature gets assigned many tasks which are related to a calendar week and assigned to one developer. Tasks which span more than a week, would be entered as several tasks, may be with different time assignements (i.e. 5 days in week a, two days in week B). The amount of time associated to a feature is the sum of time the tasks will last.

For each developer the availability per week is assigned (in fractions of a week) so that overuse or underuse of resources can be determined.

The idea is to give the team members a guide of when things need to be done, but to leave it upon them to schedule their tasks within a particular week.

The list of tasks to be done in a week, are discussed in a team meeting at the beginning of the week so that the activities can be coordinated / orchestrated in more detail when necessary, but this won't be reflected in the planning. Also checked at the meeting is what has been completed during the past week, so that the planning can be adjusted.

So, these are my ideas with regard to planning. Probably they are only applicable for a small to low-mid sized project (like XP projects seem to be ;) ). They are mostly driven by the experience that my predecessor tried planning with MS-Project even on sub-day granularity, producing gigantic gantt charts, which nobody could comprehend. Finally, nobody understood, what he needs to do this week, and after one week the whole plan was already completely garbage.

I should also mention that we are not on a commercial project with very tight deadline constraints. Instead the team runs and maintains a soil information system and does further development of the system at the same time, simultaneously. Therefore, problems in the production system (especially bug fixes, urgent requirements of user's, which become only obvious when actually working with the system) have a heavy influence on the progress of the further development activities. Thus the release plan has to be constantly adjusted, and a new version of the software is released mainly when the essentials are done and the quality is right, which is possible due to not having very tight deadlines.

Kind regards

Thomas Gülden
Munich, Germany

Thomas

Thanks for the explanation. This remembers me that -- I once read in the book

"The ultimate tool we found was A Piece of Paper"

Looks like that really is ultimate for XP planning.

Once again thanks for the info

Anki.N

Hmm,

Maybe you misunderstood my term "calender week" ?

Then I should mention that I do the planning the way I described with an Microsoft Access database, together with a GUI frontend I am writing in Delphi right now. (Using Delphi because I need that tool very quickly. For this click type style of putting a small application together Delphi for me is quicker than Java).

Regards

Thomas

In article <15300551.1096488399459.JavaMail.itn@is.intellij.net>,
Anki <no_mail@jetbrains.com> wrote:

Any idea on how well IDEA is used in XP. Any body know of any success stories
or companies that are using IDEA in XP or any other information related to
it?

I've used IDEA on 3 XP projects now, and it works great. It doesn't have
any particular "XP" features, since XP is just a collection of practices
that various people have been using for years (even decades).

The JUnit integration and the refactoring tools are especially helpful
on an XP project though, since XP suggests writing all code test-first
and to not spend too much time making a big design at the beginning but
rather do a litle design and then refactor when the design needs to be
extended. These features are of course very helpful on non-XP projects
as well.

One consequence of XP is that development machines are shared, so it's
important to keep all the settings and configurations the same on all
the computers. It would be really nice if IDEA could do this more
seamlessly. Right now, you have to export the settings into a jar file
and remember to import them on the other computers when the file has
changed. We had problems checking the iws files in, so we don't do that
anymore, and as a consequence we can't share our run configurations. We
do check our ipr files in though that file changes a lot too which is a
bit of a pain when updating from CVS.

I'd love to see the IDEA configuration stuff split into many files
(perhaps in a conf directory) so that we can check in ones that don't
change too often (code style, project layout) and not check in ones that
change a lot (window positions, etc.)


Erik Hanson