Cool Software
I was looking for a free software which allows you to send free mass email newsletters. I downloaded and started using the free version of GroupMail 5.2.058.
The free version is adequate for basic purposes and is very easy to use. It is possible to create emails containing graphics using this software. It is also possible to import a list of users and add them to groups.
Saturday, November 24, 2007
Estimating and Tracking Progress of an Agile Software Project
Project Velocity Extreme Programming Story Points Ideal Time
Project Velocity is a measure that it used when estimating how much of work will get done in an iteration in an agile software project. Velocity measures the rate at which business value is delivered. It's calculated by simply summing up the estimated units of stories delivered in an agile iteration. Assuming all iterations are of the same duration, velocity can be used to estimate size of software that can be delivered in future iterations. If iterations are of variable length, it would make sense to use the metric velocity per week to estimate the velocity in an iteration.
The units of velocity could be any measure of estimates. Ideal hours and Story Points are two of the most widely used units.
Once, development of the software starts, it is important to track progress of a project. Agile software projects are not plan driven but planning is continuous. Therefore, every single day the progress of the project should be tracked by its project manager. Burn charts are a very good way to track project progress. The units could be story points, ideal hours, or any other unit used for estimations.
I personally prefer burn-down charts as it shows how much of work is left before we complete. It feels better when the line approaches zero.
The above chart shows a line for 'Estimated Burndown' which shows the rate work should complete to reach the target for delivery. This shows the team is behind schedule and the project manager should take corrective action for course correction.
It is also possible to show scope change in a burn-down chart.
Project Velocity is a measure that it used when estimating how much of work will get done in an iteration in an agile software project. Velocity measures the rate at which business value is delivered. It's calculated by simply summing up the estimated units of stories delivered in an agile iteration. Assuming all iterations are of the same duration, velocity can be used to estimate size of software that can be delivered in future iterations. If iterations are of variable length, it would make sense to use the metric velocity per week to estimate the velocity in an iteration.
The units of velocity could be any measure of estimates. Ideal hours and Story Points are two of the most widely used units.
Once, development of the software starts, it is important to track progress of a project. Agile software projects are not plan driven but planning is continuous. Therefore, every single day the progress of the project should be tracked by its project manager. Burn charts are a very good way to track project progress. The units could be story points, ideal hours, or any other unit used for estimations.
I personally prefer burn-down charts as it shows how much of work is left before we complete. It feels better when the line approaches zero.
The above chart shows a line for 'Estimated Burndown' which shows the rate work should complete to reach the target for delivery. This shows the team is behind schedule and the project manager should take corrective action for course correction.
It is also possible to show scope change in a burn-down chart.
Thursday, November 22, 2007
Mindomo - Software for Mind Mapping the Web 2.0 Way
Cool Software Mind Mapping
Ever since I read the book: Mind Map Book by Tony Buzan, I have been using this wonderful technique for almost everything. Mind mapping is a great way to organize one's thoughts and
to brainstorm. I've used mind mapping at work, with my studies, and sometimes simply to help my thinking. I also found this very helpful when preparing for speeches at Toastmasters.
In the past I used the open source software: Freemind.
This is a really powerful tool and I've done very complex mind maps with Freemind.
However, during the past year, I have started using more Web2.0 software and it wasn't long before I started looking for a Web2.o tool for mind mapping.
Last week I started using Mindomo which is a web based mind mapping software. You can use it free for up to 7 private mind maps. Compared to Freemind, this is easier to use as I don't need to open another application each time. I can simply use my browser. When I click a hyperlink on the mind map it can open in another tab on the same browser window, which I find very helpful. It is also possible to share the mind map as an HTML page.
Ever since I read the book: Mind Map Book by Tony Buzan, I have been using this wonderful technique for almost everything. Mind mapping is a great way to organize one's thoughts and
to brainstorm. I've used mind mapping at work, with my studies, and sometimes simply to help my thinking. I also found this very helpful when preparing for speeches at Toastmasters.In the past I used the open source software: Freemind.
This is a really powerful tool and I've done very complex mind maps with Freemind.
However, during the past year, I have started using more Web2.0 software and it wasn't long before I started looking for a Web2.o tool for mind mapping.
Last week I started using Mindomo which is a web based mind mapping software. You can use it free for up to 7 private mind maps. Compared to Freemind, this is easier to use as I don't need to open another application each time. I can simply use my browser. When I click a hyperlink on the mind map it can open in another tab on the same browser window, which I find very helpful. It is also possible to share the mind map as an HTML page.
Agile Management for Software Engineering
Agile Software Book Review Software Metrics
I have completed reading a few chapters of the book: Agile Management for Software Engineering by David J. Anderson. The book tries to apply the Theory of Constraints (TOC) approach to software engineering.
TOC is based on the notion that "A value chain is as strong as its weakest link". It recommends that the weakest link is identified and exploited.
Friday, November 9, 2007
XP Stories vs. Use Cases for Software Estimation
Use Cases User Stories Extreme Programming
XP
Unified Process
A topic which often surfaces in discussions about XP is, whether Stories in XP are the same as Use Cases under a different name. Apparently, they seem to be the same. However, if you analyze a little deeper it's possible to identify subtle differences between the 2 approaches.
In my view, the main difference is their purpose of existence. The main purpose of a user story in XP is to identify the scope of the project as early as possible and to track project progress. While a use case tries to capture requirements at the required level of detail. The XP approach is to have the story defined in simple words and to get more details from the customer before development starts.
User Stories in XP
XP
Unified Process
A topic which often surfaces in discussions about XP is, whether Stories in XP are the same as Use Cases under a different name. Apparently, they seem to be the same. However, if you analyze a little deeper it's possible to identify subtle differences between the 2 approaches.
In my view, the main difference is their purpose of existence. The main purpose of a user story in XP is to identify the scope of the project as early as possible and to track project progress. While a use case tries to capture requirements at the required level of detail. The XP approach is to have the story defined in simple words and to get more details from the customer before development starts.
User Stories in XP
- Purpose: Estimation, identification of scope early, and tracking progress.
- Characteristics: Simple; any customer visible functionality.
- Approach: Meet customer face-to-face and get details before implementing.
- Suitability: Projects that need early implementation.
- Purpose: Describe all tasks that users will need to perform with the system.
- Characteristics: Can be scaled to have many details; functional and behavioral requirements.
- Approach: Gathered mainly initially (inception & elaboration phases).
- Suitability: complex large projects.
Thursday, November 8, 2007
More Thoughts on Balancing Agility and Discipline in Software Projects
Agile Software Agile Extreme Programming
XP
The book Balancing Agility and Discipline tries to find a common ground between agile and plan-driven method. The book uses the work 'Discipline' to refer to plan-driven approaches. Its implication that the agile methods lack discipline has not been accepted by the agile community.
Here's a review of the book by Ron Jeffries of XP fame.
XP
The book Balancing Agility and Discipline tries to find a common ground between agile and plan-driven method. The book uses the work 'Discipline' to refer to plan-driven approaches. Its implication that the agile methods lack discipline has not been accepted by the agile community.
Here's a review of the book by Ron Jeffries of XP fame.
Saturday, November 3, 2007
Balancing Agility and Discipline in Software Projects
Agile Software Extreme Programming Book Review
I have been an advocate of agile software development methodologies since 2001. Over the years, I have managed many projects using Extreme Programming and have observed my colleagues manage projects using agile and XP.
I came to notice that agile methodologies, offer no silver bullet to software engineering. One of the main risks of agile methodologies is the assumption that the customer will play a major role in the project by working closely together with the team. However, in practice, I have seen many situations where the customer is not willing to spend the effort of working together with the project team to make the project a success. I have also seen instances where the customer took advantage of the agility to push for more requirements into the project. These issues may not happen with all customers but these risks cannot be ignored (especially in some cultures).
I've started reading the book "Balancing Agility and Discipline" by Barry Boehm and Richard Turner. I'm into the second chapter, and already I am beginning to like this book. The book tries to find a middle path between agile and plan-driven software development. This is something I have always believed in. Instead of considering 2 extreme ends of software development methodologies, each claiming to be the answer to all questions, I believe, we need to understand the features of each approach that would be suitable for a given context and come up with the right mix of agility and discipline in each case.
I would like to quote the following from the book:
"If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a start-up company before it has to turn to profit"
I will post more thoughts as I continue to read the book.
More thoughts
I have been an advocate of agile software development methodologies since 2001. Over the years, I have managed many projects using Extreme Programming and have observed my colleagues manage projects using agile and XP.
I came to notice that agile methodologies, offer no silver bullet to software engineering. One of the main risks of agile methodologies is the assumption that the customer will play a major role in the project by working closely together with the team. However, in practice, I have seen many situations where the customer is not willing to spend the effort of working together with the project team to make the project a success. I have also seen instances where the customer took advantage of the agility to push for more requirements into the project. These issues may not happen with all customers but these risks cannot be ignored (especially in some cultures).
I've started reading the book "Balancing Agility and Discipline" by Barry Boehm and Richard Turner. I'm into the second chapter, and already I am beginning to like this book. The book tries to find a middle path between agile and plan-driven software development. This is something I have always believed in. Instead of considering 2 extreme ends of software development methodologies, each claiming to be the answer to all questions, I believe, we need to understand the features of each approach that would be suitable for a given context and come up with the right mix of agility and discipline in each case.
I would like to quote the following from the book:
"If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a start-up company before it has to turn to profit"
I will post more thoughts as I continue to read the book.
More thoughts
Subscribe to:
Posts (Atom)
