O tema do sétimo episódio de nossa sequência de podcasts é “Lean Software Development”.

Apresentamos alguns conceitos do sistema de produção Toyota (TPS) além dos 7 princípios descritos por Tom e Mary Poppendieck no livro Implementing Lean Software Development.

Nota em 07/05: comentamos sobre a tradução do manifesto ágil para português e citamos o link incorreto no podcast. O link para a tradução oficial encontra-se no “show notes”.


Caso não consiga ver o vídeo acesse nosso canal do Vimeo ou baixe o áudio diretamente.

Data de publicação: 04/05/2010 Tempo: 36:55
Show notes:

Para acompanhar este podcast acesse nossa página do iTunes ou nosso feed em seu leitor favorito.
Aguardamos seu feedback através dos comentários deste post ou pelo e-mail [email protected]
Autor

No tempo em que esteve no time da Bluesoft, Luiz Faias Junior ajudou a criar e a manter a cultura e os valores da empresa, aumentando a equipe de 3 para 40 talentosos engenheiros de software.

6 Comentários

  1. Olá Dado, então, como o testador tem bastante conhecimento de negócio, e participa da reunião de planejamento, ele sabe exatamente o que o desenvolvedor alterou e sabe onde deve testar, por isso não fazemos o tal mapa.
    É claro que para isso deve haver bastante comunicação entre ambos (desenvolvedor e testador), por isso trabalham na mesma sala e estão constantemente conversando a respeito do que foi feito. O tempo entre o desenvolvedor terminar algo e o testador iniciar os testes é geralmente muito curto (apenas alguns minutos ou horas), e o planejamento foi feito no máximo a uma semana atrás, por isso, ambos devem estar com as regras de negócio bem frescas em suas cabeças.
    Em caso de dúvidas maiores, ou algum tipo de imprevisto (algo que não tenha sido levantado no planejamento), entramos em contato com o cliente imediatamente para obter esclarecimentos.
    É importante ressaltar que o testes unitários e de integração são escritos pelo próprio desenvolvedor que muitas vezes pede ajuda ao testador para esclarecer alguma dúvida de negócio. Aqui na Bluesoft, o testador é responsável pelos testes funcionais e de aceitação e seu perfil é mais de negócios de do que técnico.
    Esse até hoje foi o melhor modelo que encontramos. Lembre-se de que não é uma bala de prata e provavelmente não funcionará bem em todas as organizações.
    Grande Abraço.

    • Mais uma vez, fico muito feliz pela resposta.
      Muito bom o método que tu descreveu, vou fazer um documento com essas suas 2 respostas e levarei amanhã mesmo como proposta de mudança, pra galera do meu trampo.
      Sucesso pra vocês. Estamos esperando o próximo podcast
      Abraço
      DADO

  2. Cara, muito obrigado pela resposta. Acho muito legal essa transparências que vocês tem com relação ao desenvolvimento.
    Sem querer abusar, gostaria de saber como as atividade são passadas pro tester. É criado um mapa de teste ou algo do tipo que indica o caminho a ser testado? Se existe, é o desenvolvedor que o escreve?
    Mais uma vez parabéns pelo trabalho e muito obrigado pelos esclarecimentos.
    DADO

  3. Salve galera!
    Mais uma vez obrigado por mais esse episódio. Demorei pra comentar aqui, mas hj, trouxe uma dúvida. Na verdade, uma curiosidade que queria matar e aproveitar pra somar ideias =)
    Enfim, gostaria de saber como vcs lidam com a transição das tarefas para os testers. Vocês criam mapas de testes? Os testers ficam no mesmo espaço físico? Se rolar algum erro, eles reportam imediatamente cara a cara, ou via mail?
    Não sei se estou sendo invasivo demais, mas, to tentando modelar um métodozinho que seja funcional pra essa questão e gostaria da ajuda de vcs. Então, se poderem explicar um pouco dessa mecânica de vcs, ficarei grato ;D
    Abraços e parabéns
    DADO

    • Olá Dado,
      Aqui na Bluesoft, os testadores são profissionais que tem bastante conhecimento de negócio o que ajuda bastante para que o teste seja eficiente. Eles ficam no mesmo espaço físico, na mesma sala, quando uma tarefa volta, ele muda de “testing” para “to do” no kanban, assim que o desenvolver termina a tarefa que está trabalhando, os dois (o testador e o desenvolvedor) trabalham em para resolver o problema endereçado.
      Não se preocupe, nós gostamos de compartilhar o que fazemos e como fazemos as coisas aqui na Bluesoft.

Deixe aqui o seu comentário