essencial a presença de alguém com um perfil de negócios próximo para ajudá-los a
compreender o que de fato é de valor e o que não é.
Quanto mais cedo for possível agregar valor ao cliente, melhor será o resultado.
Quando o cliente recebe o software funcionando em um curtos intervalos de tempo,
além de ganhar vantagem competitiva, o trabalho em progresso também diminui
(WIP). Consequentemente, a quantidade de trabalho parcialmente pronto diminuirá
o desperdício, conforme abordado anteriormente.
A Dell Computadores, por exemplo, não acumula estoques e entrega pedidos
personalizados em menos de uma semana e, exatamente por não possuir estoques
acumulados, pode oferecer a seus clientes novos produtos antes de seus concorrentes,
sem ter que se preocupar em queimar estoques de produtos antigos.
Assim como a faz a Dell, uma equipe de software que entrega rapidamente e man-
tém um baixo nível de trabalho parcialmente pronto pode responder rapidamente a
novas necessidades que venham a surgir sem se preocupar em deixar o trabalho que
já foi começado para trás.
As organizações que entregam rapidamente estruturam-se de forma que as pes-
soas saibam como o trabalho deve ser feito sem que alguém precise dizer a elas o
que fazer [48]. Essas pessoas devem ser capazes de resolver problemas e fazer adap-
tações para responder a mudanças. Essas diretrizes são profundamente aplicadas na
Toyota.
Entregar rapidamente é complementar ao princípio de tomar decisões no úl-
timo momento possível. Por exemplo: se o cliente recebe entregas de software toda
semana, não precisa decidir sobre o que será feito daqui a nove meses. Entretanto,
32
Casa do Código
Capítulo 3. Foco em Valor para o Negócio
se o cliente recebe software somente a cada três meses, então precisará decidir sobre as novas funcionalidades no mínimo três meses antes de poder vê-las em funcionamento.
Nesse capítulo abordaremos como equipes podem aplicar práticas ágeis para ga-
rantir que o cliente receba valor de negócio com frequência através da entrega iterativa de software em funcionamento.
3.1
Disseminando a Visão do Projeto
Projetos sempre nascem de ideias de pessoas. Ideias que, geralmente, nascem de ten-
tativas de tornar um determinado processo mais eficiente. Seus donos são chamados
de visionários, porque eles possuem a visão do projeto e, entendem a necessidade e
conhecem o problema que o software deve resolver. A visão revela para onde o pro-
jeto está indo e por que ele está indo para lá.
Todo projeto possui um ou mais visionários, alguém que conseguiu enxergar
uma necessidade e teve uma ideia de solução para suprir essa necessidade. Ainda
que um projeto possua muitos visionários, é necessário que alguém tome a responsa-
bilidade de promover e comunicar essa visão à equipe de desenvolvimento e a todos
os outros interessados no projeto.
Esse papel, geralmente, é de responsabilidade do gerente de projetos, do próprio
cliente, ou de alguém que represente o cliente. No método Scrum, por exemplo, a
visão do projeto é responsabilidade do Product Owner.
É muito importante que o visionário esteja bem próximo à equipe de desenvol-
vimento para esclarecer as frequentes dúvidas que surgem ao longo do projeto. Por
isso, um dos princípios do método XP é ter o Cliente Presente. Uma vez que todos forem contagiados com a visão do projeto, as chances de sucesso se tornam muito
maiores.
Há três perguntas essenciais que o visionário precisa comunicar à equipe:
1) Que objetivo o projeto deve atingir?
2) Por que esse projeto agregará valor?
3) Como medir se o projeto foi bem sucedido?
Para que a equipe possa desenvolver um software alinhado com a visão do pro-
jeto, é necessário que a visão esteja sempre acessível para todos, por isso a importância do visionário estar presente na equipe.
33
3.1. Disseminando a Visão do Projeto
Casa do Código
Muitas equipes mantêm uma breve descrição da visão, como por exemplo, a res-
posta das três perguntas acima, em um wiki ou portal interno, ou até mesmo im-
presso e anexado ao quadro da equipe. O importante é que esteja ao alcance de
todos.
Os visionários devem estar presentes nos momentos de tomada de decisão, nas
reuniões de planejamento, nas apresentações de demonstração das iterações ou reu-
niões de revisão. Se isso não acontecer, provavelmente a equipe não entenderá o
propósito do produto que estão desenvolvendo. Poderíamos comparar isso a um
médico que faz uma cirurgia, que não sabe de que mal está tentando livrar o paci-
ente.
Equipes de desenvolvimento de software tomam milhares de pequenas decisões
todos os dias, e sem uma boa visão geral e contexto do que está sendo construído, é muito difícil tomar boas decisões.
Como grande parte das equipes ágeis adotam um único representante da visão
do produto, de agora em diante, o visionário será referido como Product Owner ou
PO.
Será que todos estão na mesma página?
Marc Benioff, CEO da Salesforce.com, conta que um certo dia esta-