modelfirst.html

极限编程 Extream Programing

<hr>
<p>
<em>we are told we need to pay more attention to the user's perspective</em>
<p>
<p>
<p>
This does not contradict <a href="ModelFirst.html">ModelFirst</a>. The balance to be struck is that the &quot;right&quot; system to develop results from a dialog between what is easy or hard to develop (the developer's perspective) and what is valuable or useless to develop (the client's perspective). And you can't know either dimension perfectly before you start. Worse, the act of developing changes both dimensions. As developers get experience, what was hard may become easy (or impossible). As clients get experience, what seemed valuable may be seen as worthless, and vice versa.
<p>
<p>
<p>
I think Ward calls this &quot;matching the desirable with the possible&quot;.
<p>
<p>
<p>
<a href="ModelFirst.html">ModelFirst</a> in conjunction with <a href="ExtremePlanning.html">ExtremePlanning</a> concentrates on getting the most valuable stuff done first and in refining the metaphor and software design early, while there isn't a load of <a href="http://c2.com/cgi/wiki?UserInterfaceInertia">UserInterfaceInertia</a> slowing evolution.
<p>
<p>
<p>
--<a href="KentBeck.html">KentBeck</a>
<p>
<p>
<p>
I have trouble visualizing a team doing <a href="ModelFirst.html">ModelFirst</a> in the early stages of a project if they follow <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>. Would a customer ever be satisfied with &quot;OK, the system can do X as you asked but you can't really *see* it doing X right now&quot;? Specifically, I want to know how XP manages to do <a href="ModelFirst.html">ModelFirst</a> and still satisfy their <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>. -- <a href="http://c2.com/cgi/wiki?PieterNagel">PieterNagel</a>
<p>
<p>
<p>
The user stories are turned into <a href="FunctionalTests.html">FunctionalTests</a>.  The customers see the tests run. --<a href="DonWells.html">DonWells</a>
<p>
<p>
<p>
There should not be a conflict between <a href="ModelFirst.html">ModelFirst</a> and <a href="http://c2.com/cgi/wiki?UserStories">UserStories</a>.  CRC cards are driven from stories.  If you don't have a story, you can't CRC card. So you work on the stories you have.  The CRC cards don't particularly care about the GUI, they care about partitioning of the object model, discovery and evaluation of the classes.  So the cards represent the model, not the UI.  ergo.  --<a href="http://c2.com/cgi/wiki?AlistairCockburn">AlistairCockburn</a>
<p>
<p>
<p>
My problem is with that, to me, <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> implies *Use*. I envision the user saying &quot;I want to keep track of my outstanding orders&quot;. So now you go and enhance the &quot;Order&quot; model, but without a GUI you can only tell the client: &quot;Yup, the *system* can keep track of the orders, and we can prove it by running dummy orders from a text file, but until we have a GUI we can't prove to you that *you* can actually *use* the system to keep track of orders.&quot;
<p>
<p>
<p>
See where I'm coming from? Unless clients are particularly smart, they might not see <a href="ModelFirst.html">ModelFirst</a> as having satisfied any <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> yet. -- <a href="http://c2.com/cgi/wiki?PieterNagel">PieterNagel</a>
<p>
<p>
<p>
Perhaps the problem is with your conception of <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a>'s. I can't imagine estimating a story like &quot;keep track of orders&quot;. By the time this story got into the schedule it would be turned into one or more much more specific stories, each of which would more likely to be coverable by <a href="http://c2.com/cgi/wiki?FunctionalTest">FunctionalTest</a>'s. --<a href="KentBeck.html">KentBeck</a>
<p>
<hr>
<p>
Thinking in terms of &quot;proof&quot; is a good start. Remember that if you have a GUI, it might prove on Monday that the system works, but how will they prove it again on Friday? Pretty soon you're buying GUI testing tools and trying to record clicks and develop coverage tests all through the GUI. This is nearly impossible. So how can you REALLY prove, week in and week out, that the old stuff works and the new stuff has started to work? Once you get the answer to that question, you also have the answer to the question of why you can wait for most GUIs.
<p>
However, there are usability issues that do need addressing, and I've seen that when you train users and developers to be GUI-shy, there's some relearning to do when you finally get around to doing more than the rudimentary GUIs to keep things going. Also, remember that doing things in Inspectors is not as efficient for anyone as having a GUI. So there's trading off to be done. Many more projects do too much GUI than too little. That's why we push so hard on the &quot;do less&quot; side.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
<hr>
<p>
<em>My problem is with that, to me, <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> implies *Use*. I envision the user saying &quot;I want to keep track of my outstanding orders&quot;. So now you go and enhance the &quot;Order&quot; model, but without a GUI you can only tell the client: &quot;Yup, the *system* can keep track of the orders, and we can prove it by running dummy orders from a text file, but until we have a GUI we can't prove to you that *you* can actually *use* the system to keep track of orders.&quot;</em>'
<p>
But it's easier to tell a user that the guts of the application work it's just that you can't easily get at them yet than it is to explain that although the user interface is apparently everything they wanted that half of it doesn't work, or worse, doesn't work properly. -- John Burton
<p>
<hr>
<em>My problem is with that, to me, <a href="http://c2.com/cgi/wiki?UserStory">UserStory</a> implies *Use*. </em>
<p>
See <a href="http://c2.com/cgi/wiki?UserStoryExamples">UserStoryExamples</a> for some stories that are quite important but don't smack much of *Use*.
<p>
If the system is all GUI: enter an order, display an order, total the orders, with no real model underneath, the GUI may be necessary to see whether it works. On the other hand, if the system is like payroll or clearing Visa charges or calculating the cost of a car from its parts, it's your <a href="FunctionalTests.html">FunctionalTests</a> that really tell whether or not it works.  --<a href="RonJeffries.html">RonJeffries</a>
<p>
I have trouble with the distinction here-- If you describe a segment of the Corporate Sales Process as &quot;enter,display,total orders&quot;, I can describe a segment of the Corporate Payroll Process as something like &quot;enter, display, and total employee payments&quot;, no?  --<a href="http://c2.com/cgi/wiki?JohnClonts">JohnClonts</a>
<p>
The distinction is between processes with very high computational complexity (such as payroll) and processes with simple computation and lots of display, like adding up a bunch of orders. No insult to your corporate sales process intended.
<p>
I see, &quot;The other guy's domain is always simpler&quot; :)
<p>
<hr>
<p>
I'm trying to get into extreme programming, but instead of user-stories, I've been given prototypes of the GUI (done in photoshop). Looking at these six mocked-up windows, I've come up with more than 40 user stories. 
<p>
Maybe my stories are too small -- for example, a story, &quot;convert remotely-scanned image to black and white&quot;, corresponds to a popup menu in dialog dealing with network scanning. Another story is &quot;when user drags a rectangle on the image preview, add an entry to the scrolling-list of selections&quot;.
<p>
While I will do the model first (actually test first, model second, gui third), I would not consider the story completely implemented until the user can click that pop-up menu in that dialog and get the color image saved as a black and white file. -- <a href="http://c2.com/cgi/wiki?KeithRay">KeithRay</a>
<hr>
I do believe this page is confused.  It seems the phrase <em>the model</em> is used to mean an underlying business or computational model of the data that is distinct from direct user interaction.  This sends me in a couple of directions.
<p>
1. You can't possibly know what the computational model is unless you already understand the semantics of the user interaction.  For example, when the user says &quot;I want the system to keep track of...&quot;, your analysis of interaction is incomplete.  In this case, the user is doing your design for you.  You need to ask how and when this stuff being &quot;kept track of&quot; will be of interest in the future.  That leads to the discovery of new interaction semantics.  If the data won't be used in the future, there's no need to store it, or to worry about data models for doing so.  If the data will be used with other data in esoteric computations to yield results interesting to the Users, then someone has to be able to describe the semantics of those computations for you to build it, even if they cannot construct the formulae from memory.
<p>
2. In evolutionary development especially, there are Users and there are &quot;users&quot;.  The Users are the people who will interact with the new system.  The &quot;users&quot; are the older parts of the system that will interact with the new system.  From the perspective of those developing the new system, both of these users are significant in that they are problem context givens.  This fact gives rise to the new observation that sometimes part or all of your data and business models already exist in the older parts of the system, and their presence exerts influence back through the development process to the Users to accomodate the system as it is, rather than correct those parts that actually conflict with new requirements.  If you have an existing implementation, but no way to convey to your new Users what it does, then it could be time to develop some model of that to communicate existing semantics to your Users.  Or a simple verbal description might do as well.
<p>
--<a href="http://c2.com/cgi/wiki?WaldenMathews">WaldenMathews</a> (did I miss the window of interest in this topic?)
<p>
<hr>
<a href="http://c2.com/cgi/wiki?CategoryAnalysis">CategoryAnalysis</a>
<hr>
<a href="http://c2.com/cgi/wiki?edit=ModelFirst">EditText</a> of this page (last edited December 29, 2000)<br>
<a href="http://c2.com/cgi/wiki?FindPage&value=ModelFirst">FindPage</a> by browsing or searching<p>
<font color=gray size=-1>This page mirrored in <a href="index.html">ExtremeProgrammingRoadmap</a> as of March 31, 2001</font>
</body>