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

Re: [XP] PONG and XP/Agile Development

Expand Messages
  • Steven Gordon
    In the context of teaching a course, an idea that can work well is to have at least two different projects that are roughly the same complexity (pong and
    Message 1 of 5 , Sep 16, 2012
    • 0 Attachment
      In the context of teaching a course, an idea that can work well is to have
      at least two different projects that are roughly the same complexity (pong
      and pacman or space invaders or ?) and have any student (or team)
      implementing one of the projects act as the customer for another student
      (or team) working on the other project.

      The customer is the one who creates the user stories, prioritizes them, and
      provides constructive feedback on the working software that is delivered
      each iteration (but not on the code!).

      This gives the students a feel for both sides and hopefully teaches how
      instrumental a good customer is to a project. It is more fun to be a
      customer than a PM any day.

      Steven Gordon

      On Sun, Sep 16, 2012 at 5:02 PM, Bill Wake <bill@...> wrote:

      > **
      >
      >
      > Since we're in the XP group, I'll describe that approach. (There are other
      > approaches; my company definitely uses a lighter approach than I describe
      > here.) You've already done the work of having some vision and goals for
      > what you're doing. If you're doing this solo, there will be some aspects
      > you miss.
      >
      > Initial planning
      > * Describe the key behaviors and qualities of what you want Pong to do. In
      > XP, these are called "user stories"; get some index cards & write one per
      > card. To get started, you don't have to describe every possible thing, but
      > there are some things you know are critical so begin there. I'll give you
      > one freebie, "System updates score when point is won". For basic Pong you
      > might start with a handful of stories, maybe half a dozen (not 1, not 25).
      > * Make an estimate for each story as if it were done in isolation. For a
      > little exercise like this, I'd probably estimate in raw hours.
      > * Make a decision about how long your iterations will be. Again, toy
      > project, maybe 2 or 3 hours.
      > * Make a "release" plan - doing the most important things earlier, schedule
      > stories into iterations.
      > * You may well find, now or later, that things don't fit well or they just
      > feel too big. Then you can practice splitting stories: divide a story into
      > a simpler version, and progressively fancier versions. Make sure you're
      > splitting so that each version is a useful thing on its own (not tasks that
      > don't add up to something deliverable only if you have them all). For
      > example: simple Pong might be a white square moving, fancier might have a
      > graphic ball, even fancier might have it spinning while it floats. The
      > first version is still a ball moving, so you're refining its qualities such
      > as curb appeal:)
      >
      > Iterations
      > * Plan each iteration as you go: pick the next set of stories from your
      > plan, break them down if needed, and implement. (Some will break into tasks
      > at this point but I'd rather keep them super-small stories.)
      > * For the first story, try to pick something that is the essence of the
      > system. Split it down as small as you can to start.
      > * To more fully understand these stories & agree when they're done, you
      > should consider "what tests would tell me I've done this story? Can I
      > automate them?" (You might find this described as "ATDD" or "BDD".)
      > * You'll need source control, some way to do unit tests, and an integration
      > approach that builds the software (if needed) and runs all existing tests.
      > * For the actual programming, look at "Test-Driven Development" and
      > "Refactoring". If you're working with another person, look at "Pair
      > Programming".
      > * Work one story at a time, implementing it fully before moving on to the
      > next.
      > * Stop when your iteration is done and assess your progress. (Resist the
      > temptation to expand the iteration if you're not done with everything you
      > wanted.)
      > * Adjust your plans to reflect your new understanding.
      > * Release when you've done the bare minimum to make a useful system, and
      > keep releasing. Again, for the small project, every iteration should be
      > shippable. (I'd try hard to include the first iteration in that.) Bigger
      > projects are all over the place: my company use a continuous deployment
      > approach that releases most every checkin; other projects can only release
      > once or a few times a year.
      > * Repeat
      >
      > If you need more background, you could start with Kent Beck's book Extreme
      > Programming Explained. For any of the topics, there are web pages, books,
      > e-learning (including my company, Industrial Logic's), training etc.
      >
      > Good luck!
      > Bill Wake
      >
      > On Sun, Sep 16, 2012 at 6:22 PM, adygould_work <adrian.j.gould@...
      > >wrote:
      >
      >
      > > Hi everyone
      > >
      > > I am a newcomer to agile methodologies and as a result would really
      > > appreciate some guidance in the form of a discussion and implementation
      > of
      > > the game of PONG using XP/Scrum/Agile techniques.
      > >
      > > Before I continue, let me tell you a little about myself and why I am
      > > asking this question...
      > >
      > > I am a lecturer in Information Technology/Multimedia/Games
      > Development/etc
      > > at a technical and further educaiton college (USA Community college) in
      > > Western Australia.
      > >
      > > One of the big problems we have had in the past is that students have
      > > found project management [PM] boring and many have simply refused to
      > > complete the work, with a result of not gaining a qualification.
      > >
      > > I have taught the introduction to traditional PM in the past (some 5 or 6
      > > years ago now), but in recent times the subject was taken by another
      > > lecturer.
      > >
      > > My reintroduction into the mix has meant that I've wanted to tackle this
      > > in a different manner, to inject some more relevant practices, and to
      > learn
      > > myself! [I've always said that lecturers and teachers learn most when
      > they
      > > teach new things to students. I know I certainly do!]
      > >
      > > My aim is to introduce one of Agile/Scrum/XP/blend of flavours of PM to
      > > the students so that they can see how PM can be interesting and
      > beneficial
      > > for small and medium projects yet alone big ones!
      > >
      > > We have a mix of games designers and developers, web developers and
      > > multimedia developers in our student horde.
      > >
      > > With the games developers/designers it would give them a way to push
      > > themselves to create a working prototype in a shorter time, especially as
      > > they need to get motivated and produce output.
      > >
      > > The web developers seem to be more motivated and tend to produce
      > > prototypes and working sites in a more reproductable manner.
      > >
      > > The idea of using PONG as a basis is that we know the game, but that does
      > > not mean it cannot be extended, and using the concept of continuous
      > > improvement it might just be a perfect platform to show how simple ideas
      > > can grow.
      > >
      > > I hope that this helps you understand where I am comng from...
      > >
      > > Anyway, back to PONG...
      > >
      > > We all know the way the game works, and I could easily write the code to
      > > play the game but that is not the point.
      > > I really want to understand the steps used to plan, write, test, release
      > > PONG.
      > >
      > > If any of you are willing to help, then I'd really appreciate... count me
      > > as a total newbie and start from the beginning...
      > > I have been doing some reading, but practical application will always
      > help.
      > >
      > > BTW - I have reasonable programming skills, and would be wanting to do
      > > this in JavaScript and HTML5 as a learning tool.
      > >
      > > Many thanks
      > >
      > > Ady
      > >
      > >
      > >
      > >
      > > ------------------------------------
      >
      > >
      > > To Post a message, send it to: extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to:
      > > extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      > --
      > Bill Wake Industrial Logic, Inc.
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >


      [Non-text portions of this message have been removed]
    • adygould_work
      Hi Steven thanks for that advice. I will have to use that next year, but I agree, it is a great concept... I ll need to make sure my colecturer also
      Message 2 of 5 , Sep 22, 2012
      • 0 Attachment
        Hi Steven

        thanks for that advice.
        I will have to use that next year, but I agree, it is a great concept...

        I'll need to make sure my colecturer also understands we need to do this, especially at Certificate IV level when they are learning the elements of PM and GD.

        Cheers

        Ady


        --- In extremeprogramming@yahoogroups.com, Steven Gordon <sgordonphd@...> wrote:
        >
        > In the context of teaching a course, an idea that can work well is to have
        > at least two different projects that are roughly the same complexity (pong
        > and pacman or space invaders or ?) and have any student (or team)
        > implementing one of the projects act as the customer for another student
        > (or team) working on the other project.
        >
        > The customer is the one who creates the user stories, prioritizes them, and
        > provides constructive feedback on the working software that is delivered
        > each iteration (but not on the code!).
        >
        > This gives the students a feel for both sides and hopefully teaches how
        > instrumental a good customer is to a project. It is more fun to be a
        > customer than a PM any day.
        >
        > Steven Gordon
        >
        > On Sun, Sep 16, 2012 at 5:02 PM, Bill Wake <bill@...> wrote:
        >
        > > **
        > >
        > >
        > > Since we're in the XP group, I'll describe that approach. (There are other
        > > approaches; my company definitely uses a lighter approach than I describe
        > > here.) You've already done the work of having some vision and goals for
        > > what you're doing. If you're doing this solo, there will be some aspects
        > > you miss.
        > >
        > > Initial planning
        > > * Describe the key behaviors and qualities of what you want Pong to do. In
        > > XP, these are called "user stories"; get some index cards & write one per
        > > card. To get started, you don't have to describe every possible thing, but
        > > there are some things you know are critical so begin there. I'll give you
        > > one freebie, "System updates score when point is won". For basic Pong you
        > > might start with a handful of stories, maybe half a dozen (not 1, not 25).
        > > * Make an estimate for each story as if it were done in isolation. For a
        > > little exercise like this, I'd probably estimate in raw hours.
        > > * Make a decision about how long your iterations will be. Again, toy
        > > project, maybe 2 or 3 hours.
        > > * Make a "release" plan - doing the most important things earlier, schedule
        > > stories into iterations.
        > > * You may well find, now or later, that things don't fit well or they just
        > > feel too big. Then you can practice splitting stories: divide a story into
        > > a simpler version, and progressively fancier versions. Make sure you're
        > > splitting so that each version is a useful thing on its own (not tasks that
        > > don't add up to something deliverable only if you have them all). For
        > > example: simple Pong might be a white square moving, fancier might have a
        > > graphic ball, even fancier might have it spinning while it floats. The
        > > first version is still a ball moving, so you're refining its qualities such
        > > as curb appeal:)
        > >
        > > Iterations
        > > * Plan each iteration as you go: pick the next set of stories from your
        > > plan, break them down if needed, and implement. (Some will break into tasks
        > > at this point but I'd rather keep them super-small stories.)
        > > * For the first story, try to pick something that is the essence of the
        > > system. Split it down as small as you can to start.
        > > * To more fully understand these stories & agree when they're done, you
        > > should consider "what tests would tell me I've done this story? Can I
        > > automate them?" (You might find this described as "ATDD" or "BDD".)
        > > * You'll need source control, some way to do unit tests, and an integration
        > > approach that builds the software (if needed) and runs all existing tests.
        > > * For the actual programming, look at "Test-Driven Development" and
        > > "Refactoring". If you're working with another person, look at "Pair
        > > Programming".
        > > * Work one story at a time, implementing it fully before moving on to the
        > > next.
        > > * Stop when your iteration is done and assess your progress. (Resist the
        > > temptation to expand the iteration if you're not done with everything you
        > > wanted.)
        > > * Adjust your plans to reflect your new understanding.
        > > * Release when you've done the bare minimum to make a useful system, and
        > > keep releasing. Again, for the small project, every iteration should be
        > > shippable. (I'd try hard to include the first iteration in that.) Bigger
        > > projects are all over the place: my company use a continuous deployment
        > > approach that releases most every checkin; other projects can only release
        > > once or a few times a year.
        > > * Repeat
        > >
        > > If you need more background, you could start with Kent Beck's book Extreme
        > > Programming Explained. For any of the topics, there are web pages, books,
        > > e-learning (including my company, Industrial Logic's), training etc.
        > >
        > > Good luck!
        > > Bill Wake
        > >
        > > On Sun, Sep 16, 2012 at 6:22 PM, adygould_work <adrian.j.gould@...
        > > >wrote:
        > >
        > >
        > > > Hi everyone
        > > >
        > > > I am a newcomer to agile methodologies and as a result would really
        > > > appreciate some guidance in the form of a discussion and implementation
        > > of
        > > > the game of PONG using XP/Scrum/Agile techniques.
        > > >
        > > > Before I continue, let me tell you a little about myself and why I am
        > > > asking this question...
        > > >
        > > > I am a lecturer in Information Technology/Multimedia/Games
        > > Development/etc
        > > > at a technical and further educaiton college (USA Community college) in
        > > > Western Australia.
        > > >
        > > > One of the big problems we have had in the past is that students have
        > > > found project management [PM] boring and many have simply refused to
        > > > complete the work, with a result of not gaining a qualification.
        > > >
        > > > I have taught the introduction to traditional PM in the past (some 5 or 6
        > > > years ago now), but in recent times the subject was taken by another
        > > > lecturer.
        > > >
        > > > My reintroduction into the mix has meant that I've wanted to tackle this
        > > > in a different manner, to inject some more relevant practices, and to
        > > learn
        > > > myself! [I've always said that lecturers and teachers learn most when
        > > they
        > > > teach new things to students. I know I certainly do!]
        > > >
        > > > My aim is to introduce one of Agile/Scrum/XP/blend of flavours of PM to
        > > > the students so that they can see how PM can be interesting and
        > > beneficial
        > > > for small and medium projects yet alone big ones!
        > > >
        > > > We have a mix of games designers and developers, web developers and
        > > > multimedia developers in our student horde.
        > > >
        > > > With the games developers/designers it would give them a way to push
        > > > themselves to create a working prototype in a shorter time, especially as
        > > > they need to get motivated and produce output.
        > > >
        > > > The web developers seem to be more motivated and tend to produce
        > > > prototypes and working sites in a more reproductable manner.
        > > >
        > > > The idea of using PONG as a basis is that we know the game, but that does
        > > > not mean it cannot be extended, and using the concept of continuous
        > > > improvement it might just be a perfect platform to show how simple ideas
        > > > can grow.
        > > >
        > > > I hope that this helps you understand where I am comng from...
        > > >
        > > > Anyway, back to PONG...
        > > >
        > > > We all know the way the game works, and I could easily write the code to
        > > > play the game but that is not the point.
        > > > I really want to understand the steps used to plan, write, test, release
        > > > PONG.
        > > >
        > > > If any of you are willing to help, then I'd really appreciate... count me
        > > > as a total newbie and start from the beginning...
        > > > I have been doing some reading, but practical application will always
        > > help.
        > > >
        > > > BTW - I have reasonable programming skills, and would be wanting to do
        > > > this in JavaScript and HTML5 as a learning tool.
        > > >
        > > > Many thanks
        > > >
        > > > Ady
        > > >
        > > >
        > > >
        > > >
        > > > ------------------------------------
        > >
        > > >
        > > > To Post a message, send it to: extremeprogramming@...
        > > >
        > > > To Unsubscribe, send a blank message to:
        > > > extremeprogramming-unsubscribe@...
        > > >
        > > > ad-free courtesy of objectmentor.comYahoo! Groups Links
        > > >
        > > >
        > > >
        > > >
        > >
        > > --
        > > Bill Wake Industrial Logic, Inc.
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        >
        >
        > [Non-text portions of this message have been removed]
        >
      • adygould_work
        Thanks Bill! a cool explanation of the elements of XP. I am finding that all the methods are very similar, just look at slightly diferent viewpoints in some
        Message 3 of 5 , Sep 22, 2012
        • 0 Attachment
          Thanks Bill!

          a cool explanation of the elements of XP.

          I am finding that all the methods are very similar, just look at slightly diferent viewpoints in some ways.

          One thing I do see though is the use of Test Driven Development, which I am finding my way through as well. That though, does seem to match my more web developer interests, but I am slowly seeing how it can be used in games development as well.

          On Thursday I went ahead and got the group of Certificate IV and Diploma students together, and gave them a back story to the same of "super pong". The idea was to get their imaginations going. Well it seemed to work for some of the students. I then asked them to create a series of user stories, purposely trying to get them to think about the big and small pictures.

          We ended up with quite a diverse series of stories, including some totally off the wall and totally out of place ones.

          The experience, I hope, will spark them into creating a series of user stories for their game ideas. Help them to think about what they want to be able to do in the game, from a player's point of view (pov), from the pov of the characters, and even from the pov of the hardware and supporting objects.

          I also got them to sort the ideas into versions of the game. Getting them to make version 1 simple and easier to implement, adding complexity as it went up the version history. This they did pretty successfully.

          I purposely got them to think of v1 as a 2d top down game. That way it gave them an implementable game before making it so hard that they never got anywhere.

          Next week we will sort these into smaller stories/sprints for version 1, and over the following few weeks implement it in JavaScript and quite probably in Unity as well.


          Does anyone want to see the user stories, the back story and the other breakdowns after this coming week is concluded??

          Maybe I should make the whole concept an open source project in the long run LOL!

          --- In extremeprogramming@yahoogroups.com, Bill Wake <bill@...> wrote:
          >
          > Since we're in the XP group, I'll describe that approach. (There are other
          > approaches; my company definitely uses a lighter approach than I describe
          > here.) You've already done the work of having some vision and goals for
          > what you're doing. If you're doing this solo, there will be some aspects
          > you miss.
          >
          > Initial planning
          > * Describe the key behaviors and qualities of what you want Pong to do. In
          > XP, these are called "user stories"; get some index cards & write one per
          > card. To get started, you don't have to describe every possible thing, but
          > there are some things you know are critical so begin there. I'll give you
          > one freebie, "System updates score when point is won". For basic Pong you
          > might start with a handful of stories, maybe half a dozen (not 1, not 25).
          > * Make an estimate for each story as if it were done in isolation. For a
          > little exercise like this, I'd probably estimate in raw hours.
          > * Make a decision about how long your iterations will be. Again, toy
          > project, maybe 2 or 3 hours.
          > * Make a "release" plan - doing the most important things earlier, schedule
          > stories into iterations.
          > * You may well find, now or later, that things don't fit well or they just
          > feel too big. Then you can practice splitting stories: divide a story into
          > a simpler version, and progressively fancier versions. Make sure you're
          > splitting so that each version is a useful thing on its own (not tasks that
          > don't add up to something deliverable only if you have them all). For
          > example: simple Pong might be a white square moving, fancier might have a
          > graphic ball, even fancier might have it spinning while it floats. The
          > first version is still a ball moving, so you're refining its qualities such
          > as curb appeal:)
          >
          > Iterations
          > * Plan each iteration as you go: pick the next set of stories from your
          > plan, break them down if needed, and implement. (Some will break into tasks
          > at this point but I'd rather keep them super-small stories.)
          > * For the first story, try to pick something that is the essence of the
          > system. Split it down as small as you can to start.
          > * To more fully understand these stories & agree when they're done, you
          > should consider "what tests would tell me I've done this story? Can I
          > automate them?" (You might find this described as "ATDD" or "BDD".)
          > * You'll need source control, some way to do unit tests, and an integration
          > approach that builds the software (if needed) and runs all existing tests.
          > * For the actual programming, look at "Test-Driven Development" and
          > "Refactoring". If you're working with another person, look at "Pair
          > Programming".
          > * Work one story at a time, implementing it fully before moving on to the
          > next.
          > * Stop when your iteration is done and assess your progress. (Resist the
          > temptation to expand the iteration if you're not done with everything you
          > wanted.)
          > * Adjust your plans to reflect your new understanding.
          > * Release when you've done the bare minimum to make a useful system, and
          > keep releasing. Again, for the small project, every iteration should be
          > shippable. (I'd try hard to include the first iteration in that.) Bigger
          > projects are all over the place: my company use a continuous deployment
          > approach that releases most every checkin; other projects can only release
          > once or a few times a year.
          > * Repeat
          >
          > If you need more background, you could start with Kent Beck's book Extreme
          > Programming Explained. For any of the topics, there are web pages, books,
          > e-learning (including my company, Industrial Logic's), training etc.
          >
          > Good luck!
          > Bill Wake
          >
          > On Sun, Sep 16, 2012 at 6:22 PM, adygould_work <adrian.j.gould@...>wrote:
          >
          > > Hi everyone
          > >
          > > I am a newcomer to agile methodologies and as a result would really
          > > appreciate some guidance in the form of a discussion and implementation of
          > > the game of PONG using XP/Scrum/Agile techniques.
          > >
          > > Before I continue, let me tell you a little about myself and why I am
          > > asking this question...
          > >
          > > I am a lecturer in Information Technology/Multimedia/Games Development/etc
          > > at a technical and further educaiton college (USA Community college) in
          > > Western Australia.
          > >
          > > One of the big problems we have had in the past is that students have
          > > found project management [PM] boring and many have simply refused to
          > > complete the work, with a result of not gaining a qualification.
          > >
          > > I have taught the introduction to traditional PM in the past (some 5 or 6
          > > years ago now), but in recent times the subject was taken by another
          > > lecturer.
          > >
          > > My reintroduction into the mix has meant that I've wanted to tackle this
          > > in a different manner, to inject some more relevant practices, and to learn
          > > myself! [I've always said that lecturers and teachers learn most when they
          > > teach new things to students. I know I certainly do!]
          > >
          > > My aim is to introduce one of Agile/Scrum/XP/blend of flavours of PM to
          > > the students so that they can see how PM can be interesting and beneficial
          > > for small and medium projects yet alone big ones!
          > >
          > > We have a mix of games designers and developers, web developers and
          > > multimedia developers in our student horde.
          > >
          > > With the games developers/designers it would give them a way to push
          > > themselves to create a working prototype in a shorter time, especially as
          > > they need to get motivated and produce output.
          > >
          > > The web developers seem to be more motivated and tend to produce
          > > prototypes and working sites in a more reproductable manner.
          > >
          > > The idea of using PONG as a basis is that we know the game, but that does
          > > not mean it cannot be extended, and using the concept of continuous
          > > improvement it might just be a perfect platform to show how simple ideas
          > > can grow.
          > >
          > > I hope that this helps you understand where I am comng from...
          > >
          > > Anyway, back to PONG...
          > >
          > > We all know the way the game works, and I could easily write the code to
          > > play the game but that is not the point.
          > > I really want to understand the steps used to plan, write, test, release
          > > PONG.
          > >
          > > If any of you are willing to help, then I'd really appreciate... count me
          > > as a total newbie and start from the beginning...
          > > I have been doing some reading, but practical application will always help.
          > >
          > > BTW - I have reasonable programming skills, and would be wanting to do
          > > this in JavaScript and HTML5 as a learning tool.
          > >
          > > Many thanks
          > >
          > > Ady
          > >
          > >
          > >
          > >
          > > ------------------------------------
          > >
          > > To Post a message, send it to: extremeprogramming@...
          > >
          > > To Unsubscribe, send a blank message to:
          > > extremeprogramming-unsubscribe@...
          > >
          > > ad-free courtesy of objectmentor.comYahoo! Groups Links
          > >
          > >
          > >
          > >
          >
          >
          > --
          > Bill Wake Industrial Logic, Inc.
          >
          >
          > [Non-text portions of this message have been removed]
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.