Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] Re: Don't Split A Story Into Tasks

Expand Messages
  • Phil Goodwin
    Dang. I wish I d written this. Phil
    Message 1 of 89 , Mar 21, 2009
    • 0 Attachment
      Dang. I wish I'd written this.

      Phil
      <EOM>

      On Sat, Mar 21, 2009 at 9:11 AM, Ron Jeffries <ronjeffries@...> wrote:
      > Hello, Roy.
      >
      > I'm going to take you at your word about being perplexed, and see
      > whether I can illuminate the difference between two views, one of
      > which I take to be yours, and one of which I take to be, well, mine.
      > But I think it'll turn out to be George's too.
      >
      > What I say about "your view" will be my understanding of what you've
      > said, and may be at the root of our difficulties if I have it wrong.
      > I'll not go back for quotes to "justify" my understanding, just
      > express what I've come to think you're saying.
      >
      > On Saturday, March 21, 2009, at 10:48:49 AM, you wrote:
      >
      >> I still cannot see how knowing about 'Student' and doing that in
      >> a modelling cycle as I described, somehow is a wrong, irrelevant,
      >> or least-benefit place to start, or that the process is somehow
      >> too restrictive for discovering requirements.
      >
      > You've spoken of knowing "all about students", as if that were
      > something to be done ab initio. (You've also spoken about doing
      > things incrementally, I freely grant, but what I "got" was that
      > you'd ER a lot of Student, up front. Now ... ER isn't all that hard
      > to do and can be done on the back of an envelope etc. But it is not
      > all that hard to OVER-do either. More on the comparison below.
      >
      >> I am developing a Student Information System (as is the example).
      >> I have spent some time identifying Users and interviewing them, to
      >> compile a starting Product Backlog. This is NOT a BDUF effort, but
      >> you gotta start somewhere. The User Stories that I have gathered
      >> have indicated in various ways that there is this thing called
      >> Student that is of interest to me. 'Student' is actually two
      >> things; an actor in their own right, and an entity of interest. I
      >> have User Stories from students about their needs of the system,
      >> and I have many references to 'student' in other User stories from
      >> other users.
      >
      > OK. Stories. Good.
      >
      >> There can be no doubt that in a Student Information
      >> System, with a number of User Stories identifying this thing
      >> called Student, and having a User who is a student, that we must
      >> store data about Student. I frankly cannot see why there would be
      >> any argument about the need to store 'student' data persistently.
      >
      > I could imagine an app such that we didn't have to, but that's not
      > our point. I believe the app will store data about Student. I'm sure
      > George does, as well.
      >
      > But we don't need an ER design. We have done no code, no story.
      > Therefore there is no need to store a student NOW ... and therefore
      > no need to know much about doing it.
      >
      >> The only argument or discussion may be the manner of storing it;
      >> relationally, XML, in an OO database, locally, on the network,
      >> somewhere out there in Internet land ... etc.
      >
      > Again, could quibble. But won't.
      >
      >> So, we have identified the entity Student. Or the Class 'Student',
      >> depending on your terminology. We know, without any doubt, I
      >> think, that we will need to know about Students (what is it? what
      >> do we want to know about it? etc.). So we go through a development
      >> cycle based on 'Student' only. If we are going to store data
      >> (however stored) we quite implicitly have a need for those data
      >> maintenance and manipulation processes. Part of my entity analysis
      >> is entity lifecycle analysis (arrival, departure, lifetime
      >> activities) from a business point of view. These transform into
      >> computer processes, database schema design decisions, referential
      >> integrity constraints ... about Student. ANy other entities and
      >> relationships that we identify will be dealt with later, or
      >> otherwise.
      >
      > Yes, we know all that.
      >
      >> What you, and others, seem to be suggesting is that I am blinkered
      >> in my thinking by identifying that we need to know about
      >> 'student', that we are in fact setting out from the start to
      >> develop a database system with the persistent storage of certain
      >> data -to be fully identified and defined during the development
      >> process, and that making a preemptive assumption that if we need
      >> to store data persistently (a given in the situation) then we need
      >> to have data processing, is restricting my outcomes and my design
      >> decisions.
      >
      > I am saying: Your design decisions, if you draw an ER diagram, are
      > premature. You don't need that design yet. It could be deferred. The
      > principles I follow are that I will defer such things. I think that
      > is a principle in Agile and Lean ... late binding of decisions.
      >
      >> For example, you say that I am prempting the 'goal' by this way of
      >> thinking. I can't see that. My project task is to develop a system
      >> called 'Student Information System'. That is, information about
      >> students and the variety of other information that is to be
      >> discovered during the project activity. That is my goal! All I
      >> need now is an appropriate process to achieve this goal in as
      >> efficient and effective manner as possible. What other goal can
      >> there be when that is the quite specific purpose of the mandate to
      >> develop the system?
      >
      > I would suggest that your goal might be to take the most important
      > story which you gleaned from the stakeholders, and implement it.
      >
      > That story may well require storage of some data. It may not. I'll
      > give an example of the latter, then the former.
      >
      > No Storage:
      >
      > As Provost for the Blind, I want the SIS to be usable by blind
      > students and faculty, so that their access will be as facile as
      > that possible by sighted individuals, as shown by a human factors
      > comparison.
      >
      > If this is the first, therefore most important story, we need no
      > data storage at all. We need UX expertise and a human factors
      > experiment. Any work on the database is definitely premature.
      >
      > Storage:
      >
      > As Treasurer, I want to send dunning notices to all students who
      > owe the university money, so that we can stay in business. This
      > will be shown by the ability to produce a printed letter to the
      > student, at his or her home address, including text I'll provide
      > and the amount due.
      >
      > If this is the first, we need some data storage. In particular we
      > need, roughly, student ID, name, address, amount owed. And that is
      > all we need.
      >
      > Because of the long time involved in getting all that data into the
      > computer, the above story is too large to fit an iteration. It
      > probably needs to be recast to something like "dunning notices to
      > [these twenty] students".
      >
      > I could, and would, implement that story against a flat file, or
      > perhaps even against a fixed internal list of students.
      >
      >> Sorry, I can't see it. Now, I am sure that you, and Adam, and Ron,
      >> and others are highly experienced and knowledgeable practitioners
      >> and even theorists, so I can't dismiss what you say as irrelevant
      >> or ill informed. So this is my problem. I too am a highly
      >> experienced and knowledgeable practitioner with a long history of
      >> 'alternative' thinking (alternative to the conventional wisdoms
      >> published, taught and practiced for yonks). So I am ... perplexed.
      >
      > I believe that's because you keep arguing for your position instead
      > of exploring ours. We have not explored yours ... but our excuse is
      > perhaps slightly better because we have encountered positions that
      > sounded similar so often before ... and they were never correct.
      >
      > Nonetheless, I'm setting forth here what I hope will delineate the
      > difference in our view, and your view as we perceive it:
      >
      > US (Agile)
      >
      > We would not design or build a bit of database until we had enough
      > stories to warrant it, and perhaps not even then. We would not
      > theorize about the ER or relational or object structure: we would
      > let the stories that come up tell us what the design is, and we
      > would learn it, and implement it, incrementally.
      >
      > YOU
      >
      > (We think) you are saying that we know there will be a database and
      > therefore it is OK to design it. We do not agree. We think you will
      > then say that since there will be a database and we have a design
      > for it, we should start building it. If so, we would not agree. We
      > think you will want to build stories, starting from the beginning,
      > against the database. If so, we would not agree.
      >
      >> However, is it appropriate to continue this discussion as we have
      >> proceeded so far? If it is helpful and interesting to others, then
      >> fine, let's continue (although I can't see much more or different
      >> that can be said). If not, let's let it rest now.
      >
      > Do you agree that what I've written fairly characterizes our two
      > views? If it's not fair to yours, please say in similar terms to the
      > above what yours is. If you have not perceived ours to be as I've
      > said, and still don't, please say in similar terms what it is that
      > you think we are saying. (However, I'm saying what I just did, and I
      > expect rather a lot of support from George.)
      >
      > Ron Jeffries
      > www.XProgramming.com
      > www.xprogramming.com/blog
      > Attend our CSM Plus Course!
      > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
      > Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
      >
      >
    • Phil Goodwin
      Dang. I wish I d written this. Phil
      Message 89 of 89 , Mar 21, 2009
      • 0 Attachment
        Dang. I wish I'd written this.

        Phil
        <EOM>

        On Sat, Mar 21, 2009 at 9:11 AM, Ron Jeffries <ronjeffries@...> wrote:
        > Hello, Roy.
        >
        > I'm going to take you at your word about being perplexed, and see
        > whether I can illuminate the difference between two views, one of
        > which I take to be yours, and one of which I take to be, well, mine.
        > But I think it'll turn out to be George's too.
        >
        > What I say about "your view" will be my understanding of what you've
        > said, and may be at the root of our difficulties if I have it wrong.
        > I'll not go back for quotes to "justify" my understanding, just
        > express what I've come to think you're saying.
        >
        > On Saturday, March 21, 2009, at 10:48:49 AM, you wrote:
        >
        >> I still cannot see how knowing about 'Student' and doing that in
        >> a modelling cycle as I described, somehow is a wrong, irrelevant,
        >> or least-benefit place to start, or that the process is somehow
        >> too restrictive for discovering requirements.
        >
        > You've spoken of knowing "all about students", as if that were
        > something to be done ab initio. (You've also spoken about doing
        > things incrementally, I freely grant, but what I "got" was that
        > you'd ER a lot of Student, up front. Now ... ER isn't all that hard
        > to do and can be done on the back of an envelope etc. But it is not
        > all that hard to OVER-do either. More on the comparison below.
        >
        >> I am developing a Student Information System (as is the example).
        >> I have spent some time identifying Users and interviewing them, to
        >> compile a starting Product Backlog. This is NOT a BDUF effort, but
        >> you gotta start somewhere. The User Stories that I have gathered
        >> have indicated in various ways that there is this thing called
        >> Student that is of interest to me. 'Student' is actually two
        >> things; an actor in their own right, and an entity of interest. I
        >> have User Stories from students about their needs of the system,
        >> and I have many references to 'student' in other User stories from
        >> other users.
        >
        > OK. Stories. Good.
        >
        >> There can be no doubt that in a Student Information
        >> System, with a number of User Stories identifying this thing
        >> called Student, and having a User who is a student, that we must
        >> store data about Student. I frankly cannot see why there would be
        >> any argument about the need to store 'student' data persistently.
        >
        > I could imagine an app such that we didn't have to, but that's not
        > our point. I believe the app will store data about Student. I'm sure
        > George does, as well.
        >
        > But we don't need an ER design. We have done no code, no story.
        > Therefore there is no need to store a student NOW ... and therefore
        > no need to know much about doing it.
        >
        >> The only argument or discussion may be the manner of storing it;
        >> relationally, XML, in an OO database, locally, on the network,
        >> somewhere out there in Internet land ... etc.
        >
        > Again, could quibble. But won't.
        >
        >> So, we have identified the entity Student. Or the Class 'Student',
        >> depending on your terminology. We know, without any doubt, I
        >> think, that we will need to know about Students (what is it? what
        >> do we want to know about it? etc.). So we go through a development
        >> cycle based on 'Student' only. If we are going to store data
        >> (however stored) we quite implicitly have a need for those data
        >> maintenance and manipulation processes. Part of my entity analysis
        >> is entity lifecycle analysis (arrival, departure, lifetime
        >> activities) from a business point of view. These transform into
        >> computer processes, database schema design decisions, referential
        >> integrity constraints ... about Student. ANy other entities and
        >> relationships that we identify will be dealt with later, or
        >> otherwise.
        >
        > Yes, we know all that.
        >
        >> What you, and others, seem to be suggesting is that I am blinkered
        >> in my thinking by identifying that we need to know about
        >> 'student', that we are in fact setting out from the start to
        >> develop a database system with the persistent storage of certain
        >> data -to be fully identified and defined during the development
        >> process, and that making a preemptive assumption that if we need
        >> to store data persistently (a given in the situation) then we need
        >> to have data processing, is restricting my outcomes and my design
        >> decisions.
        >
        > I am saying: Your design decisions, if you draw an ER diagram, are
        > premature. You don't need that design yet. It could be deferred. The
        > principles I follow are that I will defer such things. I think that
        > is a principle in Agile and Lean ... late binding of decisions.
        >
        >> For example, you say that I am prempting the 'goal' by this way of
        >> thinking. I can't see that. My project task is to develop a system
        >> called 'Student Information System'. That is, information about
        >> students and the variety of other information that is to be
        >> discovered during the project activity. That is my goal! All I
        >> need now is an appropriate process to achieve this goal in as
        >> efficient and effective manner as possible. What other goal can
        >> there be when that is the quite specific purpose of the mandate to
        >> develop the system?
        >
        > I would suggest that your goal might be to take the most important
        > story which you gleaned from the stakeholders, and implement it.
        >
        > That story may well require storage of some data. It may not. I'll
        > give an example of the latter, then the former.
        >
        > No Storage:
        >
        > As Provost for the Blind, I want the SIS to be usable by blind
        > students and faculty, so that their access will be as facile as
        > that possible by sighted individuals, as shown by a human factors
        > comparison.
        >
        > If this is the first, therefore most important story, we need no
        > data storage at all. We need UX expertise and a human factors
        > experiment. Any work on the database is definitely premature.
        >
        > Storage:
        >
        > As Treasurer, I want to send dunning notices to all students who
        > owe the university money, so that we can stay in business. This
        > will be shown by the ability to produce a printed letter to the
        > student, at his or her home address, including text I'll provide
        > and the amount due.
        >
        > If this is the first, we need some data storage. In particular we
        > need, roughly, student ID, name, address, amount owed. And that is
        > all we need.
        >
        > Because of the long time involved in getting all that data into the
        > computer, the above story is too large to fit an iteration. It
        > probably needs to be recast to something like "dunning notices to
        > [these twenty] students".
        >
        > I could, and would, implement that story against a flat file, or
        > perhaps even against a fixed internal list of students.
        >
        >> Sorry, I can't see it. Now, I am sure that you, and Adam, and Ron,
        >> and others are highly experienced and knowledgeable practitioners
        >> and even theorists, so I can't dismiss what you say as irrelevant
        >> or ill informed. So this is my problem. I too am a highly
        >> experienced and knowledgeable practitioner with a long history of
        >> 'alternative' thinking (alternative to the conventional wisdoms
        >> published, taught and practiced for yonks). So I am ... perplexed.
        >
        > I believe that's because you keep arguing for your position instead
        > of exploring ours. We have not explored yours ... but our excuse is
        > perhaps slightly better because we have encountered positions that
        > sounded similar so often before ... and they were never correct.
        >
        > Nonetheless, I'm setting forth here what I hope will delineate the
        > difference in our view, and your view as we perceive it:
        >
        > US (Agile)
        >
        > We would not design or build a bit of database until we had enough
        > stories to warrant it, and perhaps not even then. We would not
        > theorize about the ER or relational or object structure: we would
        > let the stories that come up tell us what the design is, and we
        > would learn it, and implement it, incrementally.
        >
        > YOU
        >
        > (We think) you are saying that we know there will be a database and
        > therefore it is OK to design it. We do not agree. We think you will
        > then say that since there will be a database and we have a design
        > for it, we should start building it. If so, we would not agree. We
        > think you will want to build stories, starting from the beginning,
        > against the database. If so, we would not agree.
        >
        >> However, is it appropriate to continue this discussion as we have
        >> proceeded so far? If it is helpful and interesting to others, then
        >> fine, let's continue (although I can't see much more or different
        >> that can be said). If not, let's let it rest now.
        >
        > Do you agree that what I've written fairly characterizes our two
        > views? If it's not fair to yours, please say in similar terms to the
        > above what yours is. If you have not perceived ours to be as I've
        > said, and still don't, please say in similar terms what it is that
        > you think we are saying. (However, I'm saying what I just did, and I
        > expect rather a lot of support from George.)
        >
        > Ron Jeffries
        > www.XProgramming.com
        > www.xprogramming.com/blog
        > Attend our CSM Plus Course!
        > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
        > Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.