design em processo ágil

5

Recentemente, tive uma entrevista com a equipe de desenvolvimento de uma empresa. A equipe usa o ágil + TDD. O exercício de código implementa uma locadora de vídeo que gera uma declaração para calcular a taxa total de locação para cada tipo de vídeo (nova versão, filhos, etc.) para um cliente. O código existente usa o objeto como:

  • Declaração para gerar extrato e taxa de cálculo, onde a declaração de troca grande se senta para usar o enum para determinar como calcular a taxa de aluguel
  • o cliente tem uma lista de aluguéis
  • classe base de filmes e classe derivada para cada tipo de filme (NOVO, CRIAN Ç AS, ACÇÃO, etc.)

O código originalmente não é compilado, pois o proprietário foi considerado atingido por um barramento. Então, aqui está o que eu fiz:

  • delineou a melhoria em relação ao modelo de objetos para ter melhor responsabilidade por cada classe.
  • use o padrão de estratégia para substituir a instrução switch e envolvê-los na configuração

Mas a equipe diz que é perda de tempo porque não há nenhuma exigência para isso e o conjunto de testes UAT funciona e é a única diretriz que entra na decisão de arquitetura. A história subjacente é apenas para obter recursos de preços e não dizer nada sobre como fazê-lo. Portanto, a discussão é focada em por que o tempo gasto na refatoração da instrução switch deve ser gasto.

No meu entendimento, a metodologia ágil não significa zero design antecipadamente e esse código deve ser evitado no início. Além disso, qualquer conjunto de testes de unidade / UAT não detectará esse cheiro de código, caso contrário sonar, findbugs não existirá.

Aqui eu quero perguntar:

  1. existe algo chamado design ágil na metodologia ágil? Apenas como documentação ágil.
  2. como definir o design ágil antecipadamente? como saber o suficiente é suficiente? No meu entendimento, a arquitetura do ballpark e o contrato de dados entre os componentes devem ser definidos antes / ao iniciar o projeto, não os detalhes. Estou certo?
  3. alguém pode explicar o que a equipe está realmente procurando nesse tipo de configuração? é aspecto de design ou aspecto ágil?
  4. como implementar o conceito de produto viável mínimo no processo ágil no projeto do mundo real? É necessário que você se sinta envergonhado de ser MVP?
por ying 19.10.2013 / 16:03
fonte

2 respostas

4

Existem muitas abordagens no mundo real sobre isso. Você está fazendo uma pergunta muito ampla, então minha resposta será um pouco geral.

  1. Claro que existe um conceito de design em ágil. Normalmente não existe o conceito de design inicial, mas os sistemas são projetados à medida que você vai e, é claro, os sistemas legados têm um design.

  2. >
  3. Estritamente falando, você deve fazer o projeto mínimo necessário que puder pagar. É perfeitamente possível que um site comece com uma página HTML estática hospedada em algum lugar. De fato, muitos sites fazem isso. É claro que, às vezes, é necessário fazer um pouco de trabalho inicial para que um design básico seja implementado, mas devemos falar sobre os dias de trabalho, no máximo.

  4. Essa é uma pergunta para sua equipe, mas não acho que seja correto fazer uma pergunta inicial. As equipes não precisam de nada além de computadores em rede. Tudo o que uma equipe precisa é determinado pelo que a equipe precisa alcançar.

  5. O MVP é o conjunto mínimo de itens que você precisa enviar para ter qualquer valor. Normalmente, é uma "inscrição na página beta". Depois disso, a quantidade mínima de recursos que permitirá que seu produto funcione. Eu gostaria de enfatizar o "mínimo" aqui: pegue o conjunto de recursos "não tão mínimos" que você provavelmente criará inicialmente, e comece a remover tudo que puder enquanto mantém o núcleo funcionando. O ponto principal é permitir um ciclo de feedback com os primeiros usuários. Um MVP deve ser uma versão alfa e não beta.

por 19.10.2013 / 16:33
fonte
2

O importante com o design em um processo ágil é que ele precisa ser feito dentro do processo. Uma das primeiras coisas a produzir é um design, caso contrário, você não tem ideia do que está fazendo. Mas esse design não deve demorar muito para ser produzido, e deve, a partir de então, ser um artefato sujeito a revisão através do processo ágil, assim como o código. Não assuma que você vai acertar primeiro. Não tenha medo de adicioná-lo se necessário e refatorá-lo se for muito complicado.

Tente manter o design em algo que caiba em uma página (ou em um slide) para que as pessoas possam entender onde a peça em que estão trabalhando se encaixa na imagem geral. Claro, isso não cobrirá todos os casos, mas projetar de antemão para cobrir tudo não é uma prática ágil; que decorre naturalmente do princípio fundador de que os requisitos não são todos conhecidos de antemão (e o ponto óbvio de que o verdadeiro design segue os requisitos).

Para saber quando você tem muito? Francamente, você provavelmente já tem muito. O design de alto nível - o bit realmente útil - não deve demorar muito, e o design de baixo nível é o que quer que caia do backlog. (Dica: se você está pensando em algoritmos no design, você quase certamente já recebeu muitos detalhes. Bem, a menos que você esteja fazendo algo tão estranho que seja impossível sem esse algoritmo específico ...)

O que é importante para a equipe é que eles fazem algo acontecer e voltam com o proprietário do produto para a próxima iteração para entender os requisitos. Tal como acontece com todo o desenvolvimento ágil. (Re o MVP, lembre-se que pode levar algumas iterações para chegar lá, e não tenha medo de não fazer com que pareça bom nas primeiras rotações; os clientes muitas vezes pensam que ter o CSS aplicado significa que todo o serviço está concluído. Você sabe e eu sei que isso não é verdade.)

    
por 19.10.2013 / 16:47
fonte

Tags