headers
Steven Gordon | 1 Dec 2005 02:10
Picon

Re: Development Case

I recall it was called dX (XP upside-down).

On 11/30/05, Dean Wampler <deanwampler <at> gmail.com> wrote:
>
> FYIW, I believe that Robert Martin and Object Mentor did a similar
> exercise a few years ago for Rational to include as part of the RUP
> product. You might look at the IBM/Rational website. Perhaps there is
> a free version you can reference.
>
> dean
>
> On 11/30/05, Katia <katia.canepa <at> gmail.com> wrote:
> > Hi,
> >
> > I'm investigating on Develpoment case, a template of RUP that tries to
> > describe all the artefacts, roles and the lifecycle model that will be
> > used in a proyect.
> >
> > Do any one knows the equivalent on XP? What do you usually use to
> > describe the lifecycle of the process, the artefacts and roles?
> >
> > Please any answer is welcome.
> >
> > Best Regards from Perú,
> >
> >
> > -Katia
>

[Non-text portions of this message have been removed]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale Emery | 1 Dec 2005 02:59
Favicon
Gravatar

Re: Struggling with how to fit QA in

Hi Denis,

> This got me thinking about exactly what we want testers to do.

I want testers to produce information about the quality of the 
system.  And I want the information to be timely, accurate, and 
relevant to the decisions that key stakeholders will make about 
the software.

> In an ideal world developers would perfectly understand what
> should be implemented and would be able to implement it
> perfectly (e.g. with no errors), so that when they are done
> and commit to subversion, the feature is complete and
> error-free.
> 
> The implication of having testers is that such perfection is
> impossible, and that a tester's role is to catch developer's
> mistakes (either in understanding or in implementation).

I see a softer implication:  We haven't achieved such perfection yet.

Catching developer's mistakes is not a primary focus for me.  A 
more general role is to produce accurate, relevant, timely 
information about the quality of the system.  Developers may 
value the information that helps them to see their mistakes, and 
the things they did well.  Other stakeholders will value other 
information, depending on their concerns.

Dale
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Swartz | 1 Dec 2005 03:42
Picon

Re[2]: Interviews [OT?]


Wednesday, November 30, 2005, 2:13:04 PM, Jim McFarland wrote:

> On 11/29/05, Doug Swartz <daswartz <at> prodigy.net> wrote:
>>
>> Our interview process usually takes about half a day, or a
>> little more.
>>

> While I agree that including pair programming in the interview process
> gives you a better evaluation of the candidates, do those companies
> which use that approach consider that being able to commit that much
> time to an interview is not always feasible for the candidates who
> have jobs.  If you are out of work, it's no big deal, but if you are
> employed, you can't always use time off for an interview that may not
> produce a job.  If you interviewed with a few XP shops you could add
> up significant time away from your current job very quickly.  Anyway,
> just a concern that the interviewers need to consider.

I think you have a point. I believe the only people who we've
asked to come to an interview who declined, had already taken
other jobs, but it's worth keeping in mind.

We always do a phone interview first. So we try to only bring
people on-site who we feel have a good chance of being hired.
Of course we still hire less than 50%.

--

-- 

 Doug Swartz
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Swartz | 1 Dec 2005 03:45
Picon

Re[2]: Interviews [OT?]


Wednesday, November 30, 2005, 5:20:22 PM, Daryl Richter wrote:

> On Nov 30, 2005, at 3:13 PM, Jim McFarland wrote:

>> On 11/29/05, Doug Swartz <daswartz <at> prodigy.net> wrote:
>>>
>>> Our interview process usually takes about half a day, or a
>>> little more.
>>>
>>
>> While I agree that including pair programming in the interview process
>> gives you a better evaluation of the candidates, do those companies
>> which use that approach consider that being able to commit that much
>> time to an interview is not always feasible for the candidates who
>> have jobs.  If you are out of work, it's no big deal, but if you are
>> employed, you can't always use time off for an interview that may not
>> produce a job.  If you interviewed with a few XP shops you could add
>> up significant time away from your current job very quickly.  Anyway,
>> just a concern that the interviewers need to consider.
>>
>> later...
>> jim
>>

> I recently had an interesting interview process.  After spending 8  
> hours interviewing and taking programming tests I was informed that I  
> had passed those trials and was now invited to participate in 2 more  
> complete 9-5 days of interviewing!
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Shore | 1 Dec 2005 05:20

Agile requirements

I've just posted a new essay on my blog titled "How I Use Fit."  It's 
based on my recent post to this group about Fit and TDD.

As I look back, I realize that I've now closed the circle on a pretty 
substantial cycle of essays on agile requirements.  I now cover 
everything from planning months of releases down to how to write a 
single section of Fit document, the work of an hour.  Pretty cool.  
(Hey, wait!  Shouldn't I demand big bucks for this stuff?)

* "Beyond Story Cards" describes how I prefer to handle requirements 
over the course of developing an entire software product.
* "Fit Workflow" describes how I use Fit to facilitate collaboration on 
requirements during a single iteration.
* "A Vision for Fit" gives a concrete example of using Fit to facilite 
collaboration.
* Describe-Demonstrate-Develop, in "How I Use Fit" describes how I 
prefer to develop the Fit document, fixtures, and how actual software 
development comes into play.
* "Elaborating on a Theme," also in "How I Use Fit," describes how I 
structure Fit documents and their examples.

Find links to these essays at 
http://www.jamesshore.com/Blog/Agile-Requirements.html

Cheers,
Jim
--

-- 
James Shore -- Titanium IT -- Successful Software
Recipient of 2005 Gordon Pask award for
Contributions to Agile Practice
(Continue reading)

Permalink | Reply | 20 comments |
headers
Dadi Ingolfsson | 1 Dec 2005 11:53
Picon
Gravatar

RE: Fit and Unit Tests, how to go about it

Nice piece, Jim! I have some questions though:

This method you use to structure your specifications/tests, as in parse.html
in the Fit library, does it not feel a little bit cluttered and complex?
What I mean is, I would have thought that you would put the HTML parsing
tests into a test suite, like in FitNesse, and then have a test in there for
each of the cases? So you´d have:

SuiteParsing
	TestGoodHtmlParsing
	TestOtherHtml
	TestWhitespaceIsPreserved
	TestComplicatedTables
	...

Maybe this is a bit too fine grained for some of the cases but...

Similar to the tests you creates in xUnit you have a test method for each
small piece of functionality in a unit. How is this different? It feels to
me that you are sort of putting all the testing into a single method, if you
see what I mean?

Best regards,
Dadi.

Sam Gentile wrote:
> Don't have much time now but I'm going to ask Jim Shore to comment here as
> he has been teachig our team story-driven development using FIT and has a
> lot of great perspective on it.More soon-)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dominic Williams | 1 Dec 2005 18:00

Re: Re: Struggling with how to fit QA in

Hi Denis,

>> What sort of work does the tester do? Does he or she
>> participate in defining user stories? Are there any
>> automated acceptance tests, and who designs them?
>
> Defining user stories: yes (to the extent we're
> moving in that direction)
> Writing acceptane tests: yes
> Automating acceptance tests: yes

Great. I'm puzzled about how developers still exhibit
"push to QA" behaviour... Can you tell us a story or
two about that? What do they do or say?

Here's another tack:

- are developers responsible for a task or a story?
- when do they consider stories finished?

Regards,

Dominic Williams
http://www.dominicwilliams.net

----

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

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

Permalink | Reply | 0 comments |
headers
Dan Bunea | 1 Dec 2005 23:02
Picon

Re: Agile requirements

Hi Jim,

Thank you for a very good reading.

However I am a little bit confused about the balance between FIT automated  
customer tests and the normal unit/integration tests we write using TDD.

I and a friend of mine, decided to write a new piece of software.It will  
be a desktop application written in .net, aimed to help small business  
better manage their activities (sales), especially in conditions where  
he's very mobile (pda/laptop/smartphone). He's more of a business expert  
of this domain (but still a programmer), and I come with my programming  
expertise.

Now we are starting to gather the requirements. My usual way, the XP way  
is to plan the first relase first, by having a pile of user stories, then  
adding details to them as acceptance tests, more when the iteration is  
planned. However, writing FIT tests in fitnesse seems like a very nice  
thing to do, but what confuses us is what should be automated as  
unit/integration tests with NUnit/NMock and what should be automated as  
Fit tests?

For instance, obviously an application like this will have an order form,  
order will have a list of order details. My way would be to build the  
form, using TDD and the MVP pattern. At the same time, I think that I  
could construct a test as a fit table, them make an adapter, and build the  
part of the form to make the test pass, build a new one and so on until I  
have m order form constructed. Fit tests are much more visual, but a lot  
slower. What should I do? What should really be Fit tests and what NUnit?  
Where's the line?
(Continue reading)

Permalink | Reply | 19 comments |
headers
Jim Shore | 2 Dec 2005 04:50

Re: Fit and Unit Tests, how to go about it

Hi, Dadi,

Dadi Ingolfsson wrote:
> This method you use to structure your specifications/tests, as in parse.html
> in the Fit library, does it not feel a little bit cluttered and complex?
> What I mean is, I would have thought that you would put the HTML parsing
> tests into a test suite, like in FitNesse, and then have a test in there for
> each of the cases? [...]

I see your point and I would certainly do this if I felt I were writing 
tests.  In this case, though, the testing aspect, while still important, 
is secondary.

I'm more interested in providing a medium that's familiar to business 
experts so /they/ can write the examples.  I use Fit to automatically 
check the examples and provide feedback, yes... but I still think of 
them as examples rather than tests, written by business experts from 
their perspective, using tools and approaches that are familiar to them.

That's not to say that I put all of my Fit examples in a single 
document.  Even the Fit spec, which is relatively small, has four files. 
  I also use Word's automated 'table of contents' tool to provide a 
table of contents with links to various sections of the document.

Still, managing a large set of Fit documents is a problem with Word. 
FitNesse does a great job of providing some tools to allow you to manage 
the overall document structure.  If your business experts are 
comfortable with that approach, then by all means use it.

The main thing I would recommend is to be careful of doing things that
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jim Shore | 2 Dec 2005 05:01

Re: Agile requirements

Hi, Dan,

Dan Bunea wrote:
> However, writing FIT tests in fitnesse seems like a very nice  
> thing to do, but what confuses us is what should be automated as  
> unit/integration tests with NUnit/NMock and what should be automated as  
> Fit tests?

I would suggest using NUnit to test everything that you as programmers 
feel should be tested.  I don't see Fit as a testing tool.

I use Fit to provide examples of complicated requirements.  I don't try 
to test everything with Fit; I mainly just focus on examples of domain 
logic.  I only occasionally provide examples of UI interaction or data 
translation: as a rule of thumb, I don't do it unless the UI interaction 
  or data translation is complicated or Fit would facilitate discussion 
with non-programmers.

I see NUnit and Fit as being orthogonal.  They solve different problems 
and it's not that important that they both end up comparing 'expected' 
and 'actual' results.

What's complicated about the application you're building?  What's the 
"secret sauce"--the magic know-how that your application provides that 
no one else does?  Provide Fit examples of that.

I use TDD for everything, even if it has Fit examples too.  When I write 
my NUnit tests, I use different data than my Fit examples.  I TDD from a 
programming perspective... using data that reflects my knowledge of the 
program's edge cases, zero-one-many scenarios, etc.
(Continue reading)

Permalink | Reply | 17 comments |

Gmane