Hi everyone, I'm interested in hearing some strategies that I can use for foster good planning on the part of students in my classes. We're just starting our latest project (http://www.isd197.org/sibley/cs/icp/assignments/portfolio_html) and I'm going to have them working in teams of four (a pair of programming pairs). Do you have a formal way of encouraging (enforcing?) a planning process? Does anyone use UML when they get to OOP? (We're not quite there yet.) -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson@visi.com | <dtml-var pithy_quote> | http://linux.com
Timothy Wilson wrote:
Do you have a formal way of encouraging (enforcing?) a planning process?
I would encourage a lightweight planning process, such as writing up a bunch of index cards with tasks and then ordering the index cards according to when tasks should be completed.
Great idea, Steve. Using cards is nice and simple. And it is a great way to introduce ideas like "use cases" or "user stories". Here are some references to the usage of cards in the Extreme Programming community: XP Roadmap (intro): http://c2.com/cgi/wiki?ExtremeProgramming Card-specific: http://c2.com/cgi/wiki?WriteItOnaCard User stories: http://c2.com/cgi/wiki?UserStory Also, Timothy, going so far as to actually enforce a planning process would probably backfire. There are intrinsic rewards to various degrees of planning (better code, less frustrating debugging, potential for rapid adaptability to changing customer requirements), but they are not always obvious, especially to beginners. Explicitly *rewarding* ("bonus points") individuals and teams that plan (and plan well) might help ingrain the practice. Up front reward for investing the energy in planning coupled with deferred reward as their projects run with more features and less debugging, yes, I think that might do it. :-) Cheers, Jason -----Original Message----- From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On Behalf Of Steve Howell Sent: Wednesday, December 12, 2001 9:20 AM To: Timothy Wilson Cc: Python-Edu SIG Subject: Re: [Edu-sig] Encouraging students to plan effectively Timothy Wilson wrote:
Do you have a formal way of encouraging (enforcing?) a planning process?
I would encourage a lightweight planning process, such as writing up a bunch of index cards with tasks and then ordering the index cards according to when tasks should be completed. _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
"Jason L. Asbahr" wrote:
[...] Also, Timothy, going so far as to actually enforce a planning process would probably backfire. There are intrinsic rewards to various degrees of planning (better code, less frustrating debugging, potential for rapid adaptability to changing customer requirements), but they are not always obvious, especially to beginners.
Explicitly *rewarding* ("bonus points") individuals and teams that plan (and plan well) might help ingrain the practice. Up front reward for investing the energy in planning coupled with deferred reward as their projects run with more features and less debugging, yes, I think that might do it. :-)
Good points. If you have a planning process based on index cards, you can create a tangible reward system for the planning process. After each task is finished, you get to move it from the to-do pile to the done pile. This gets very addictive, even for adults! I've visited a couple real-world programming shops that do Extreme Programming, and they have bulletin boards where they put the cards up, and as the cards get completed, they move the cards to the "done" area of the bulletin board.
On Wed, 12 Dec 2001, Jason L. Asbahr wrote:
Great idea, Steve. Using cards is nice and simple. And it is a great way to introduce ideas like "use cases" or "user stories".
Thanks to all who offered suggestions. I read "Extreme Programming Installed" over the last couple days and found several things that were interesting. I like the "user story" method of defining the specifications for a project. I'm going to try this. My students are part way through a new Portfolio Tracker assignment (http://www.isd197.org/sibley/cs/icp/assignments/portfolio_html), but I think I'll hand out some user story cards and get them used to the concept. I wrote up another project page at http://www.isd197.org/sibley/cs/icp/assignments/portfolio2_html that emphasizes the user stories. I wonder if any of you would look it over and give me some feedback. Specifically, do the user stories capture the specs adequately? (My project page also includes a PDF of the user stories I'm going to hand out.) -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson@visi.com | <dtml-var pithy_quote> | http://linux.com
(I inadvertently sent this to the original poster only -- I meant to send it to the OP and the list so here it is.) In quickly reading your materials, e.g.,,
My students are part way through a new Portfolio Tracker assignment (http://www.isd197.org/sibley/cs/icp/assignments/portfolio_html), but I think I'll hand out some user story cards and get them used to the concept.
I wrote up another project page at http://www.isd197.org/sibley/cs/icp/assignments/portfolio2_html that emphasizes the user stories.
etc. I had expected more real "stories" -- i.e. "So, a user walks into a brokerage house and asks..." with the eye on the stories being one to engage the imagination and from the story to distill the requirements. That's kind of what I have done for middle school students with respect to a Mars Voyage Simulation written in Perl (see: http://home.mindspring.com/~djrassoc01/mars/index.html ) though it's not quite the same thing because I was writing the program to fit some requirements of a Mars Space Camp that the students were taking. Still, I tried (for middle school students) to weave a "simulation story" around what I was doing so there would be a natural visualizable way that the programming aspects would fall out and be meaningful to the students rather than seeming to have just been pulled out of thin air. Your students are several years older than mine so it may be that they don't need (as I felt) the more concrete story telling to get their heads into the problem -- in which case the comments are not that relevant. --D. -- Dr. David J. Ritchie, Sr. djrassoc01@mindspring.com http://home.mindspring.com/~djrassoc01/
participants (4)
-
Dr. David J. Ritchie, Sr. -
Jason L. Asbahr -
Steve Howell -
Timothy Wilson