headers
Rakesh Pandey | 1 Nov 2008 10:33
Picon
Favicon

How to measure Project Progress of an Agile Project

HI

How to measure project progress when executing a project using an Agile methodology.  This may seem a
question from someone who is trying to migrate from traditional waterfall approach to agile, but this
question keeps coming to my mind again and again.

 
Regards

Rakesh Pandey, PMP ®
+91-9810112234

[Non-text portions of this message have been removed]

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/extremeprogramming/join
(Continue reading)

Permalink | Reply | 3 comments |
headers
Victor | 1 Nov 2008 12:22
Picon

Re: How to measure Project Progress of an Agile Project

There is the initial project design game, and then quite frequently (daily, 
or weekly, or biweekly) the functional requirements for the next development 
cycle (daily, or weekly, or biweekly).  Those requirements are recorded in 
cards.  Once they are satisfied, the card is marked in some way, let's say 
with the date of completion and the word DONE in green ink.
Also, the number of new unit tests passed could be recorded, together with 
the capital burn rate.  Then all kind of sophisticated graphs could be drawn 
showing the developments as function of time.

Víctor

====================================

----- Original Message ----- 
From: "Rakesh Pandey" <rpandeydelhi <at> yahoo.com>
To: <extremeprogramming <at> yahoogroups.com>
Sent: Saturday, November 01, 2008 5:33 AM
Subject: [XP] How to measure Project Progress of an Agile Project

HI

How to measure project progress when executing a project using an Agile 
methodology.  This may seem a question from someone who is trying to migrate 
from traditional waterfall approach to agile, but this question keeps coming 
to my mind again and again.

Regards

Rakesh Pandey, PMP ®
+91-9810112234
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ilja Preuß | 1 Nov 2008 13:01
Gravatar

Re: How to measure Project Progress of an Agile Project

http://www.xprogramming.com/xpmag/jatRtsMetric.htm

Cheers, Ilja

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/extremeprogramming/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:extremeprogramming-digest <at> yahoogroups.com 
    mailto:extremeprogramming-fullfeatured <at> yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    extremeprogramming-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Meade Rubenstein | 1 Nov 2008 13:40
Picon
Favicon

Re: Matrix Organizations

From my experience Matrix Orgs are put into place because they are
easier to control and understand by Sr. Management - they follow the
McDonald's structure of separating out specific functional areas (fry
person, cashier, etc.) - they tend to be efficient, but not effective
(lots of work gets done, but usually not very beneficial work). 
Functional/Team Orgs are put into place when a strong CIO/CTO is
present who understands how to provide try business benefit from IT
people.  Functional Orgs usually require more mature/able managers
with the ability/will to focus on the important and turn away the
lower priority (but many times squeakier) business managers.

--- In extremeprogramming <at> yahoogroups.com, "Victor" <vmgoldberg <at> ...>
wrote:
>
> Does anybody have any experience or comments about matrix organizations?
> 
> Thanks,
> Víctor
>

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Grigg | 1 Nov 2008 16:56
Favicon
Gravatar

Re: Unit vs Integration TDD

--- "Matt" <maswaffer <at> ...> wrote:
> I suppose.  Although when I entered the web address to
> get to my gmail [... (see below) ...]
> 
> And I haven't even gotten to gmail the application yet.
> 
> So how would you approach eliminating permutations?

At first I thought we were talking about the difficulty in writing 
and testing a web mail application like gmail.  But since none of 
these test cases have touched gmail code yet, I think we're really 
talking about how to write acceptance integration tests to drive Test 
Driven Development (TDD) of a browser.

I think it's helpful to notice that none of the questions above talks 
about anything that wouldn't be visible to the end user.  That makes 
everything mentioned, and all the details that would be needed to 
turn these questions into tests, good material for end-to-end 
integration tests -- automated acceptance tests.

> if I put http:// in first or mail. or just google.com.

Test:
User puts 'http://mail.google.com' into the address box.
Result: User gets gmail signon page.

Test: User puts 'mail.google.com' into the address box.
Result: User gets gmail signon page.

Test: User types 'mail' into the address box.
(Continue reading)

Permalink | Reply | 2 comments |
headers
J. B. Rainsberger | 1 Nov 2008 22:11
Picon

Re: Re: Could customer acceptance tests be sufficient? TDD Adoption Rate Survey

On Wed, Oct 29, 2008 at 9:59 AM, kentb <kentb <at> earthlink.net> wrote:

> I would guess that this proportion of acceptance/unit tests is unusually
> high because we are working with a simple API and moderately simple
> behavior. Maybe not, though. I am working on another project that has been
> going for ten years and we have learned to drive most development from
> acceptance-level tests because testing at too low a level and missing
> something is often more costly than spending extra time writing and running
> higher level tests.

End-to-end tests do not exert enough positive pressure on design
decisions to help me see opportunities to improve the design, which
explains why I write and recommend highly focused, small, isolated
object tests. It seems clear to me that the more layers between the
entry point and the deepest point in the design, the more trouble this
causes. It also seems clear that in a system with only one layer, one
probably wouldn't manage to tell the difference between using
end-to-end tests and isolated object tests.

It so happens I'll talk about the details in Orlando in my tutorial
"Avoid Integration Defects Without Integration Tests".

Take care.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 1 Nov 2008 22:15
Picon

Re: Re: Unit vs Integration TDD

On Fri, Oct 31, 2008 at 4:19 PM, Matt <maswaffer <at> gmail.com> wrote:

> There are a number of components of quality, two of which are "it does
> what we asked it to do" and "it doesn't break".
>
> Integration or specification tests seem to do a pretty good job of
> making sure the software "does what we asked it to do".
>
> The problem that I see is that it is difficult for these tests to make
> sure "it doesn't break" given the number of permutations at higher
> levels.
>
> The response I usually get from BDD guys is "who cares about testing all
> the permutations?" and my response usually is "my boss... since he gets
> the irate calls about bugs". :)

Matt, I'd never thought about this distinction before. I really,
really like it. This provides another Competent-level rule on whether
to write an isolated object test or an integration test. Tinier tests
work better for exhaustive testing to verify the object's don't break,
because larger tests run the risk of a combinatoric explosion. Tinier
tests can cause trouble for specification testing, because one could
lose the forest for the trees. As a result, make tests focused enough
(but not too focused) to clarify intended behavior, but make them as
focused as possible to verify sensible behavior on the unexpected
paths.

I'm glad I read this now. This changes what I'll say in my tutorial.

Take care.
(Continue reading)

Permalink | Reply | 6 comments |
headers
J. B. Rainsberger | 1 Nov 2008 22:16
Picon

Re: Re: Unit vs Integration TDD

On Fri, Oct 31, 2008 at 5:24 PM, Ron Jeffries
<ronjeffries <at> xprogramming.com> wrote:
> Hello, Matt. On Friday, October 31, 2008, at 4:19:34 PM, you
> wrote:
>
>> The response I usually get from BDD guys is "who cares about testing all
>> the permutations?" and my response usually is "my boss... since he gets
>> the irate calls about bugs". :)
>
> Perhaps the problem is having the permutations.

Not all complexity is accidental. Much, maybe most, but not all.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
(Continue reading)

Permalink | Reply | 2 comments |
headers
J. B. Rainsberger | 1 Nov 2008 22:19
Picon

Re: How to measure Project Progress of an Agile Project

On Sat, Nov 1, 2008 at 5:33 AM, Rakesh Pandey <rpandeydelhi <at> yahoo.com> wrote:

> How to measure project progress when executing a project using an Agile
> methodology. This may seem a question from someone who is trying to migrate
> from traditional waterfall approach to agile, but this question keeps coming
> to my mind again and again.

Rakesh, I imagine others will give you great ideas about what to
measure; however, I'd like to ask you your question slightly
differently:

You've chosen to use agile practices on a project. What kinds of
results do you expect from using agile practices on this project as
opposed to doing whatever you used to do on that project?

If you answer that question for me, then I think you'll answer your
question for yourself.
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links
(Continue reading)

Permalink | Reply | 0 comments |
headers
J. B. Rainsberger | 1 Nov 2008 22:27
Picon

Re: TDD Like You've Never Seen it Before

On Wed, Sep 3, 2008 at 10:44 AM, John A. De Goes <john <at> n-brain.net> wrote:
>> 1. You started with about a million lines of code before
>> the first test. Or 15.
>
> Sure. Ordinarily I wouldn't recommend this approach, but a stack is a
> very well-defined problem, and we agreed on the methods to develop
> beforehand. By writing the signatures upfront, we get that grunt work
> out of the way and can focus on the red/green/refactor cycle.

Yes, but then you call it "test-driven development", which it clearly
is not. Why confuse people?
--

-- 
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contribution Agile Software Practice

------------------------------------

To Post a message, send it to:   extremeprogramming <at> eGroups.com

To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe <at> eGroups.com

ad-free courtesy of objectmentor.comYahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/extremeprogramming/

<*> Your email settings:
    Individual Email | Traditional
(Continue reading)

Permalink | Reply | 59 comments |

Gmane