Wednesday, July 17, 2013

Agile : Planning Poker

Planning poker, also called Scrum poker, is a consensus-based technique for estimating, mostly used to estimate effort or relative size of user stories in software development. Planning Poker is a technique to determine user story size and to build consensus with the development team members. Planning poker is a popular and straightforward approach to estimating story size.
The method was first defined and named by James Grenning in 2002 and later popularized by Mike Cohn in the book Agile Estimating and Planning, whose company trade marked the term.
To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators. Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates. The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time. Only the development team plays estimation poker. The team lead and product owner don’t get a deck and don’t provide estimates. However, the team lead can act as a facilitator, and the product owner reads the user stories and provides details on user stories as needed.
"Planning Poker is a good way to come to a consensus without spending too much time on any one topic. It allows, or forces, people to voice their opinions, thoughts and concerns."
- Lori Schubring, Manager, Bemis Manufacturing Company

Planning poker benefits
Planning poker is a tool for estimating software development projects. It is a technique that minimizes anchoring by asking each team member to play their estimate card such that it cannot be seen by the other players. After each player has selected a card, all cards are exposed at once. Anchoring can occur if a team estimate is based on discussion alone. A team normally has a mix of conservative and optimistic estimators and there may be people who have agendas; developers are likely to want as much time as they can to do the job and the product owner or customer is likely to want it as quickly as possible. Planning poker exposes the potentially influential team member as being isolated in his or her opinion among the group. It then demands that she or he argue the case against the prevailing opinion. If a group is able to express its unity in this manner they are more likely to have faith in their original estimates. If the influential person has a good case to argue everyone will see sense and follow, but at least the rest of the team won't have been anchored; instead they will have listened to reason.

Friday, July 12, 2013

lawnchair : simple JSON storage

Persistent local storage is one of the areas where native client applications have held an advantage over web application. Cookies were invented early in the web’s history, and indeed they can be used for persistent local storage of small amounts of data. But they have three potentially deal breaking downsides:
  • Cookies are included with every HTTP request, thereby slowing down your web application by needlessly transmitting the same data over and over
  • Cookies are included with every HTTP request, thereby sending data unencrypted over the internet (unless your entire web application is served over SSL)
  • Cookies are limited to about 4 KB of data — enough to slow down your application (see above), but not enough to be terribly useful
Whats really needed is:
  • a lot of storage space
  • on the client
  • that persists beyond a page refresh
  • and isn’t transmitted to the server
What is Web Storage?
With HTML5, web pages can store data locally within the user's browser. Web Storage is more secure and faster. The data is not included with every server request, but used ONLY when asked for. It is also possible to store large amounts of data, without affecting the website's performance. The data is stored in key/value pairs, and a web page can only access data stored by itself.
A lawnchair is sorta like a couch except smaller and outside. Perfect for HTML5 web/mobile apps that need a lightweight, adaptive, simple and elegant persistence solution.
  • Collections. A lawnchair instance is really just an array of objects.
  • Adaptive persistence. The underlying store is abstracted behind a consistent interface.
  • Pluggable collection behavior. Sometimes we need collection helpers but not always.
  • Super micro tiny storage without the nasty SQL: pure and delicious JSON.
  • Default build weighs in at 3.4K minified; 1.5 gzip'd!
  • Adapters for any client side store.
  • Designed with mobile in mind.
  • Clean and simple API.
  • Key/value store ...key is optional.
  • Terse syntax for searching/finding.
  • Battle tested in app stores and on the open mobile web.
  • Framework agnostic. (If not a framework athiest!)
By default, Lawnchair will persist data using DOM Storage but if other adapters are available and DOM Storage isn't supported by the currently executing JavaScript runtime. Lawnchair will attempt each successive adapter until it finds one that works.