HeaderSIS.jpg

Difference between revisions of "IS480 Team wiki: 2014T1 Team Epsilon Project Management"

From IS480
Jump to navigation Jump to search
Line 41: Line 41:
 
<!-- Start Content -->
 
<!-- Start Content -->
  
 +
== Agile Software Development ==
 
<b> Choice of Methodology </b>
 
<b> Choice of Methodology </b>
  

Revision as of 03:15, 24 August 2014

Team Epsilon Logo.png.png

Home   Project Overview   Project Management   Documentation   Team

Methodology   Project Schedule   Metrics Management   Risk Management


Agile Software Development

Choice of Methodology

Our team will be adopting the Agile software development methodology in managing this project.

We aim to:

  • Deliver working software more frequently
  • Prioritize functions based on business value
  • Measure progress principally based on working useful software


Primary Essence of Agile

To focus on delivering value-adding functionality as often as possible, from the point of view of our customer.


Tasks

Many tasks we perform, while necessary in most cases, do not provide actual value to the customer by themselves. In software development, it means that although some tasks like “analysis”, “coding” and “testing” are necessary to achieve and deliver our end-product or feature, they are not what our customer seek. The value then, is in the “working feature” that our customer needs.


Stories

To measure and deliver value to our customer, we adopt the classic “stories” that agile methodology provides. It is assumed that all tasks that need to transpire to deliver a story will ensue. But we should not be giving or getting any cookies for simply completing these menial tasks. Rather, we aim to only get cookies when we deliver working (running & tested) features that the customer wants; we get cookies for delivering value.


Tell a Smaller Story

Our system also has its share of “Epic Stories”; stories that in our group’s context, have 150 story points and above. This simply means the story is more complex and bigger, resulting in more effort and time needed to complete it. In order to deliver value as often as possible, we strive to break the story (feature) up into smaller pieces whenever possible; the smaller a story, the faster we are able to deliver value. Smaller stories also mean the estimation of effort needed is more accurate, it is easier to design and improve as we go along, and it is easier to test and deliver working features. Alas, no matter how small we split a story, we do not split by tasks - each split in and of itself must still provide demonstrable value to the customer.


Burn Stories; Not Tasks

Traditional agile burndown charts tracks by the task-level. We want to focus on completing stories, not tasks. Besides focusing us on the wrong things, it also burdens us to worry about too many things by encouraging us to micro-manage menial tasks. This is very “un-agile”-like and will only lead to reduced productivity and diminished value for the team.


Communication

In order to ensure all parties get updated regularly about the project's progress, our team will be using:

  • Daily Conversation: Face-to-face meet-ups, Whatsapp, or Facebook messaging to keep the team up to date. This will replace our group's daily standup meeting as it provides us more flexibility.
  • Weekly Round-Up Meeting: Every week, we will have an internal meeting where we summarize and consolidate what has been done over the past week, as well as what is ahead of us.
  • Fortnightly Sponsor Meeting: Once every two weeks, we try to arrange a sponsor meeting to update our client with our team's progress as well as deliver him a workable piece of software.
  • Supervisor Meeting: Once every three to four weeks, or by need basis, we will arrange a supervisor meeting to update our supervisor regarding the team's progress as well as clarify and consult him on any doubts we might have regarding the team's direction and project.