Managing a Rails project

Hi Federico,

I'll be interested in your report. It would be neat to be able to use
UML as a front end for a kind of "super scaffolding" generator.

Starr

Hi Again :slight_smile:

Well... the project is almost done. We didn't use Rails, because I
didn't have Rails programmers (instead, we had to use PHP+Smarty), but
we used sequence diagramms that imitates Rails MVC model. The result
was awesome: once that the diagramms were ready, the programmers
understood the application completely. Before starting the
implementation phase, one programmer told me: "wow I can see the whole
application, I know exactly what I have to do".

I made a plan of 5 releases, and they were executed without any
problems. Tomorrow the 5th release will be done, 3 weeks before the
death line.

Now I'm starting a new project, and I will use this technique again in
the design phase, but adding TDD for the implementation phase, and
Rails. If this project goes as well as the first one, I would like to
develop a graphical IDE for Rails... I think it would rock.

Anyone interested in such a tool, please leave the message. I think I
would start working on this in January.

Cheers,
Federico F.

Federico F. wrote:

Now I'm starting a new project, and I will use this technique again in
the design phase, but adding TDD for the implementation phase, and
Rails. If this project goes as well as the first one, I would like to
develop a graphical IDE for Rails... I think it would rock.

Google "Waterfall". Your PHP project went well because Waterfall is
indeed a step up from Code-and-Fix.

However, if your project was larger, then a "design phase" would
conflate any mistakes in design. Your "implementation phase" would
suffer.

Use TDD essentially the same way Rails has used it on itself. Design a
little, code a little, deliver a little, and repeat in small cycles.
Write tests for everything, to make frequent releases safe.

I met with a team using Rails the other day, and unless I
misunderstood them, they seem to be releasing each integration. They
seem to have no "staging server", where most commercial web
applications deploy their source into a simulated production
environment, for smoke-tests before the

                                main deployment. Unless I
misunderstood them, they could apparently change their code on their
own desktop, pass their tests, hit a button, and deploy this new
feature directly to their live server.

That is "agility".

Hi Philip,

Yes, I didn't use an "Agile" approach for this project, because even
though I like some ideas from XP and Scrum, I also like some from CMMi.
So , I'm currently working on a process that mixes what I think is the
best of both worlds.

I do belive that you need to design what you are going to code, before
coding it, and it may be a good practice to do TDD after you have these
design documents. I also think that you need much more less design
documents than those available in RUP.

But, of course, I also don't think that there is THE best way to
develop software. I think it depends on the people you have in your
team.

Cheers,
Federico

Federico F. wrote:

Yes, I didn't use an "Agile" approach for this project, because even
though I like some ideas from XP and Scrum, I also like some from CMMi.
So , I'm currently working on a process that mixes what I think is the
best of both worlds.

I do belive that you need to design what you are going to code, before
coding it, and it may be a good practice to do TDD after you have these
design documents. I also think that you need much more less design
documents than those available in RUP.

RUP is an "agile" process too, and it does _not_ specify that you create lots of design documents before coding.

But, of course, I also don't think that there is THE best way to
develop software. I think it depends on the people you have in your
team.

There are, however, worst ways.

One of the biggest impediments to adopting TDD is the amount of effort you must spend learning to retrofit tests into existing frameworks. (This, in turn, is a good way to vet the quality of those frameworks. Attrocities like ASP.NET should be shunned _specifically_ because they are hard to test.)

Rails, however, provides a testing framework matching most of its features. So all you need to do is just start extending the tests, in parallel to how you extend the application.

So the ultimate goal of TDD, Emergent Design, is within reach of anyone as soon as they generate their first Rails application.

Hi Federico,

Federico Fernandez wrote:

So my intention is to find a way to adopt
an Agile process that fits CMM aswell.

You might want to check out www.niwotridge.com. Glen Alleman is one of the most experienced folks around wrt utilizing agile development methods within a CMMI-compliant overall PM infrastructure.

hth,
Bill

Federico Fernandez wrote:

The real point is CMM/CMMi and it's relation with Agile methodologies.
If you like CMM it is hard to accept pure XP, Scrum... So my intention
is to find a way to adopt an Agile process that fits CMM aswell.

XP satisfies all the CMM KPAs for one team. All the "manage your process" stuff.

This requires you to actually _do_ XP (just as CMM actually requires you to do it, not just speak it!).

A CMM certifier should rate an XP team at Level 3 and part of 4, at least. The remaining KPAs are the inter-team stuff, which XP naturally does not cover.

For example, pure XP requires an Onsite Customer (a "business analyst" role) to author acceptance tests. These tests are analysis, and documentation, and requirements gathering, and - uh - tests. All in one. So the KPAs that require those things are satisfied.

Projects without acceptance tests are not XP, so they also should fail CMM certifiation.

Googling a bit again... I found a paper of some person talking about
"stretching" Agile to make it CMM level 3 compliant. I will read it as I
read more about agile and TDD. Specifically, my doubt now is if you can
design your software with at least one or two UML diagramms before doing
TDD.

CMM does _not_ require you to draw diagrams before you write code.

XP does _not_ forbid them, either.

People practicing XP learn that they need such diagrams less often. This, in turn, increases the value and meaning of such diagrams when they are used. So people practicing XP often write about their experiences, leading to a myth that things like UML and debuggers are forbidden.

A company at CMM Level 5 should lose their certification if they don't try XP in a pilot project, per the KPA "experiment with new processes and learn from them".