Scrum Poker (ou Poker Planning)

Artigo bastante elucidativo, de uma forma divertida :), sobre Poker Planning, metodologia proposta por Mike Cohn, para calcular estimativas para a duração das stories.

http://www.crisp.se/planningpoker

Have fun :o)

What Do Actors and Programmers Have in Common?

Artigo interessante sobre metodologias (estrategias?) partilhadas por estes dois grupos, aparentemente tão distintos :)

[…]
So, what do actors and programmers have in common?
Well, some amazingly fundamental things as it turns out:

* Iterative work
* Collaboration
* Innovation

Theatre work and product development both thrive on iteration and collaboration. Lee described this in terms of rehearsal and the emergent look of a play leading up to and even after opening night. Rob affirmed the value of a collaborative and iterative approach in product development[…]

Mais aqui: http://www.rallydev.com/agileblog/2009/11/what-do-actors-and-programmers-have-in-common/

How to implement Scrum in 10 easy steps :)

Artigo que propõe uma metodologia para aplicar a metodologia :)
Scrum, entenda-se :))

Daqui: http://www.agile-software-development.com/2007/09/how-to-implement-scrum-in-10-easy-steps.html

- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

Pragmatic Agile Development (PAD)

Interessante.
Uma abordagem a metodologias ageis, baseada em Scrum, mas com algumas alterações.

Aqui fica um pequeno resumo.

Pragmatic Agile Development (PAD) and Agile Scrum

It is important to note that the way we use Agile Scrum varies from a purist version of Scrum as we have made modifications to Agile Scrum to work well for our development environment. Our version of Scrum is called Pragmatic Agile Development (PAD) and differs from a more purist Scrum implementation in these ways:

1. Scrum Planning - In Scrum, planning for an upcoming sprint is accomplished in 1 day, in PAD the planning spans 1 week. This is because we write more detailed specifications than a purist Scrum does (see next bullet item).
2. User Stories vs. Specifications - In Scrum, requirements are written on index cards (called User Stories) and does not contain prototypes or detailed explanations of the feature set. In PAD, we spend time detailing the requirement specifications with prototypes to ensure that time is well spent on the feature, reducing rework.
3. 30 Day Sprints - In Scrum, development is done in 30 calendar days. In PAD, development is done in 30 working days, skipping holidays. This provides us with more evenly distributed sprints.
4. Team Composition - In Scrum, developers are expected to perform all duties (analysis, design, coding, test case development, execution, and documentation). In PAD, developers help with analysis and design and perform all the coding. We have specialized team members (Software Quality Engineers) for test case development and specialized team members for documentation. We do this because our experience has shown that we need specialists in these areas.

E o link: http://softwareplanner.com/Newsletters/newsletter_2008_05_SP.htm

KISS! :)

KISS. Keep IT Simple Stupid.

Manter o SCRUM simples, nao complicar.
O que quer dizer isto??

Manter as stories simples.
Manter a Review/Planning Meetings simples.
Etc, etc, etc...
Simplicidade. Simplicidade. Simplicidade.

A NAO ESQUECER!! :))

Artigos interessantes sobre KISS e SCRUM :)

http://pt.wikipedia.org/wiki/Keep_It_Simple
http://diego-pacheco.blogspot.com/2009/04/o-melhor-do-xp.html
http://www.techcrunch.com/2009/04/28/keep-it-simple-stupid/
http://rafaelspereira.wordpress.com/2008/04/13/keep-it-simple/
http://blog.lppjunior.com/planejamento-de-software-keep-it-simple-stupid/

E ainda, YAGNI :)

Tudo deve ser feito da forma mais simples possível, mas não mais simples que isso.
Albert Einstein

A perfeição é alcançada não quando não há mais nada para adicionar,
mas quando não há mais nada que se possa retirar.
Antoine de Saint-Exupéry

A simplicidade é a ultima sofisticação.
Leonardo Da Vinci

:)

SCRUM User Stories

In Scrum, work is expressed in the backlog as user stories. A team may write its user stories in a number of ways as long as they are written from the perspective of the end user. Put another way, team members are encouraged to think of their work from the perspective of who will use it (hence “user” story). A team can express a story as a noun (i.e. “text message” on a cell phone project) or a sentence or phrase (i.e. “debug GPS tracking system”).

Many Scrum teams have adopted the user story template developed by Mike Cohn, which identifies who the end user is, what the end user wants, and why in a single sentence. This model of the user story is most often written like this: “As a [end user role], I want [the desire] so that [the rationale]."

To illustrate, consider how a developer working on a calculator application for a PC might express his work. First, the developer would want to identify who will benefit from this appication: a PC user. Second, he would want to decide what the PC user will want to get out of it: a convenient, prepackaged calculator application. Third, he would want to be able to explain why it’s important for the PC user to have this application. This piece of information is the most open to interpretation, but one can safely assume that the PC user would want to use it to add, subtract, multiply, and divide. Thus the developer’s user story could read something like the following: “As a PC user, I want a calculator with basic functionality on my PC so that I can conveniently perform basic mathematic operations.”

In summary, user stories document requirements with particular attention to the end user’s point of view. Stories can be written in myriad ways, but Cohn’s model really works in Scrum because it provides so much information about the story. Because user stories are oriented to reflect the desires of the end user, they help developers remain focused on the customer.

Daqui: http://scrummethodology.com/scrum-user-stories/

SCRUM Ceremonies - Detalhes

Scrum has three ceremonies: Sprint Planning, Sprint Review, and the Daily Scrum Meeting.

Sprint Planning Meeting

Preparation for a Scrum sprint begins when the Product Owner develops a plan for a product or a project. The Product Owner can be a customer representative or a customer proxy. For product companies, the customer is a market, and the Product Owner serves as a proxy for the market. A Product Owner needs a vision for the product that frames its ultimate purpose, a business plan that shows what revenue streams can be anticipated from the product in which timeframes, and a road map that plans out several releases, with features ordered by contribution to return on investment (ROI). S/he prepares a list of customer requirements prioritized by business value. This list is the Product Backlog , a single list of features prioritized by value delivered to the customer.

The Scrum begins when enough of the Product Backlog is defined and prioritized to launch the first thirty-day sprint. A Sprint Planning Meeting is used to develop a detailed plan for the iteration. It begins with the Product Owner reviewing the vision, the roadmap, the release plan, and the Product Backlog with the Scrum team. The team reviews the estimates for features on the Product Backlog and confirms that they are as accurate as possible. The team decides how much work it can successfully take into the sprint based on team size, available hours, and level of team productivity. It is important that the team "pull" items from the top of the Product Backlog that they can commit to deliver in a thirty-day sprint. Pull systems have been show to deliver significant productivity gains in lean product development.

When the Scrum team has selected and committed to deliver a set of top priority features from the Product Backlog, the ScrumMaster leads the team in a planning session to break down Product Backlogs features into sprint tasks. These are the specific development activities required to implement a feature and form the Sprint Backlog. This phase of the Sprint Planning Meeting is time-boxed to a maximum of four hours.

Daily Scrum Meeting

Once planning is complete, the Sprint begins its thirty-day cycle. Each day the ScrumMaster leads the team in the Daily Scrum Meeting. This is a fifteen-minute meeting designed to clarify the state of the Scrum. Each team member speaks to three questions: what did I do yesterday, what did I do today, and what impediments got in my way? While anyone can attend this meeting, only team members who have committed to deliver work to the Scrum are allowed to speak. The goal is to get a global snapshot of the project, discover any new dependencies, address any personal needs of committed individuals, and adjust the work plan in real time to the needs of the day.

Sprint Review Meeting

At the end of a sprint, a Sprint Review Meeting is held. This meeting is time-boxed to a maximum of four hours. The first half of the meeting is set aside to demonstrate to the Product Owner the potentially shippable code that has been developed during the sprint. The Product Owner leads this part of the meeting and invites all interested stakeholders to attend. The state of the business, the market, and the technology are reviewed. The Product Owner determines which items on the Product Backlog have been completed in the Sprint, and discusses with the Scrum team and stakeholders how best to reprioritize the Product Backlog for the next sprint. The goal for the next sprint is defined.

The second half of the Sprint Review Meeting is a retrospective for the Scrum team that is led by the ScrumMaster. The team assesses the way they worked together in the sprint and identifies positive ways of working together that can be encouraged as future practice. the team also identifies the things that could work better and develops strategies for improvement.

After the Scrum Review Meeting, the process begins again. Iterations proceed until enough features have been done to complete or release a product.

Daqui: http://www.scrumalliance.org/pages/scrum_ceremonies