headers
zdnfa | 1 Nov 2009 03:58
Picon
Favicon

Re: Designing and documenting in XP


--- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffgrigg <at> ...> wrote:
>
> I still find a traditional Entity-Relationship Diagram to be quite useful:  It serves as a road map to the
database -- its tables and their relationships.

I totally agree with you. We have used ERD, DFD, and Swimlane diagrmas in a government project and these
diagrams helped a lot in drawing an initial pictiure to the system, and user stories were documented using
these models. The nice thing is that this process helped in bringing up a common understanding amongs
users themselves.
> 
> It can easily take several man-days to get an ERD into really usable form, even with good tools to generate
the basics of it.  But it serves as a shared structure to guide discussion and design.
> 
> I've seen that some people try to draw these ad-hoc, as needed.  But that requires either memorization of
all the content, which takes months and is unreliable, or regular repeated rediscovery of the information.

We also found that a reverse engineered code into use case after every release is very helpful in creating a
project documentation repository that helped in up coming releases.
> 
> 
> I've found some other diagrams useful too:  Generally speaking, something that gives you a high level
overview of the system, a "road map" is likely to be useful.
> 
> 
> The failure I've seen in document-driven projects is the idea that you must document everything that can
be documented.  Aside from consuming excessive resources to create and maintain such documentation,
they create the problem of how can you find the documentation you need, buried deep inside large stacks of
largely useless drivel.
>
(Continue reading)

Permalink | Reply | 7 comments |
headers
Bill Caputo | 1 Nov 2009 04:24
Favicon

Re: Re: Designing and documenting in XP

Zaidoun, who is this We you refer to in all of your posts?

Thanks,
Bill

On Sat, Oct 31, 2009 at 10:58 PM, zdnfa <zdnfa <at> yahoo.com> wrote:
>
>
> --- In extremeprogramming <at> yahoogroups.com, "JeffGrigg" <jeffgrigg <at> ...> wrote:
>>
>> I still find a traditional Entity-Relationship Diagram to be quite useful:  It serves as a road map to
the database -- its tables and their relationships.
>
> I totally agree with you. We have used ERD, DFD, and Swimlane diagrmas in a government project and these
diagrams helped a lot in drawing an initial pictiure to the system, and user stories were documented using
these models. The nice thing is that this process helped in bringing up a common understanding amongs
users themselves.
>>
>> It can easily take several man-days to get an ERD into really usable form, even with good tools to generate
the basics of it.  But it serves as a shared structure to guide discussion and design.
>>
>> I've seen that some people try to draw these ad-hoc, as needed.  But that requires either memorization
of all the content, which takes months and is unreliable, or regular repeated rediscovery of the information.
>
> We also found that a reverse engineered code into use case after every release is very helpful in creating a
project documentation repository that helped in up coming releases.
>>
>>
>> I've found some other diagrams useful too:  Generally speaking, something that gives you a high level
overview of the system, a "road map" is likely to be useful.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Adam Sroka | 1 Nov 2009 04:49
Picon
Gravatar

Re: Re: XP is a philosophy not a religion

On Sat, Oct 31, 2009 at 2:13 AM, zdnfa <zdnfa <at> yahoo.com> wrote:
>
>
>
> >
> > Code is a form of explicit knowledge that matters. We need to code
> > explicitly because machines don't have opinions nor do they appreciate
> > nuance.
> >
> > I'm not sure what code standards have to do with that. Code standards
> > per se are not knowledge at all, they are just about making code
> > comprehensible to us non-machines.
> >
> > We spend a lot of time changing code. In fact, in Agile we spend more
> > time changing code than almost anything else. We have to change it
> > because it is wrong. Then when we make it right it becomes wrong
> > again. It becomes wrong because it is explicit and real knowledge
> > isn't.
> >
> > Understanding how and why the explicit knowledge in code becomes wrong
> > is hard. That is why we need lots of tests. Tests break when we try to
> > change things. That lets us know what we need to do to help the code
> > to evolve towards what tacit truth is telling us. We can also add more
> > tests when we learn new things about the stuff we thought we already
> > knew.
> >
> > Documents are just as wrong as code. Documents don't break when we
> > make them lie. Documents don't let us know how they need to change or
> > when we get it right. Documents are hard to verify and thus harder to
> > change.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Joshua Partogi | 1 Nov 2009 13:06
Picon

How do you charge a customer on XP projects?

Dear all,

As I have read on many XP books, with XP we actually charge customer
based on scope. But how does this differ from traditional project
management? With traditional/waterfall project management we charge
customer based on fixed price, because everything is calculated and
estimated upfront. So if we miss the deadline, it is the consultant's
responsibility. Does this mean we can't or don't charge customer with
fixed price on XP? Does that mean we charge them with man/hours?

Is there any detailed resources on how we charge the customer on
XP/Agile projects? Any guidance and insights on this topic would be
very helpful.

Kind regards.

--

-- 
Certified Scrum Master
http://blog.scrum8.com | http://jobs.scrum8.com | http://twitter.com/scrum8
Permalink | Reply | 3 comments |
headers
Ron Jeffries | 1 Nov 2009 16:37
Picon
Favicon
Gravatar

Re: How do you charge a customer on XP projects?

Hello, Joshua.  On Sunday, November 1, 2009, at 7:06:49 AM, you
wrote:

> As I have read on many XP books, with XP we actually charge customer
> based on scope.

I'm not sure what books actually say how to charge customers but
certainly in every project, actual cost (if not charges) is
proportional to scope.

> But how does this differ from traditional project
> management?

As far as I can see, it differs in just about every possible way.
Traditional project management generally seems to suggest up front
planning and setting of price, date, and scope. XP does none of
those things.

> With traditional/waterfall project management we charge
> customer based on fixed price, because everything is calculated and
> estimated upfront.

... incorrectly calculated, generally. If you have the ability to
calculate those things correctly, I'd say go ahead and do it and
teach the rest of us. :)

> So if we miss the deadline, it is the consultant's
> responsibility.

Traditional fixed price contracts do try to set up this
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Gordon | 1 Nov 2009 17:04
Picon

Re: How do you charge a customer on XP projects?

No matter what process is being used, what it ultimately comes down to is
that there is /always/ a cost to the customer for transferring the risk of a
project to somebody else.  No free lunch.

A contractor who has to eat all cost overruns has to compensate themselves
for taking that extra risk by various tactics, including:
- charging more,
- charging exorbitantly for changes,
- cutting on quality in ways that the customer will only discover after
accepting delivery,

Even if a contractor is naive or desperate enough to not take extra
compensation to be able to cover any costs overruns and litigation out of
their own profits, then they risk going out of business during the project,
which transfers the risk right back to customer.

Where the difference between processes does factor in is that the customer
cannot really know if they are getting their money's worth until software is
being delivered.  Processes that deliver working software every 2 weeks
provides the time-and-material customer a much better idea of whether they
are getting what they paid for than a process that first delivers working
software after several months.

On Sun, Nov 1, 2009 at 5:06 AM, Joshua Partogi <joshua.partogi <at> gmail.com>wrote:

>
>
> Dear all,
>
> As I have read on many XP books, with XP we actually charge customer
(Continue reading)

Permalink | Reply | 0 comments |
headers
zdnfa | 2 Nov 2009 04:43
Picon
Favicon

Re: Designing and documenting in XP


--- In extremeprogramming <at> yahoogroups.com, Bill Caputo <list-subscriber <at> ...> wrote:
>
> Zaidoun, who is this We you refer to in all of your posts?
> 
> Thanks,
> Bill

We, is a team working for the governement of Syria in the Ministry of Finance.

Thanks
Permalink | Reply | 5 comments |
headers
Niklas Bjornerstedt | 2 Nov 2009 12:02

Re: How do you charge a customer on XP projects?

There is a lot of interesting stuff about contracts for agile projects on the net. The problem is that it is
fragmented, no one has collected this into a more comprehensive overview. Here is one interesting paper
and slide set from this years Agile2009 conference:

http://www.bestbrains.dk/dansk.aspx/Artikler

/Niklas
www.leanway.no

--- In extremeprogramming <at> yahoogroups.com, Ron Jeffries <ronjeffries <at> ...> wrote:
>
> Hello, Joshua.  On Sunday, November 1, 2009, at 7:06:49 AM, you
> wrote:
> 
> > As I have read on many XP books, with XP we actually charge customer
> > based on scope.
> 
> I'm not sure what books actually say how to charge customers but
> certainly in every project, actual cost (if not charges) is
> proportional to scope.
> 
> > But how does this differ from traditional project
> > management?
> 
> As far as I can see, it differs in just about every possible way.
> Traditional project management generally seems to suggest up front
> planning and setting of price, date, and scope. XP does none of
> those things.
> 
> > With traditional/waterfall project management we charge
(Continue reading)

Permalink | Reply | 0 comments |
headers
Charlie Poole | 2 Nov 2009 16:12
Favicon

RE: Re: Designing and documenting in XP

Hi Zaidoun, 

> --- In extremeprogramming <at> yahoogroups.com, Bill Caputo 
> <list-subscriber <at> ...> wrote:
> >
> > Zaidoun, who is this We you refer to in all of your posts?
> > 
> > Thanks,
> > Bill
> 
> We, is a team working for the governement of Syria in the 
> Ministry of Finance.

FWIW, I had the same confusion. In some of your posts, "we" 
seemed to mean your team and in other places "we, the XP
community." In other places I was not sure.

Charlie
Permalink | Reply | 0 comments |
headers
Bill Caputo | 2 Nov 2009 16:53
Favicon

Re: Re: Designing and documenting in XP

On Sun, Nov 1, 2009 at 9:43 PM, zdnfa <zdnfa <at> yahoo.com> wrote:
>> Zaidoun, who is this We you refer to in all of your posts?
> We, is a team working for the governement of Syria in the Ministry of Finance.

Thank you for the clarification, like Charlie, I felt the context was
changing, but wasn't sure what your situation was.

I think some of the resistance in the discussion is being directed at
the general nature of your proposals (i.e. I think people hear you
saying: "these techniques and practices, if incorporated into XP would
make it more widely applicable").

Given that, I have some questions:
Is that your intent or is it something closer to stating these things
that have improved your current project(s)?

If its the former, I think that has been addressed already and do not
wish to continue it, however if the latter: are the techniques and
practices ones you've adopted on your projects or ones that you would
like to?

Finally, is your team now using XP or some variation of it, and if not
have you (or they) done so in the past?

Thanks,
Bill
Permalink | Reply | 2 comments |

Gmane