Skip to content
Browse files

New post about reducing scope

  • Loading branch information...
1 parent c84a127 commit 10bbb7f8e0f325be43f82127494a017fce59954a @andersondias committed
Showing with 29 additions and 0 deletions.
  1. +29 −0 _posts/2011-03-13-reduzir-escopo-nao-e-pecado.markdown
View
29 _posts/2011-03-13-reduzir-escopo-nao-e-pecado.markdown
@@ -0,0 +1,29 @@
+---
+layout: post
+title: Reduzir escopo não é pecado
+categories: adaptabilidade priorização pt
+---
+Estávamos atrasados. O time se comprometeu com um conjunto de funcionalidades e não atingimos nossa meta. Ainda podia ficar pior. Priorizamos errado e demos mais atenção a funcionalidades de menos importância. Precisávamos urgentemente mudar o rumo para atender às expectativas.
+
+Estávamos trabalhando em uma tarefa e sua funcionalidade foi concluída. Faltava somente colocar algumas informações que poderiam ajudar o usuário a utilizá-la. Não era algo vital. Procurávamos os melhores ícones para as explicações ficarem mais simpáticas. Mas, o problema era um pouco maior. Nos apegamos a detalhes de uma tarefa de baixa prioridade enquanto uma funcionalidade importante ainda não havia sido acabada.
+
+O Sprint havia estourado. Erramos na priorização e nos deixamos levar por detalhes minúsculos. Ao ser informado do erro que havíamos cometido mudamos os esforços da equipe para poder finalizar a tarefa de maior prioridade. Surgiu porém uma dúvida: como fica a tarefa de menor prioridade? Teoricamente ela estava incompleta.
+
+Desenvolvimento de *software* é um processo complexo, não definido. Para gerenciar tal tipo de processo é necessário utilizar processos empíricos de controle<sup>1</sup>. A adaptabilidade é uma das grandes ferramentas para poder se modelar ao [caos emergente](http://akitaonrails.com/2009/07/08/off-topic-agilidade-caos-auto-organizacao) no processo de criação de um sistema.
+
+Schwaber e Beedle<sup>1</sup> defendem que o time tem autoridade para mudar a funcionalidade do Sprint ao passo que a mudança alcance a meta do mesmo. Primeiro é necessário descobrir qual é o mínimo mais simples que atenda a demanda<sup>2</sup>. Depois aprender a reduzir o escopo para atender esse mínimo quando o Sprint está em jogo.
+
+Não entregar tudo o que foi planejado para uma tarefa não indica que a mesma não está pronta para produção. É assim que se pensa ao utilizar metodologias ágeis. As funcionalidades são incrementais. O desenvolvimento é evolutivo. No primeiro Sprint entregamos uma parte funcional que atenda a necessidade, em seguida melhoramos esta funcionalidade.
+
+Mudamos o escopo da funcionalidade. Ela irá ao ar sem alguns detalhes que pensamos inicialmente, mas atenderá à necessidade. Haverão melhoras na mesma num Sprint posterior. A tarefa de maior prioridade está sendo terminada e será entregue no próximo release.
+
+**Sempre que for necessário altere o escopo de uma funcionalidade em prol da meta estabelecida.**
+
+E sempre fique atento à correta priorização das tarefas.
+
+\-\-
+
+Referências:
+
+1. Schwaber e Beedle, *Agile software development with Scrum*
+2. Telles, Vinícius Manhães, *Extreme programming*: aprenda como encantar seus usuários desenvolvendo *software* com agilidade e alta qualidade, pág. 48, 2006

0 comments on commit 10bbb7f

Please sign in to comment.
Something went wrong with that request. Please try again.