Jump to content

Extreme Programming


gobbledonk

Recommended Posts

Hi!

 

Actually that was the sub project I was working in. The whole project involved more than 2000 people all together and was divided into sub projects which in there turn were divided into sub sub projects, task forces, teams etc. Being a project manager was definitely no stroll in the park.

 

regards

 

ALHOLK

 

Link to comment
Share on other sites

  • Replies 34
  • Created
  • Last Reply

Hi,

 

Pair programming, eh?

 

Must admit gentlement that the concept is NEW to me. However, as a Configuration/QA Manager, I do have a standard called "Walkthrough and Peer review" which can be as deep as you like. I normally don't have time for Peer/Code review (Leave it up to the task Leads) but I do look at code if needed before and during User Acceptance Tests and believe me, programmers do hate me for I will send the codes back if they don't make sense and too complicated for maintenance. :devil: :devil:

 

Must admit that many programmers do work better alone but since the cost of maintenance is much higher than developing, I would think that we do need to have certain standards in programming. The codes is NOT your babies :bow:

 

Jasmine :devil:

Link to comment
Share on other sites

My view of XP is that for a small project, with an unchanging team, in one location, in one time zone, all highly experienced, committed, motivated and driven, it can yield great results. Back on planet earth, where you need repeatable results with " generic" people who can be plugged in and out, a small amount of formal analysis, design and documentation is mandatory. XP is an avant-garde, egalatarian concept that simply does not work in the majority of large IT shops. It does have a place for disposible, short-life point solutions, for inexperienced clients to whom lines of code are the only tangible deliverable, but I would not use it for anything other than medium size risk-mitigation projects...

 

 

Link to comment
Share on other sites

Hi!

 

I was speaking from the software developers point of view. I'm fully aware of that a secretary writing business letters and reading email is better of with windows than with Unix/Linux.

 

The poor quality of the software does piss me off slightly. What pisses me of much more is the fact that they try to decide how I should work. Let me give you an example.

 

The handling of foreign languages is very poor in MS Word. If I'm working with a template in English it is almost impossible to change the language to Swedish. The letter 'i' in Swedish is the word English word 'in' . If I create a document in Swedish Word will still try to capitalise every 'i' in the document. This can be turned off but the deafault setting is to have it turned on.

 

An American programmer once told me that it's a well known fact that the best American programmers don't work for M$, they work at places like JPL, Laurence Livermore etc.

 

In the seventies IBM didn't become the worlds largest coumputer manufacturor by having the best technichians but by having the best marketing staff. The best technichians worked for companies like Univac, CDC, Bull etc., companies that in most cases don't exist today.

 

regards

 

ALHOLK

 

 

 

Link to comment
Share on other sites

Says descartes:

My view of XP is that for a small project, with an unchanging team, in one location, in one time zone, all highly experienced, committed, motivated and driven, it can yield great results. Back on planet earth, where you need repeatable results with " generic" people who can be plugged in and out, a small amount of formal analysis, design and documentation is mandatory. XP is an avant-garde, egalatarian concept that simply does not work in the majority of large IT shops. It does have a place for disposible, short-life point solutions, for inexperienced clients to whom lines of code are the only tangible deliverable, but I would not use it for anything other than medium size risk-mitigation projects...

 


 

I think you're dismissing it too lightly. It is what it is - a light, adaptive methodology and you can take what you want from it. There are undeniably good bits in it - everyone seems to agree that unit testing and writing the tests before coding is a great idea. If you want more formal documentation, etc, you could incorporate some of its ideas into the Unified Process, say. I like adaptive processes. In the "real world", things change.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...