This months meeting was at a new location - Camden Clubhouse situated in Downtown Orlando. One of our excellent members, Demetrius Ford, arranged for a meeting room for our use.
We had a nice turnout, with the following members present eager to learn more about PHP and related technologies: David Rogers and his wife Rachael, Demetrius Fordand his son Demetrius, Kristian Stoyanov, Tony Guijarro, Steven Martin, Derek Gallo, Jamal Fanaian, Trevor Meyer, Spargnacat and David Harris.
CakePHP vs. Zend Framework
Since this was a new location we had some unplanned technical difficulties due to not having the correct cables to connect the laptop to the meeting room’s view screen. While David and Tony went to procure the correct one, a discussion regarding the merits and difficulties of Zend Framework vs. CakePHP ensued. Derek Gallo mentioned while CakePHP allows you to get started quickly, Zend Framework’s components allowed for greater control over your application. He also mentioned the importance of using Test Driven Development (TDD ) while you’re developing your application.
Back to Business
After David and Tony returned with the correct cable, Kristian presented a unique web application he had designed and started developing: TASCK.com, a simple online task manager. He explained the current features and the direction he wanted to take the application but admitted to being mostly an Information Designer and User Interface Designer, not a Developer. After giving us the walk-through of TASCK, David’s presentation began. He discussed Mike Cohn’s book User Stores Applied, which served as a resource for him to learn about estimating how much time a project should take.
Estimation using Hours
David then discussed the down-side of estimating a project using hours. He discussed how developers hate it since it ties them down to that specific amount of time to finish a project which they themselves might think would warrant more time. He also discussed how time estimates don’t work. Time estimates more often then not will end up being inaccurate whether you’re at the beginning, middle, or the end of a project.
An alternative to the hour system: Planning Poker
At this point David introduced us to planning poker: a method of estimating a project’s cost based on risk and overall difficulty. Planning poker utilizes a deck of cards numbered using a fibonacci-like sequence. Each developer on your team then chooses the card with the number he/she feels is indicative of the level of difficulty of the project. There is no preset definition for what each number corresponds to - it’s up to the developer to decide. After that the developers reveal what they chose. Then the developers discuss why they chose what they did.
This point in the development phase helps you learn how the other developers view the project, and what they themselves believe will be necessary to accomplish it. This is an excellent way of learning about what goes into a project, and about aspects of a project that you may not have thought of, or may have overcomplicated.
This process also helps clear up misconceptions that the developers might have on what the customer desires from the application as well as giving the customer new insight in certain features or the functionality of existing features that could be done differently.
Let’s do this!
Having discussed Kristian’s TASCK.com web application earlier, Kristian graciously played our “customer”. The rest of us then divided up the project’s requirements and decided individually what planning poker number each task warranted. Then we discussed the choices and came to a consensus. During this discussion a majority of developers would choose a certain value, while others would choose much higher or lower. We discussed the following and assigned the following points to them:
- Adding a task (5 points)
- Deleting a task (5 points)
- Deleting all tasks (5 points)
- Marking a task as done (8 points)
Derek Gallo mentioned how the levels (values on the cards) are relative, which we saw when we moved from “Adding a task” to “Deleting a task”. Since they were very similar in what it would take to implement, we estimated similar numbers. Also over the course of the discussion, the customer - Kristian - learned how he could utilize “categories” as “filters” for tasks rather than as “folders”. Hence, both the customer and the developers came out of the process with a better understanding of what the application should entail and the complexities involved in implementing the application.
Next month, we plan to continue the exercise and finish estimating more of Kristian Stoyanov’s TASCK.com. You should come!
