Archive for October, 2009
SCRUM for clients
Tuesday, October 20th, 2009
UPDATE: this post has evolved into the About Our Work Methodology page in our website.
This post is intended for customers to understand the implications of using this methodology and how we implement it in our daily work.
Scrum is an agile development methodology based in the following principles:
- The customer or Product Owner has an important involvement in the development process.
- Product requirements are defined with the Product Owner (usually as User Stories) and put together as Product Backlog Items. It is a desired practice that Product Owner actually writes requirements.
- Product Owner prioritizes the Product Backlog Items in accordance with its business value.
- Product Backlog Items are estimated, whether by time or relative weight, only by the development team. This estimation is adjusted constantly, usually at the start of each Sprint.
- The development cycle is divided into time-boxed Sprints of a fixed duration (typically 2 to 4 weeks). Each Sprint has a clear Sprint Goal and produces a working product increment.
- Before each Sprint starts, a Sprint Planning meeting is done to choose which requirements are implemented and the details on each are discussed. The whole development team and Product Owner participate.
- The requirements that are implemented in a Sprint constitutes the Sprint Backlog.
- Once a Sprint starts, no changes are accepted for the Sprint (bugs could be an exception).
- A Daily Scrum meeting is held every morning only between members of the dev team. This is a short-stand-up meeting where each member communicates: what he did yesterday, what he will be doing today and any impediment he is facing.
- At the end of each Sprint a Sprint Review or demo is held where the team demonstrates the product increment to the Product Owner and any other involved stakeholder.
- At the end of each Sprint, a Sprint Retrospective is held to discuss what it is working and what it is not.
How we define what to do
It is important for us to clearly understand what you want to do. We usually like to put this on a Project Vision document. Customers often think that, as we developers we are not interested in the business background for a project. Well, not only we are very interested but we strongly need to know all the aspects of the business related to a project in order to understand the project and to make key decisions in the design and implementation stage of the development cycle.
A Project Vision document contains all available thinking about what a project will be. It defines the goals of a project, why they make sense and what the high-level features, requirements or dates for a project will be.
The most important points to cover in the Project vision are:
- Vision Statement. This is usually a once sentence that describes this specific release of the project. This is also known as the problem statement because usually projects are planned to solve a specific problem.
- Project Goals. Describe how this project contributes to the goals of the organization, customer or final user.
- Business Opportunity. Describe what is the current business situation, what users’ or customers’ needs are not being satisfayed, what competitors are doing or offering and how we can change the world with our solution.
- Users Description. Describe who are the customers, what problems does this software solve for them and why they would use or buy the software.
- Stakeholders Description. Who are the stakeholders (people with power on the project but not necessary the users/customers) and what role they have in the project.
- Product Features. This section describes the high-level features for the system. We prefer not to employ use cases here because they are too detailed and usually people reading the Project Vision just want a short overview identifying the key functions. User stories could be a list too long to describe in the Project Vision. That’s why prefer to write it as a list of features. It is important to differentiate between essential features (priority 1) and desired-but-not-essential (priority 2).
-
Other topics could be Risks and Assumptions being made and Dependencies on other projects, companies or organizations.
How we define requirements
Requirements also define “what to do” in a project, although, with a deeper level of detail than what can be found in the Product Features of the Vision document.
There are several types of Requirements. We classify them as Functional and Non Functional (Usability, Reliability, Performance, Supportability, Implementation, Interface, Operations, Deployment and Legal).
Functional Requirements are among the most important because they define the core of the system, what the system must do, its features and capabilities. Functional Requirements are usually defined as User Stories or Use Cases.
We strongly think that requirements should be written by the customer with one or more members of the development team or, at least, participate actively in the requirements definition.
The best method to involve the client in the definition of the system requirements is by using User Stories because they are easier to conceive and because they are formulated in a more natural and spoken language.
User Stories
User Stories define a goal that a specific type of user has when using the system, in a natural language. Although it is not necessary to follow it, we use this format to describe the User Stories:
As a [type of user], I want/can/need/etc. [goal or need], so I can [reason].
An example of a User Story, for an e-learning web site could be:
As a Teacher,I want to create an online test, so I can measure the level of the students.
User Stories have a more important advantage. They are an easier method to have non technical involved people define requirements. For example, it is easier for a Product Owner to write a list of requirements in this format than in the format of a Use Case diagram or a list of Use Cases.
User Stories emphasize verbal communication, in comparison to written language. The use of the first person to describe the goal make them sound more natural and tend to avoid misunderstandings typical of a written document.
We strongly prefer to define Functional Requirements as User Stories or inspired by them (because sometimes they could be too long) because they are a lot much easier to discuss with clients and users.
All the User Stories (or Use Cases or Features, depending on what we decide to use), along with any other requirement that is expressed in any different way are put together in the Product Backlog. This constitutes all what has to be done to complete the product.
We define the Product Backlog in a System Requirements Specifications (SRS) document and we manage it (time and resources) using a spreadsheet. The SRS document could contain additional information about each User Story. The Non-Functional requirements are also described in the SRS.
Acceptance Criteria
While the Product Backlog defines all what has to be done, sometimes it is risky to give the customer a fixed estimate or quote based only in simple User Stories or Features.
To solve this we sit together with the customer and go through each User Story and define what we call the Acceptance Criteria. This describes the high level features a User Story has to meet and the Tests it has to pass in order to be accepted as complete either by the development team or by the customer.
Examples of Acceptance Criteria for the above User Story could be:
| As a Teacher,I want to create an online test, so I can measure the level of the students.
Description
Acceptance Tests
|
Resources
Scrum Video: http://www.youtube.com/watch?v=Q5k7a9YEoUI
Scrum Presentation: http://www.mountaingoatsoftware.com/scrum-a-presentation
Bibliography
The Art of Project Management – Scott Berkum
UML and Patterns – Craig Larman
Posted in Development | No Comments »
Software Development Top 10 Content Sites
Tuesday, October 6th, 2009
Centraldev was mentioned in Latin IT Marketing as one of the Top 10 Content Sites of Software Development. The list includes the best sites in Latin America that offers relevant content to their target audience.
The list was created based in 9 different aspects:
- Clarity in its benefit message and unique service difference.
- Clarity in the following steps: “What do I do now? Where do you want me to click?”
- Not confusing site.
- Enough information so I can take an action and call them.
- Use of my 5 senses: video, images, emotions, etc.
- A blog which give valuable information and educates me about the industry or something that helps my company.
- Reports, white papers or virtual books that I can download.
- A newsletter to learn about the news of the company.
- Links to social media: Twitter, Linkedin, Facebook, etc.
Link: http://latinitmarketing.com/10-mejores-sitios-web-desarrolladores-software
Posted in Uncategorized | No Comments »
