Having problems with message search?
Agora na última empresa que trabalhei e onde aprendi o pouco que sei, o que faziamos era manter o cliente perto e ciente de tudo, tentando passar o valor que a "qualidade interna" trazia (ganho de tempo em nos próximos itens, desempenho, etc...)
Dai no planning game traziamos esses necessidades a tona, e todos juntos pesavamos o que poderia ser feito.
O clima era mais ou menos assim, o cliente geralmente queria colocar coisas novas + as historias tecnicas no proximo sprint... mas com calma e um pouco de humor explicavamos que cada um de nós só tinhamos 2 braços... rsrs e por ai ia até que depois da 4ª iteração ele meio que aprendeu nossa "velocidade" e as coisas fluiram melhor...
Minha dica é, mantenha o cliente perto, se possível na mesma sala, para ele ver que a equipe trabalha e está jogando a favor não contra, assim ele aceita melhor as estorias tecnicas.
Abcs
Roger Eduardo.
*1: Então, por falar nisso vou fazer uma apresentação para "um pessoal que se acha importante" aqui na empresa, logo irei mandar uns ppt para vocês me ajudarem...
Ronan,
Aqui no trabalho o que nós fazemos é passar para nosso cliente, em nossas reuniões agendadas, todas as funcionalidades fechadas no ciclo e as "tarefas técnicas" são sinalizadas para ele também no intuito de ficar ciente.
Até o momento tem andado bem pois o cliente tem recebido suas funcionalidades e esse, sabendo quais são os impedimentos técnicos, que por ventura pode causar algum tipo de atraso, não cai na "desconfiança".
Bem, acho que vale o bom senso, pode-se colocar as "tarefas técnicas" como funcionalidades para equipe dentro de um ciclo e vale sinalizar o cliente sobre impedimentos técnicos encontrados.
Sds,
André Santiago
http://infotecfatos.blogspot.com/2008/5/6 Celestino Gomes <tinorj@...>:
Olá Ronan,
Já passei por isso na Ancar. O que fazíamos era explicar ao cliente a real necessidade de tais "tarefas técnicas" e com certeza, ele, percebendo a necessidade, terá o bom censo de colocar no planejamento da iteração. Usávamos um cartão escrito "Tarefas Técnicas" (explicando em português claro e não em geekês) o que iria alí dentro, com estimativa, e assim fica claro para o cliente (não geek) que aquilo é coisa de nerd (nem sempre). E não um cartão como: "Implementar um proxy reverso" e etc...
Agora, aqui na Globo.com, como usamos Scrum (calma gente, sei que estou na lista do XP Rio, mas é para ajudar :P), essas estórias são chamadas de impedimentos (por não ter valor de negócio, mas ser importante para o andamento do Sprint) que, por conseqüência, entram no Sprint. Mas sempre com o bom censo entre os desenvolvedores e o cliente, senão, nós desenvolvedores, colocaríamos tudo como impedimento para poder fazer na frente. hehehe
[ ]s
--
Celestino Gomes
http://tinogomes.wordpress.com
Nenhum de nós é tão bom quanto TODOS NÓS JUNTOS!2008/5/6 Ronan Lucio <listas@...>:Pessoal,
Aprendi que em XP as Estórias devem ser escritas do ponto de vista "do usuário".
Cada Estória deve fornecer algum valor "para o usuário".
Aqui na empresa estamos em processo de adoção da XP.
Estamos implantando XP em um software já existente, porém, em continuo desenvolvimento.
Com isso temos, também, tarefas (técnicas) do tipo:
São tarefas que não poderiam ser criadas pelo cliente. Não representam um Requisito Funcional do projeto, porém, estão tão ligadas quanto, ao sucesso do mesmo.
- Pesquisar a tecnologia X;
- Melhorar a usabilidade da página Y;
- Melhorar a performance da página Z;
- Implementar um proxy reverso;
- E etc.
Na realidade não temos um cliente real dentro da empresa. Precisamos trabalhar com pessoas que conheçam o negócio e representem o papel dos clientes.
Com isso é comum termos Estórias escritas pela a própria equipe, porém, a priorização delas é de responsabilidade desses representantes.
Como vocês vêem esta situação e como costumam lidar com essa questão?
[]s
Ronan
--
Att,
Roger Eduardo.
Offline 
Send Email