scrum_xp_direto_das_trincheiras.txt

Card Set Information

Author:
rivasalmir
ID:
172355
Filename:
scrum_xp_direto_das_trincheiras.txt
Updated:
2012-09-21 13:44:13
Tags:
scrum
Folders:

Description:
Perguntas referentes ao conteúdo do livro scrum direto das trincheiras.
Show Answers:

Home > Flashcards > Print Preview

The flashcards below were created by user rivasalmir on FreezingBlue Flashcards. What would you like to do?


  1. Para que devemos usar a página de informações do sprint?
    Para manter a empresa inteira informada sobre o que esta acontecendo no projeto.(Capítulo 5, Como comunicamos sprints)
  2. Que tipo de informações também podem ser incluídas na página de informações do sprint?
    Informações sobre como a história sera demonstrada. Informações sobre o tempo e o lugar da reunião diária da equipe. Data e local da apresentação dos resultados do sprint, quando ele estiver próximo de acabar. (Capítulo 5, Como comunicamos sprints)
  3. Quando deve-se atualizar a página de informação do sprint?
    O mais cedo possível depois da reunião de planejamento do sprint. E deve ser comunicado a toda empresa.(Capítulo 5, Como comunicamos sprints)
  4. Aonde pode ficar a página de informação do sprint?
    Pode ficar na intranet ou extranet da empresa, pode-se utilizar uma ferramenta wiki. O scrum master deve também afixar uma versão impressa desta página no mural do lado de fora da sala de equipe (ou em local equivalente).(Capítulo 5, Como comunicamos sprints)
  5. Quem cria o sprint backlog?
    O scrum master. (Capítulo 6 - Como fazemos os sprint backlogs)
  6. Quando o sprint backlog deve ser feito?
    Depois da reunião do planejamento do sprint e antes da primeira reunião diária do scrum. (Capítulo 6 - Como fazemos os sprint backlogs)
  7. [Capítulo 6 - Como fazemos os sprint backlogs] Qual o formato mais produtivo do sprint backlog?
    Um quadro de aviso pregado na parede.
  8. [Capítulo 6 - Como fazemos os sprint backlogs] Qual deve ser o tamanho do quadro de aviso que conterá o sprint backlog?
    2x2 ou 3x2 para equipes grandes. A medida esta em metro.
  9. [Capítulo 6 - Como fazemos os sprint backlogs] Qual a dica para o uso de post-it?
    Não esqueça de colá-los com durex ou fita crepe para evitar que caiam.
  10. [Capítulo 6 - Como fazemos os sprint backlogs] Qual a pergunta que deve ser feita antes de adicionar uma coluna no quadro de tarefas?
    Esta coluna é realmente necessária.
  11. [Capítulo 6 - Como fazemos os sprint backlogs] Quando devo adicionar complicações no scrum?
    Quando o custo de não fazê-las for muito alto.
  12. [Capítulo 6 - Como fazemos os sprint backlogs] Como as tarefas são estimadas na maioria dos livros de scrum?
    Em horas.
  13. [Capítulo 6 - Como fazemos os sprint backlogs] Quais os problemas de estimar as tarefas em horas?
    • As estimativas em homem-hora eram muito granulares, e isto provocava uma tendência a estimar muitas tarefas de 1-2 horas e a conseqüente micro gerencia.
    • De qualquer forma, como todos estavam pensando em temos de homens-dias, e simplesmente multiplicavam por 6 antes de escrever homem-hora. “Hmmmm, esta tarefa deve gastar um dia. Bom, tenho que escrever horas, então escrevo 6 horas”.
    • Duas unidades diferentes podem causar confusão. “Esta estimativa é em homem-hora ou homem-dia?
  14. [Capítulo 6 - Como fazemos os sprint backlogs] O que deve acontecer com tarefas que durem menos que 0.5 homem/dia?
    Deve ser eliminada ou somada com outra.
  15. [7 - Como arrumamos a sala da equipe] Aonde costumam ocorrer as discussões mais valiosas e interessantes sobre o design?
    Na frente do quadro de tarefas
  16. [7 - Como arrumamos a sala da equipe] O que é a "parede de design"?
    É um grande quadro-branco contendo os rabiscos de design e esboços (printouts) da documentação de design mais importante (gráficos de seqüências, protótipos de GUI, modelos de domínio, etc).
  17. [7 - Como arrumamos a sala da equipe] Como devem estar dispostas as pessoas de um equipe scrum?
    A equipe deve estar sempre junta, mantenha a equipe junta.
  18. [7 - Como arrumamos a sala da equipe] O que significa sentar a equipe junto?
    • Audibilidade - Qualquer um da equipe pode conversar com o outro sem gritar ou sair da mesa.
    • Visibilidade - Todos da equipe podem ver todos os demais. Cada um da equipe consegue ver o quadro de tarefas. Não necessariamente perto o suficiente para lê-lo, mas pelo menos para vê-lo.
    • Isolamento - Se toda equipe de repente levantar e se envolver em uma espontânea e animada discussão sobre implementação, não haverá ninguém de fora da equipe perto o suficiente para ser perturbado. E vice-versa.
  19. [7 - Como arrumamos a sala da equipe] Qual a distância que se deve estar do produtc owner?
    O product owner deve estar suficientemente perto para permitir que a equipe possa ir onde esta e perguntar qualquer coisa, e também para que ele possa ir ao quadro de tarefas. Mas ele nãio deve estar junto da equipe.
  20. [7 - Como arrumamos a sala da equipe] Qual a distância que deve estar o gerente e o coach?
    A uma distância onde possa se envolver com a equipe mas que não fique lá permanentemente. Ele deve deixar a equipe se autogerenciar.
  21. [8 - Como fazemos reuniões diárias] Como são chamadas as reuniões diárias do scrum?
    Daily scrums.
  22. [8 - Como fazemos reuniões diárias] As reuniões diárias devem obedecer a uma rígida disciplina? Qual disciplina?
    Sim. Hora, local e duração exatos, sempre.
  23. [8 - Como fazemos reuniões diárias] Qual o melhor lugar para fazer a daily scrums?
    Na frente do quadro de tarefas.
  24. [8 - Como fazemos reuniões diárias] Qual a melhor forma de fazer uma daily scrum?
    De pé
  25. [8 - Como fazemos reuniões diárias] Quando atualizamos o quadro de tarefas?
    Durante a reunião diária/daily scrum. Conforme cada pessoa descreve o que fez ontem,o que fará hoje, um item não planejado e quando atualiza uma estimativa de prazo. O scrum master pode fazer este trabalho enquanto as pessoas conversam.
  26. [8 - Como fazemos reuniões diárias] Qual a política de atualização do quadro de tarefas de algumas equipe?
    Algumas equipes têm a política de que cada pessoa deve atualizar o quadro de tarefas antes de cada reunião.
  27. [8 - Como fazemos reuniões diárias] O que é importante com relação a atualização do sprint backlog?
    Que toda equipe se envolva na atualização dele.
  28. [8 - Como fazemos reuniões diárias] Quais as desvantagens de escolher um único mantenedor para o quadro de tarefas?
    • Gasto de tempo do mantenedor - O mantenedor gasta tempo demais administrando essas coisa, ao invés de apoiando a equipe e removendo impedimentos.
    • Perda de noção da situação do sprint - Os membros da equipe perdem a noção do status do sprint, uma vez que o sprint backlog não é algo com o que eles precisem se preocupar. Essa falta de feedback reduz a agilidade e o foco da equipe.
  29. [8 - Como fazemos reuniões diárias] Como podemos garantir que qualquer membro da equipe atualize facilmente o sprint backlog?
    Definindo-o bem.
  30. [8 - Como fazemos reuniões diárias] Quando deve-se atulizar o gráfico de burndown?
    Impediatamente após a reunião diária/daily scrum.
  31. [8 - Como fazemos reuniões diárias] De que forma deve ser atualizado?
    Totalizando estimatimativas de prazo das histórias que faltam ficar prontas e marcando um novo ponto no sprint burndown.
  32. [8 - Como fazemos reuniões diárias] Como punir os atrasados para a reunião?
    Criando um pote de moedas e notas e determinando uma multa fixa para eles mesmo que avisem.
  33. [8 - Como fazemos reuniões diárias] Quando devemos punir pessoas que atrasam?
    Quando isso ocorre reqüentemente na equipe.
  34. [8 - Como fazemos reuniões diárias] O que fazer com a pergunta "não sei o que fazer hoje"?
    • Deixa todos falarem, verifico se o quadro de tarefas esta todo ok e pergunto ao dono da pergunta; sabe o que fazer agora?
    • persistindo, scrum master avalia possibilidade de programação em par
    • persistindo, scrum master pergunta quem quer demonstrar a release para a gente? e busca saber que tarefas faltam para apresentação da release e passa para o dono da pergunta.
    • persistinto, técnica da vergonha (ir para casa ou simplesmente sentar e vê se alguém precisa de ajuda)
    • persistindo, atribua uma tarefa a pessoa
    • persistindo, pressione por uma resposta, vinculando o fim da reunião a decisão deles.
    • persistindo, remova a pessoa do grupo e dê um treinamento forte.
    • persistindo, avalia a importância da pessoa para equipe, senão for importante, remova da equipe
    • se for importante, arrume um pastor para ela
  35. Qual o outro nome da apresentação de sprint?
    Revisão de sprint.[Capítulo 9 - Como fazemos apresentações de sprint]
  36. Qual o outro nome da revisão de sprint?
    Apresentação de sprint.[Capítulo 9 - Como fazemos apresentações de sprint]
  37. Motivos para que todos os sprints devem terminar com uma apresentação?
    • A equipe ganha crédito por suas realizações. Eles se sentem bem.
    • Outros aprendem o que sua equipe está fazendo.
    • A apresentação atrai feedback vital dos stakeholders.
    • Apresentações são (ou deveriam ser) um evento social onde equipes diferentes podem interagir umas com as outras e discutir seu trabalho. Isso tem muito valor.
    • Fazer uma apresentação força a equipe a realmente terminar as coisas e liberá-las (mesmo que seja apenas em um ambiente de teste). Sem apresentações, nós continuamos recebendo imensas pilhas de coisas 99% prontas. Com apresentações nós podemos ter menos itens prontos, mas estes itens estarão realmente prontos, o que é (no nosso caso) muito melhor do que termos uma pilha inteira de coisas que estão apenas parcialmente prontas e que irão poluir o próximo sprint.
    • [Capítulo 9 - Como fazemos apresentações de sprint]
  38. Qual o efeito de uma equipe ser forçada a apresentar um sprint que esteja mais ou menos terminado?
    Apesar de ser um remédio amargo no próximo sprint a equipe vai se dedicar de fato a terminar tudo.[Capítulo 9 - Como fazemos apresentações de sprint]
  39. Qual o checklist que devemos utilizar para apresentação de sprint?
    • Certifique-se de apresentar claramente o objetivo do sprint. Se houver pessoas na apresentação que não sabem absolutamente nada sobre seu produto, utilize alguns minutos para descrevê-lo.
    • Não gaste muito tempo preparando a apresentação, especialmente evite enfeitar demais as apresentações. Corte tudo que não interessa e foque-se apenas em demonstrar código realmente funcionando.
    • Mantenha um bom ritmo, isto é, foque sua preparação em fazer com que a apresentação seja rápida ao invés de bonita.
    • Mantenha a apresentação em um nível orientado ao negócio, deixe de fora detalhes técnicos. Foque em “o que nós fizemos” ao invés de “como nós fizemos”.
    • Se possível, deixe a audiência testar o produto.
    • Não demonstre um monte de correções de pequenos bugs e funcionalidades triviais. Mencione-as mas não as demonstre, já que isso geralmente leva muito tempo e desvia o foco das estórias mais importantes.
    • [Capítulo 9 - Como fazemos apresentações de sprint]
  40. Como demonstrar uma coisa não demonstrável?
    • Procure ver que fatos (relatórios, testes de stresse) levaram você a concluir que a tarefa estava pronta e mostre-os de maneira objetiva.
    • [Capítulo 9 - Como fazemos apresentações de sprint]
  41. O que é o mais importante em uma retrospectiva de sprint?
    Assegurar que elas aconteçam.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  42. Qual o grau de importância da retrospectiva para o scrum?
    É apenas menos que a reunião de planejamento do sprint.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  43. Um bom motivo para fazer a reunião de retrospectiva do sprint?
    Idéias são melhores aceitas pela equipe quando saem dela mesmo.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  44. Qual a pior descoberta de equipes que não fazem retrospectivas?
    Que cometem os mesmo erros repetidamente.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  45. Como organizar as retrospectivas?
    • Nós alocamos 1 a 3 horas dependendo de quanto a discussão já estiver adiantada.
    • Participantes: o product owner, a equipe toda, e eu mesmo (Scrum master).
    • Nós vamos para uma sala fechada, ou um confortável sofá de canto, um terraço, ou algum outro lugar como estes. Onde nós pudermos não ter interrupções.
    • Nós geralmente não fazemos retrospectivas no espaço de trabalho da equipe, pois as pessoas tendem a perder a atenção.
    • Alguém é designado como secretário.
    • O Scrum master mostra o sprint backlog e, com a ajuda da equipe, resume o sprint. Eventos e decisões importantes, etc.
    • Nós fazemos “as rodadas”. Cada pessoa tem a chance de dizer, sem ser interrompido, o que eles acharam que foi bom, o que eles acharam que poderia ter sido melhor, e o que eles gostariam de fazer de forma diferente no próximo sprint.
    • Nós comparamos a velocidade estimada com a velocidade realizada. Se existir uma grande diferença nós tentamos analisar o motivo.
    • Quando o tempo já está quase acabado, o Scrum master tenta resumir as sugestões concretas sobre o que nós poderemos fazer melhor no próximo sprint.
  46. O que deve estar em foco durante a reunião de retrospectiva de sprint?
    A pergunta "o que nós podemos fazer melhor no próximo sprint". [Capítulo 10 - Como fazemos retrospectivas de sprints]
  47. Que ferramentas podemos utilizar para ajudar na reunião de retrospectiva do sprint?
    Um quadro com três colunas:bom, poderia ter sido melhor e melhorias. E uma votação sobre que atitudes concretas tomar. após preencher o quadro de acordo com cada história. É importante não ser ambicioso demais na escolha das próximas melhorias.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  48. Qual a melhor forma de divulgar as lições aprendidas?
    Usando uma pessoa como "ponte de conhecimento" de maneira informal.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  49. Qual a característica de um boa "ponte de conhecimento"?
    • Ser bom ouvinte.
    • Se a retrospectiva estiver em muito silêncio, ele deve estar preparado para fazer perguntas simples mas estratégicas para estimular a discussão do grupo. Por exemplo: "se você pudesse retornar no tempo e refazer o mesmo sprint por 1 dia, o que seria feito diferente?"
    • Deve estar disposto a investir tempo visitando todas as retrospectivas de todas as equipes.
    • Deve estar em algum tipo de posição de autoridade, para que possa agir em sugestões melhorias que estejam fora do controle da equipe.
    • [Capítulo 10 - Como fazemos retrospectivas de sprints]
  50. Quais as situações mais comuns levantadas durante a reunião de retrospectiva do sprint?
    • “Nós deveríamos ter gasto mais tempo quebrando as estórias em sub-itens e tarefas”
    • “Interferências externas demais”
    • “Nós nos comprometemos com coisas demais e só metade está pronta”
    • “Nosso ambiente é barulhento e bagunçado demais”
    • [Capítulo 10 - Como fazemos retrospectivas de sprints]
  51. Qual a solução para: “Nós deveríamos ter gasto mais tempo quebrando as estórias em sub-itens e tarefas”?
    Isto é bem comum. Todos os dias na reunião diária, membros da equipe se pegam dizendo: “Eu realmente não sei o que fazer hoje”. Então após cada reunião diária você gasta mais tempo tentando encontrar as tarefas concretas. Geralmente é mais eficaz adiar isto para um momento mais oportuno.Ações típicas: Nenhuma. A equipe provavelmente encontrará uma solução por ela mesma durante o próximo planejamento do sprint. Se isto acontece frequentemente, aumente o tempo do planejamento do sprint.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  52. Qual a solução para: “Interferências externas demais”?
    • Peça à equipe para reduzir o fator de foco no próximo sprint, assim terão um plano mais realista
    • Peça à equipe para recordar melhor as interferências no próximo sprint. Quem interrompeu, quanto tempo tomou. Será mais fácil resolver o problema depois.
    • Peça à equipe para concentrar as interferências no scrum master ou product owner
    • Peça à equipe para designar uma pessoa para ser o “goleiro”. Todas as interrupções serão repassadas à ele, assim o resto da equipe pode se concentrar. Pode ser o scrum master ou ser revezado entre o resto.
    • [Capítulo 10 - Como fazemos retrospectivas de sprints]
  53. Qual a solução para: “Nós nos comprometemos com coisas demais e só metade está pronta”?
    Ações típicas: nada. A equipe provavelmente não vai se comprometer com coisas demais no próximo sprint. Ou no mínimo não errar por tanto.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  54. Qual a solução para “Nosso ambiente é barulhento e bagunçado demais”?
    Ações típicas:Tente criar um ambiente melhor, ou tire a equipe do local. Alugue um quarto de hotel, Qualquer coisa. Veja pg 59 “Como arrumamos a sala da equipe” ).Se não for possível, diga à equipe para diminuir o fator de foco no próximo sprint, e deixar claro que isso se deve ao ambiente barulhento e bagunçado. Espera-se que que isto faça o product owner tomar alguma atitude sobre isto.[Capítulo 10 - Como fazemos retrospectivas de sprints]
  55. Como criar intervalos de sprint?
    • Criar intervalo entre as reuniões de retrospectivas do sprint e a próxima reunião de planejamento do sprint.
    • Criar "lab days"
    • Ter um "lab day" por mês para toda a empresa
    • [Capítulo 11 - Intervalo entre sprints]
  56. Qual a saída para utilizar scrum com contratos de preço fixo?
    Planejar vários sprints de uma vez.[Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  57. Como fazer os planejamentos destes scripts?
    • Defina seus critérios de aceitação
    • Faça estimativas de tempo para os itens mais importantes
    • Estime velocidade
    • Junte tudo num plano de release
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  58. O que são os critérios de aceitação?
    É uma classificação simples de acordo com que níveis de importância de cada item do product backlog de acordo com o contrato.[Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  59. Como são feitos as estimativas de tempo para os itens mais importantes?
    • Deixa a equipe fazer as estimativas
    • Não faça com que eles gastem tempo demais
    • Certifique-se de que eles tenham entendido que as estimativas de tempo são estimativas cruas, não compromissos
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  60. Qual deve ser o procedimento do product owner durante a reunião de estimativas de tempo?
    • Explica cada história
    • Informa o tempo da reunião
    • Deixa a equipe trabalhar permanecendo na sala para esclarecer dúvidas
    • Cobra da equipe sempre o "preenchimento" do item "como apresentar" de cada estória
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  61. Qual o cuidado que a equipe deve ter?
    • Deixar claro para o product owner o impacto destas reuniões no seu sprint.
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  62. O que fator de foco?
    • Tempo que a equipe gasta focando na execução da estória em questão.
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  63. Como fazer a adaptaçãop do plano de release?
    • Após cada sprint observemos a velocidade daquele sprint.
    • Revise e atualiza o plano de release de acordo com a velocidade observada.
    • Revise e atualize o plano de release de acordo com possíveis melhorias no fator de foco.
    • [Capítulo 12 - Como fazemos o planejamento de release e contratos com preço fixo]
  64. Onde é o foco de scrum?
    O Scrum é focado nas práticas de gerenciamento e organização[Capítulo 13 - Como combinamos scrum e xp]
  65. Onde o XP é focado?
    O XP é focado nas tareas de programação mesmo.[Capítulo 13 - Como combinamos scrum e xp]
  66. Quais as práticas de XP utilizadas pelo autor?
    • Programação em par
    • Desenvolvimento Orientado a Testes (TDD)
    • Design incremental
    • Integração contínua
    • Propriedade coletiva do código
    • Ambiente de trabalho informativo
    • Padrão de codificação
    • Ritmo Sustentável / Trabalho energizado
    • [Capítulo 13 - Como combinamos scrum e xp]
  67. Conclusões sobre programação em par?
    • Programação em par aumenta a qualidade do código
    • Programação em par aumenta o foco da equipe (por exemplo:quando o par lhe diz: “Ei, estas coisas realmente são necessárias para este sprint?)
    • Surpreendentemente muitos desenvolvedores que são fortemente contra programação em par nunca tentaram antes e rapidamente aprendem a gostar uma vez que experimentam.
    • Programação em par é cansativa e não deve ser feito todos os dias
    • Trocar os pares freqüentemente é bom.
    • Programação em par nivela o conhecimento da equipe. Surpreendentemente de forma rápida também.
    • Algumas pessoas simplesmente não se sentem confortáveis com programação em par. Não jogue fora um excelente programador simplesmente porque ele não se sente confortável com programação em par
    • Revisão de código é uma alternativa válida para a programação em par.
    • O “navegador” (o cara que não está digitando) deve ter um computador para si próprio. Não para ser usado no desenvolvimento, mas para pequenas atividades quando necessário, navegar na documentação enquanto o “piloto” (o cara nos teclados) o espera, etc.
    • Não force as pessoas a praticarem a programação em par. Encoraje as pessoas e forneça as ferramentas corretas, mas deixeas experimentar por si mesmas.
    • [Capítulo 13 - Como combinamos scrum e xp]
  68. O que é TDD?
    Desenvolvimento orientado a testes significa que você escreve um teste automatizado, então escreve apenas código suficiente para fazê-lo passar, então você refatora o código primeiramente para melhorar a legibilidade e remover duplicação. Enxague e repita.[Capítulo 13 - Como combinamos scrum e xp]
  69. Quais as reflexões qu o autor faz sobre TDD?
    • TDD é difícil. Leva um tempo para o programador pegar o jeito. Na verdade, em muitos casos não importa quanto você ensina, treina e demonstra - em muitos casos a única maneira de um programador "pegar o jeito" é fazendo ele programar em par com alguém que é bom em TDD. Contudo, uma vez que pega o jeito, normalmente é severamente infectado e nunca mais irá querer trabalhar de outra forma.
    • TDD tem um efeito profundamente positivo no design do sistema.
    • Leva tempo para deixar o TDD efetivamente pronto e funcionando em um novo produto, especialmente em testes de integração de caixa-preta, mas o retorno de investimento é rápido.
    • Tenha certeza que você investe o tempo necessário para tornar mais fácil escrever os testes. Isso significa obter as ferramentas certas, educar as pessoas, prover o utilitário de classes ou base de classes certo, etc.
    • [Capítulo 13 - Como combinamos scrum e xp]
  70. Quais as ferramentas de TDD sugeridas pelo autor?
    • JUnit / httpUnit / jWebUnit. Estamos considerando TestNG e Selenium.
    • HSQLDB como BD embutido na memória para fins de teste.
    • Jetty como container web embutido na memória para fins de testes.
    • Cobertura para métricas de cobertura de testes.
    • Spring framework para ligação dos diferentes tipos de fixtures de teste (com mocks, sem mocks, com banco de dados externo, com banco de dados na memória, etc).
    • [Capítulo 13 - Como combinamos scrum e xp]
  71. O que é design incremental?
    Significa manter o design simples desde o início e melhorá-lo continuamente, ao invés de tentar deixá-lo perfeito desde o início e então congelá-lo.[Capítulo 13 - Como combinamos scrum e xp]
  72. O que é Integração contínua?
    Integrar todo o produto a cada mudança.[Capítulo 13 - Como combinamos scrum e xp]
  73. O que propriedade coletiva do código?
    É a caracteristica de num projeto qualque programador poder melhorar o código a qualquer tempo.[Capítulo 13 - Como combinamos scrum e xp]
  74. O que é Ambiente de trabalho informativo?
    Todas as equipes tem acesso a quadros brancos e os usam.[Capítulo 13 - Como combinamos scrum e xp]
  75. O que é padrão de codificação?
    Pequenas regras , que vinculada a estudos existentes, ajudam a criar um código mais legível sem engessar os programadores.[Capítulo 13 - Como combinamos scrum e xp]
  76. Cite alguns exemplos de padrão de codificação
    • A convenção de codificação da Sun: http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html
    • Nunca, jamais, nem pense em capturar exceções sem logar o stack trace ou rethowing. log.debug() é uma boa, mas não perca o stack trace.
    • Use a dependência baseada em métodos setter para desacoplar as classes umas das outras. (exceto quando um acoplamento forte for desejável).
    • Evite abreviações. Abreviações bem conhecidas como DAO são bem-vindas.
    • Os métodos que retornam collections ou arrays não devem retornar nulo. Retorne coleções ou arrays vazios ao invés de nulo.
    • [Capítulo 13 - Como combinamos scrum e xp]
  77. O que é ritmo sustentável/trabalho energizado?
    Muitos livros sobre desenvolvimento ágil de software dizem que horas extras são anti-produtivas no desenvolvimento de software.[Capítulo 13 - Como combinamos scrum e xp]
  78. O que se entende por fase de teste de aceitação?
    Todo o período de teste e re-release.[Capítulo 14 - Como fazemos testes]
  79. Como minimizar a fase de testes de aceitação?
    • Maximizando a qualidade do código entregue pela equipe Scrum
    • Maximizando a eficiência do trabalho de teste manual (isto é, encontrar os melhores testadores, dar-lhes as melhores ferramentas, certificar-se de que eles lhe avisam quando houver tarefas que consomem muito tempo e que podem ser automatizadas [Capítulo 14 - Como fazemos testes]
  80. Como maximizar a qualidade de código entregue pela equipe scrum?
    • Coloque os testadores na equipe scrum (testadores mesmo).
    • E o testador que diz que esta pronto.
    • Faça menos a cada sprint
    • [Capítulo 14 - Como fazemos testes]
  81. O que o testador faz quando não tem nada para testar?
    • Escreve especificações de teste
    • Prepara um ambiente de teste
    • Nas equipes que utilizam TDD, ele deve fazer par com os programadores que estão escrevendo testes
    • Se nada disso for possível a equipe de buscar tarefas onde o testador possa ajudar de maneira indireta a equipe
    • [Capítulo 14 - Como fazemos testes]
  82. Dê exemplos de tarefas que podem ser feitas pelo Sr.T?
    • Preparar um ambiente de teste.
    • Esclarecer requisitos
    • Discutir detalhes de deploy com a operação
    • Escrever documentos de deploy (release notes, RFC, ou qualquer outro que sua empresa use)
    • Contatar recursos externos (projetistas de interface com usuário,por exemplo).
    • Melhorar os scripts de build
    • Mais quebras de estórias em tarefas
    • Identificar perguntas-chave dos desenvolvedores e conseguir a resposta para elas.
    • [Capítulo 14 - Como fazemos testes]
  83. O que fazer se o Sr.T tornar-se um gargalo?
    Transforme todo o resto da equipe em ajudantes do sr. T. Ele decide qual funcionalidade ele próprio precisa fazer e delega as outras para o restante da equipe.[Capítulo 14 - Como fazemos testes]
  84. Como aumentar a qualidade fazendo menos sprint?
    • Coloque as histórias de formas mais simples.
    • Menos estórias nos sprints
    • [Capítulo 14 - Como fazemos testes]
  85. Os testes de aceitação deveriam fazer parte do sprint?
    A maioria das equipes acham que não, por duas razões:Um sprint tem um limite de tempo e se você tem várias equipes trabalhando no mesmo produto, o teste manual de aceitação deve ser seguido combinado com o trabalho de ambas equipes.[Capítulo 14 - Como fazemos testes]
  86. Mostre algumas formas de evitar os problemas gerados por ciclo de sprint x ciclos de teste de aceitacao.
    • Não inicie a construção de coisas novas antes das coisas antigas estarem em produção
    • OK para começar a implementar novas funcionalidades, mas priorizar colocar as coisas antigas em produção
    • Foco em construir coisas novas
  87. Quais os acontecimentos no caso de utilizar "Não inicie a construção de coisas novas antes das coisas antigas estarem em produção"?
    Ter que adicionar um período de liberação sem um espaço de tempo fixo entre cada sprint, onde faríamos apenas teste e depuração até que pudéssemos realizar um release em produção. Isso quebra o ritmo da equipe. [Capítulo 14 - Como fazemos testes]
  88. Quais os acontecimentos no caso de usar "OK para começar a implementar novas funcionalidades, mas priorizar colocar as coisas antigas em produção"?
    Basicamente quando terminamos um sprint, nós vamos para o próximo. Mas esperamos gastar algum tempo deste próximo sprint consertando coisas do último sprint. Se os próximos sprints se tornarem severamente prejudicados por causa do gasto excessivo de tempo na correção de bugs do último sprint, nós avaliamos por que isto aconteceu e como podemos melhorar a qualidade. Nós procuramos ter a certeza de que sprints são duradouros o suficiente para não serem impactados por um punhado de tempo gasto concertando bugs do sprint anterior. Durante as reuniões de planejamento do sprint, nós ajustamos o fato de foco baixo o suficiente para considerar o tempo que gastamos concertando os bugs do último sprint.[Capítulo 14 - Como fazemos testes]
  89. Qual o problema de ter "foco em construir coisas novas"?
    É uma doença relacionada a pressão do projeto. Muitos gerentes realmente não compreendem que quando toda a codificação terminar, você geralmente estará longe do release de produção. Pelo menos para sistemas complexos. Então o gerente (ou product owner) pede para a equipe continuar adicionando novas funcionalidades enquanto a mochila de código das coisas “quase prontas” se torna cada vez mais e mais pesada, diminuindo a velocidade de tudo.[Capítulo 14 - Como fazemos testes]
  90. O que é "expor o elo mais fraco da sua corrente" e como superar isso?
    • Digamos que o teste de aceitação seja o seu elo mais fraco. Você tem pouquíssimos testadores ou o período de testes demora mais devido à baixa qualidade do código. Digamos que a equipe de testes de aceitação possa testar no máximo 3 funcionalidades por semana (não, nós não usamos “funcionalidades por semana” como métrica; só estou dando um exemplo). E digamos que seus desenvolvedores produzam 6 novas funcionalidades por semana. É tentador para os gerentes ou product owners (ou talvez mesmo para a equipe) prever o desenvolvimento de 6 novas funcionalidades por semana.
    • Ao invés disso, planeje 3 novas funcionalidades por semana e invista o restante do tempo para aliviar o gargalo de testes. Exemplo:
    • Aloque alguns desenvolvedores como testadores (Ah, eles irão amá-lo por isso…)
    • Implemente ferramentas e scripts que facilitem os testes.
    • Adicione mais código que automatize os testes.
    • Aumente o tamanho do sprint e tenha os testes de aceitação incluídos nele.
    • Defina alguns sprints como “sprints para teste” onde a equipe inteira atuará como uma equipe de testes de aceitação.
    • Contrate mais testadores (mesmo que isso signifique dispensar alguns desenvolvedores).
    • [Capítulo 14 - Como fazemos testes]

What would you like to do?

Home > Flashcards > Print Preview