Re: [epf-dev] No coding in Inception

["Scott W. Ambler" <swa@xxxxxxxxxxxx>]

Here's a few thoughts which support Mark's:
1. There's nothing stopping you from writing code.
2. Writing code is a good thing because it provides concrete feedback.
3. You want to do the right thing for your situation at hand.
4. Reducing the feedback cycle as much as possible is usually pretty good.

- Scott

On Wed, May 23, 2007 5:52 am, Mark.Dickson@xxxxxxxxx said:
> A couple of thoughts to throw into the pot.
> In the small team context with a project of 3-4 months, I would typically
> be looking at iterations of around 1 week for Inception and Elaboration;
> and 2 weeks for Construction & Transition. The motivation for this would
> be to generate urgency, momentum and confidence over a relatively short
> time frame.
> I would almost certainly be expecting to produce some software in
> Inception to demonstrate the feasibility of the solution. In RUP, this
> would be represented by the Architecture Proof of Concept, produced in
> Inception. The thing is that even though RUP identifies this product it is
> not (as far as I can tell) supported by explicit Implementation discipline
> tasks. It is a product of an Analysis & Design task performed solely by
> the Software Architect role.
> Earlier this year I proposed that we drop the Architecture PoC from
> OpenUP, reasoning that, as an optional product it didn't fit with
> OpenUP/Basic's minimal philosophy.
> Further, it is possible to view the PoC as simply an example of a Build.
> We can use the existing Development and Test content to produce an
> Inception phase CP to demonstrate the architecture.
> This approach would show that we are proving the architecture with working
> software early in the project.
>
> Cheers
> Mark
>
>
> Mark Dickson
> EAS Practice
> Xansa
> 0780 1917480
> *** sent from my blackberry ***
>
>
> ----- Original Message -----
> From: "Nate Oster" [noster@xxxxxxxxxxxxx]
> Sent: 05/22/2007 10:53 PM
> To: "Eclipse Process Framework Project Developers List"
> <epf-dev@xxxxxxxxxxx>
> Subject: RE: [epf-dev] No coding in Inception
>
> Jean,
>
> One thing that we're focused on articulating better as OpenUP/Basic
> approaches 1.0 is the "Dev Case" that it addresses "out of the box."  I
> mean, OpenUP/Basic is "minimal, extensible, _complete_," but that
> doesn't mean it's complete for all cases, or that it never needs
> tailoring before use.
>
> The idea is that OpenUP/Basic should be an executable unified process
> for small, collocated teams on relatively short engagements.  I was
> hearing 3-5 people, 3-4 months from the original committers, but always
> had trouble squaring that with the fact that we recommend four week
> iterations, and there's four phases, so unless we're planning one
> iteration per phase (!), that's 4 months right there.  I'm hoping we'll
> eventually settle on something like "5-8 people, 5-8 months."  The exact
> numbers don't matter as much as getting the idea across that we're
> talking small teams applying agile practices, ideally to architecturally
> significant problems, to quickly deliver working solutions.
>
> This needs to be explicit in the /basic process. (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=176199)
>
> Per your P.S., there are other disciplines that have *tasks* that are
> unused in Inception.  Test, for example, doesn't perform Implement Test
> Scripts or Run Tests during Inception, which is a bug that's closely
> related (https://bugs.eclipse.org/bugs/show_bug.cgi?id=187665).  I'd
> like OpenUP to acknowledge "if you've got code, you've got tests."
>
> I'm incline to avoid the "multiple CP" option that Ricardo mentions for
> a couple reasons, but mostly because it immediately introduces process
> tailoring into the Inception phase, and I think one of OpenUP/Basic's
> strengths is that you *can* extend it all you want (easily), but it's
> executable for small teams without tailoring.
>
> Thanks,
> Nate Oster
>
>
>
> -----Original Message-----
> From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Jean Pommier
> Sent: Tuesday, May 22, 2007 2:08 PM
> To: epf-dev@xxxxxxxxxxx
> Subject: [epf-dev] No coding in Inception
>
>
> I've been on the list for a few weeks now, so sorry if my reaction to
> this thread his missing enough context and OpenUP knowledge. Yet, since
> we leverage OpenUP in our company, I want to make sure we are not
> missing something around the Inception concept. We also met with Ricardo
> to assess our use of and contribution to OpenUP, hence the access to
> this -dev list.
>
> Bryan Lyons wrote:
>> We should discuss the absence of actual coding in the Inception phase
> of OpenUP
>> as demonstrated by the Inception Iteration capability pattern and then
> discuss
>> the notion that other parts of the process and method characterize the
> architecture
>> has had its feasibility "confirmed"... with no code.  This is an issue
> worthy of
>> discussion with broad participation by the OpenUP/Basic authors.
>
> - First, in our software business we meet prospects and customers either
> before they actually launched their project or after. We characterize
> the switch from Inception to Elaboration as the official Go/No Go
> decision. Within the Inception phase, project stakeholders may have to
> demonstrate some concepts and feasibility to get management buy in and,
> in the software context, that usually requires some actual modeling and
> coding (especially performance benchmarks).
>
> - Another thing is that, to my knowledge, RUP has some coding involved
> during the Inception phase (which again makes most sense to me).
> Therefore, following generalization principles, I don't see how OpenUP,
> which is more general as a foundation, couldn't include the idea of some
> coding during Inception. Doesn't mean that there is necessary coding
> involved in all situations, but it makes OpenUP more applicable to all
> cases by supporting the idea of some coding.
>
> - If the idea behind the previous statement is that a
> formal/theoretical/abstract method/approach (as opposed to pragmatic
> coding) should be used in Inception, then I think this reduces the
> usability and applicability of OpenUP to quite sophisiticated entities
> and companies, maybe not something we wish for.
>
> Again, sorry for the long post, hope I'm not too far off topic. In
> particular by overstating the Inception/Elaboration inflection point.
> Thanks for letting me know otherwise. As suggested by Bryan, looking
> forward to hearing back from the OpenUP/Basic authors anyway.
>
> Jean.
>
> PS: by curiosity, is there any other clear cut such as this one on other
> disciplines in the phases? I mean a discipline which would not be
> present in a certain phase. I thought there was at least "some" of each
> discipline in every iteration, some meaning a lot or a little depending
> on the phase. But at least some. Makes the process less directive, but
> more flexible and applicable.
>
> ---------------------------------------------------------------------
> Jean Pommier, Vice President Methodology, Corporate Quality Office
>
>
Practice Leader Agile Development, IBM Rational
http://www-306.ibm.com/software/rational/bios/ambler.html

Refactoring Databases (
http://www.ambysoft.com/books/refactoringDatabases.html ) is now
available.