Loading ...
Sorry, an error occurred while loading the content.
 

Re: [xprio] Estórias Técnicas

Expand Messages
  • Roger Eduardo
    Olá, no projeto que estou atualmente infelizmente ainda não temos o poder nem de negociar os itens tecnicos (a empresa quer usar ágil mas ainda não usa, e
    Message 1 of 10 , May 6 12:50 PM
      Olá, no projeto que estou atualmente infelizmente ainda não temos o poder nem de negociar os itens tecnicos (a empresa quer usar ágil mas ainda não usa, e ainda tem aquela idéia de que eu fui contratado para fazer a consulta XYZ, fazer um DAO só se der tempo e em último caso). *1
      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...

      2008/5/6 Carlos André <andcss@...>:

      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:

      • Pesquisar a tecnologia X;
      • Melhorar a usabilidade da página Y;
      • Melhorar a performance da página Z;
      • Implementar um proxy reverso;
      • E etc.
      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.

      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.
    • Guilherme Machado Cirne
      Celestino, Tb trabalho na Globo.com e vou discordar um pouco de vc (desculpa!). Na equipe onde trabalho histórias técnicas não são impedimentos.
      Message 2 of 10 , May 7 8:30 PM
        Celestino,

        Tb trabalho na Globo.com e vou discordar um pouco de vc (desculpa!). Na equipe onde trabalho histórias técnicas não são impedimentos. Impedimentos são coisas que não são capazes de serem resolvidas dentro do time. Dependem do trabalho de pessoas que não fazem parte do time. Nesse caso, é o Scrum Master quem atua para remover tais impedimentos.

        Ronan,

        Voltando ao tópico. Realmente, as histórias devem ser escritas do ponto de vista do usuário. Qualquer tarefa técnica só existe (ou só deveria existir) para atender alguma história do usuário. Por exemplo, não devemos ter uma história "Implementar camada de persistência". Isso deve ser uma tarefa dentro de uma história que traga valor para o usuário.

        Mas acho que podemos ser pragmáticos. Realmente existem algumas tarefas técnicas que não "cabem" em nenhuma história. Um exemplo recente da equipe onde trabalho. Tínhamos acabado de começar um projeto novo. Na reunião de planejamento do segundo sprint, o time escreveu a seguinte história (qualquer um pode escrever uma história): "Como desenvolvedor, gostaria de colocar o projeto X no CruiseControl para termos uma integração contínua e assim ajudar a garantir a qualidade do produto". O time explicou à Product Owner do que se tratava essa história. Ela entendeu o que era e isso foi priorizado no segundo sprint.

        Essa história jamais seria escrita por um usuário. E apesar de não ter um valor tão explícito para ele, não deixa de ter um valor, que é garantir a qualidade do produto.

        2008/5/6 Roger Eduardo <roger.eduardo@...>:
        Olá, no projeto que estou atualmente infelizmente ainda não temos o poder nem de negociar os itens tecnicos (a empresa quer usar ágil mas ainda não usa, e ainda tem aquela idéia de que eu fui contratado para fazer a consulta XYZ, fazer um DAO só se der tempo e em último caso). *1
        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...

        2008/5/6 Carlos André <andcss@...>:

        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:

        • Pesquisar a tecnologia X;
        • Melhorar a usabilidade da página Y;
        • Melhorar a performance da página Z;
        • Implementar um proxy reverso;
        • E etc.
        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.

        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.



        --
        Guilherme Machado Cirne
        gcirne@...
      • Celestino Gomes
        No problem Guilherme! :P Também é válida essa abortagem e concordo! Mas quanto a afirmação que Impedimentos são coisas que não são capazes de serem
        Message 3 of 10 , May 8 6:25 AM
          No problem Guilherme! :P

          Também é válida essa abortagem e concordo!

          Mas quanto a afirmação que "Impedimentos são coisas que não são capazes de serem resolvidas dentro do time...", aqui temos 2 níveis de impedimentos: os do time e os da organização. E os do time, somos nós que resolvemos. Não sei se essa é a abordagem correta, mas é como usamos aqui. Se puder, vamos trocar uma idéia sobre isso e, quem sabe, alinhar as idéias. Sou da Equipe do Peleteiro!


          Abraço!

          --
          Celestino Gomes
          http://tinogomes.wordpress.com

          Nenhum de nós é tão bom quanto TODOS NÓS JUNTOS!



          2008/5/8 Guilherme Machado Cirne <gcirne@...>:

          Celestino,

          Tb trabalho na Globo.com e vou discordar um pouco de vc (desculpa!). Na equipe onde trabalho histórias técnicas não são impedimentos. Impedimentos são coisas que não são capazes de serem resolvidas dentro do time. Dependem do trabalho de pessoas que não fazem parte do time. Nesse caso, é o Scrum Master quem atua para remover tais impedimentos.

          Ronan,

          Voltando ao tópico. Realmente, as histórias devem ser escritas do ponto de vista do usuário. Qualquer tarefa técnica só existe (ou só deveria existir) para atender alguma história do usuário. Por exemplo, não devemos ter uma história "Implementar camada de persistência". Isso deve ser uma tarefa dentro de uma história que traga valor para o usuário.

          Mas acho que podemos ser pragmáticos. Realmente existem algumas tarefas técnicas que não "cabem" em nenhuma história. Um exemplo recente da equipe onde trabalho. Tínhamos acabado de começar um projeto novo. Na reunião de planejamento do segundo sprint, o time escreveu a seguinte história (qualquer um pode escrever uma história): "Como desenvolvedor, gostaria de colocar o projeto X no CruiseControl para termos uma integração contínua e assim ajudar a garantir a qualidade do produto". O time explicou à Product Owner do que se tratava essa história. Ela entendeu o que era e isso foi priorizado no segundo sprint.

          Essa história jamais seria escrita por um usuário. E apesar de não ter um valor tão explícito para ele, não deixa de ter um valor, que é garantir a qualidade do produto.

          2008/5/6 Roger Eduardo <roger.eduardo@...>:

          Olá, no projeto que estou atualmente infelizmente ainda não temos o poder nem de negociar os itens tecnicos (a empresa quer usar ágil mas ainda não usa, e ainda tem aquela idéia de que eu fui contratado para fazer a consulta XYZ, fazer um DAO só se der tempo e em último caso). *1
          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...

          2008/5/6 Carlos André <andcss@...>:

          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:

          • Pesquisar a tecnologia X;
          • Melhorar a usabilidade da página Y;
          • Melhorar a performance da página Z;
          • Implementar um proxy reverso;
          • E etc.
          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.

          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.



          --
          Guilherme Machado Cirne
          gcirne@...



        • Ronan Lucio
          Pessoal, Gostaria de agradecer a todos pelas respostas. Realmente foram bastante proveitosas para mim. Obrigado, Ronan
          Message 4 of 10 , May 8 9:46 AM
            Pessoal,

            Gostaria de agradecer a todos pelas respostas.
            Realmente foram bastante proveitosas para mim.

            Obrigado,
            Ronan
          • Jonathas Lima
            Ronan, é bem dentro do que o Rodrigo escreveu, aqui na minha empresa estamos também em processo de implementação do XP, e está existindo a necessidade de
            Message 5 of 10 , May 13 7:35 AM
              Ronan, é bem dentro do que o Rodrigo escreveu, aqui na minha empresa estamos
              também em processo de implementação do XP, e está existindo a necessidade
              de criar cartões técnicos e de infra-estrutura, com isso, a própria equipe
              cria os cartões. Se alguma atividade funcional do sistema, estiver dependendo
              dos cartões técnicos, eles serão implementados anteriormente a funcionalidade,
              caso não seja ultra-urgente, estes cartões técnicos, poderão ser implementados
              ao longo de sua iteração semanal ou quinzenal etc.

              No XP, a equipe pode gerar seus próprios cartões caso sejam necessários.


              >-- Mensagem Original --
              >To: xprio@yahoogroups.com
              >From: "Rodrigo Maia (Fortes Informática)"
              > <rodrigomaia@...>
              >Date: Tue, 06 May 2008 13:53:45 -0300
              >Subject: Re: ** POSSIVEL SPAM ** [xprio] Estórias Té
              > cnicas
              >Reply-To: xprio@yahoogroups.com
              >
              >
              >Ronan,
              >
              >cartões técnicos são super comuns, aqui na empresa adotamos uma outra
              >cor pra ele, só isso.
              >
              >Quando vamos discutir com o cliente o que será feito na semana, reunião

              >de planejamento, explicamos pra ele a importância desses cartões
              >técnicos e usamos, se for necessário, frases do tipo: "isso tem que ser

              >feito com urgência", o cliente sempre compreende a necessidade desses
              >cartões, até porque o dinheiro dele esta em jogo.
              >
              >[]'s
              >
              >Ronan Lucio escreveu:
              >>
              >> 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:
              >>
              >> * Pesquisar a tecnologia X;
              >> * Melhorar a usabilidade da página Y;
              >> * Melhorar a performance da página Z;
              >> * Implementar um proxy reverso;
              >> * E etc.
              >>
              >> 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.
              >>
              >> 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
              >>
              >>
              >
              >
              >--
              >Rodrigo Maia
              >Desenvolvimento
              >Fortes Informática (Fortaleza)
              >Fone: (85) 4005.1111 - Fax: (85) 4005.1115
              >rodrigomaia@...
              >www.fortesinformatica.com.br
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.