Resources

Apple Distinguished Educators are invited to join this wiki and add resources...


Standards




Video




Models of Leadership 2.0 in action





Articles




Books



Game Theory

Below is a short article describing Game Flow and the elements that need be included in an activity to make it fun as well as a chart that shows the relationship between ability and challenge, a cornerstone of the Flow theory. Take a look. I think it has some direct application that could be useful as selection criteria for possible solutions to our challenge.

Game Flow Article.pdf
http://docs.google.com/fileview?id=F.9bf37437-7c9e-4056-be61-462e22453522

Agile vs Waterfall resources

  • Agile Development - http://en.wikipedia.org/wiki/Agile_software_development
  • Agile Software Menifesto - http://www.agilemanifesto.org/
  • Scrum - Pigs/Chickens - http://en.wikipedia.org/wiki/Scrum_(development)
  • Planning Poker - http://www.planningpoker.com/
    The idea behind Planning Poker is simple. Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again.
  • Collaborative software development model - http://en.wikipedia.org/wiki/Collaborative_software_development_model - A style of software development whose focus is on public availability and communication, usually via the Internet.
  • Agile Modelling - http://en.wikipedia.org/wiki/Agile_Modeling - A construct for documentation
  • User Stories - http://en.wikipedia.org/wiki/User_stories - User stories are a quick way of handling customer requirements without having to elaborate vast formalized requirement documents and without performing overloaded administrative tasks related to maintaining them. The intention with the user story is to be able to respond faster and with less overhead to rapidly changing real-world requirements.
    User stories define what is to be built in the software project. User stories are prioritized by the customer to indicate which are most important for the system and will be broken down in tasks and estimated by the developers. When user stories are about to be implemented the developers should have the possibility to talk to the customer about it. The short stories may be difficult to interpret, may require some background knowledge or the requirements may have changed since the story was written. Every user story must at some point have one or more acceptance tests attached, allowing the developer to test when the user story is done and also allowing the customer to verify it. Without a precise formulation of the requirements, prolonged nonconstructive arguments may arise when the product is to be delivered. XP and other agile methodologies favour face-to-face communication over comprehensive documentation and quick adaptation to change instead of fixation on the problem. User stories achieve this by:
  • Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
  • Allowing developer and client to discuss requirements throughout the project lifetime
  • Needing very little maintenance
  • Only being considered at the time of use
  • Maintaining a close customer contact
  • Allow projects to be broken into small increments
  • Suited to projects where the requirements are volatile (change often) or poorly understood. Iterations of discovery drive the refinement process.
  • May be easier to estimate development effort

  • Waterfall Method - The old way of doing things. Becomes harder to change as projects grow and develop.
File:Waterfall model.svg
File:Waterfall model.svg
Waterfall method -http://en.wikipedia.org/wiki/Waterfall_model - A sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and Maintenance. Requires early commitment in concept and design phases with little deviation in lower stages resulting in poor agility to deal with new circumstances, challenges, and requirements during the development porcess. Leaves you with a solution that may have worked when you began but now that you are done does not meet all the requirements of your users.




DIscussion

Subject Author Replies Views Last Message
FEEDBACK NEEDED - Game-Based Risk-Free Incentives chorusboy chorusboy 0 114 Jul 14, 2009 by chorusboy chorusboy
Invitation Dolton Dolton 0 128 Jul 13, 2009 by Dolton Dolton