Simon Kirk a écrit :
> Hi Damien.

Hi Simon,

> I am very interested in this kind of thing, unfortunately my
> understanding and/or point of view is fashioned via experience rather
> than any particular papers/publications/code, but I'll plough on
> regardless :)


Experienced Smalltalkers have full of ideas and I'm glad to hear your 
opinion. Thank you for answering.

> Just to be clear on definition, by "workflow" I am thinking in terms of
> a developer's day-to-day development work (be that design, coding,
> writing of unit tests, whatever) and its integration with both a
> work/bug/whatever-tracking system and a source-control system.


Exactly


> A while ago I posted a rather large (and largely uninformed) email to
> the list about Monticello trying to get some answers up-front before I
> had ever used it in anger, with respect to integrating it into a model
> of developer workflow.
> 
> Too stop this turning into more of a tome then it already is, here's the
> gmane link to the email: http://shrunk.net/472063cf

This discussion is very interesting ("Squeak, source control, 
subversion, versioning, monticello, all that good stuff")

> In reply Avi came up with a suggestion of how to loosely (ie not
> restricted programmatically, just conventionally) model this workflow
> with Monticello here: http://shrunk.net/47742a1b (there were lots of
> other useful replies, sorry I can't quote them all).
> 
> These days I know MC much better - so I can understand his suggestion,
> and it's good. Of course, in an ideal world, the browser would
> provide a framework for the developer to support a workflow like this.
> This is where you guys step in :)


This is an interesting idea we could work on.


> [...]
> 2. The integration of other steps of workflow - in fact perhaps the
> three most important: Design, Unit test development (ie "up-front" TDD
> rather than "when there's time" testing), and code review.


We would like to work on this too.


> This coordinates interestingly with Agile methodoloies. In Scrum there
> needs to be a clearly defined value of "Done" for any bit of work, that
> ought to mean something like "well designed, cleanly coded, unit tested,
> refactored and peer code reviewed". Any tool that attempts to aid
> developer workflow would do well to aim to help a developer achieve this
> level of "doneness" in a well defined and repeatable manner.


I didn't know Scrum, thank you for this.


> A final note, regarding tools to aid code review: Cenqua are a company
> who write a very useful subversion/CVS analysis tool called Fisheye.
> They are also now in beta of a tool that integrates Fisheye with a code
> review framework called Crucible. It may be worth taking a look at that
> as an idea of how to model the code review part of developer workflow,
> as Cenqua traditionally (in my experience anyway) create well thought
> out and useful tools.
> 
> I meant this email as an open discussion of my ideas regarding developer
> workflow work, hence the length. I hope it can be of some use!


It is, thank you