Skip navigation

Monthly Archives: November 2014

Standards for Scrum:
• A Scrum team must have a Product Owner and know who that person is.
• The Product Owner must have a Product Backlog with estimates created by the team.
• The team must have a Burndown Chart and know their velocity.
• There must be no one outside a team interfering with the team
during a Sprint.

Scrum and XP teams don’t pursue drawing the perfect UML model in a case tool, writing the perfect requirements document, or writing code that will be able to accommodate all imaginable future changes. Instead, Scrum and XP teams focus on getting things done. These teams accept that they may mistakes along the way, but they also realize that the best way to find those mistakes is to stop thinking about the software at the theoretical level of analysis and design and to dive in, get their hands dirty, and start building the product.

Scrum is not a methodology, it is a framework. What that means is that Scrum is not really going to tell you exactly what to do. Darn.

How we do product backlogs
The product backlog is the heart of Scrum. This is where it all starts. The
product backlog is basically a prioritized list of requirements, or stories, or features, or whatevers. Things that the customer wants, described using the customer’s terminology. Important that’s in shape when the team sees it

Our stories include the following fields:
ID – a unique identification, just an auto-incremented number.
This is to avoid losing track of stories when we rename them.

Notes from a presentation by Virgil Dobjanschi at Google I/O 2010

So what is RESTScreen Shot 2014-11-13 at 10.04.05? REST stands for Representational State Transfer. It is a broadly adopted architecture style. This architecture style is comprised of clients and servers. Clients make request to the server to get or change the state of a particular resource. Servers respond to the client with representations of resources. So what is a resource? A resource is any meaningful concept that can be addressed. For the purpose of this talk I’m going to reference back to the Google Finance API as a simple example of an API. A resource, in the case of the Google Finance API, is a stock portfolio, which is characterised by its name and the currency in which it operates. The representation of a resource is simply a document that fully describes that particular resource. In case of the Google Finance API, this is an XML document which simply describes that particular resource in terms of its name and the currency, and maybe its ID for the purpose of referring to that particular resource later on, when you need to update or delete it.





from: apps.html