O agile pode ser efetivamente usado para desenvolvimento inicial em um projeto substancial?

5

Eu acho que a resposta curta para essa pergunta provavelmente é "sim", mas eu pensei em perguntar mesmo assim!

Estamos no processo de levar um número de aplicativos existentes semelhantes, mas diferentes e, como parte do que é para nós possivelmente o maior projeto de desenvolvimento de todos os tempos, tentando substituí-los e qualquer aplicativo subseqüente semelhante, mas diferente, com um sistema superconfigurável e superconfigurável para controlá-los. Eu espero que a Síndrome do Segundo Sistema Difícil nos dê muitos problemas para entregar o gigante em primeiro lugar, mas eu não quero que nossa escolha de metodologia torne tudo pior. Nós nos demos conta de algo ágil, principalmente de cascata, mas este seria nosso primeiro projeto substancial usando uma nova metodologia melhorada.

Temos planos grandes para o novo sistema e, embora nem todos tenham que ser entregues de uma só vez , precisaremos implementar grandes partes dele desde o início para permitir que qualquer coisa seja entregue ao cliente. que eles até entenderiam . Minha preocupação é que, como estamos mudando drasticamente de uma só vez, há pouco espaço para pequenos trechos de trabalho que levam a resultados úteis / demonsáveis. Tenho medo de que, mesmo se conseguíssemos encontrar uma maneira de fazer isso em pequenos pedaços, precisássemos que esses pedaços se encaixassem bem em um quadro maior, e assim seria difícil desenvolvê-los isoladamente por esse motivo. também. Estamos visando uma abordagem de SOA desacoplada, o que é algo.

As escalas de tempo são rigorosas e as reputações foram apostadas na entrega a tempo.

Então, eu gostaria de saber se, neste caso:

  • é aconselhável fazer um monte de design inicial, montar a forma geral do aplicativo e fazer com que os módulos cruciais funcionem em um grande impulso (que pode ser acelerado em termos de acompanhamento do trabalho, mas não tanto em termos de feedback e melhoria de design e assim por diante), antes de talvez ficar mais ágil a partir de então, ou ...
  • tente ser o mais ágil possível desde o início - concorde coisas como padrões de codificação, talvez algumas noções básicas de API, divisões gerais de módulos e, em seguida, confie em codificação independente, tendo flexibilidade em mente para deixar que as outras coisas sejam gradualmente desenvolvidas; talvez algumas coisas tenham que ser retrabalhadas, mas qualquer coisa que possa ser mais bem dirigida durante o desenvolvimento do que antecipada será beneficiada, ou ...
  • talvez mais alguma coisa e ...
  • alguma dica geral?
por frumious 05.08.2011 / 02:00
fonte

2 respostas

4

Sim ... se ...

Eu só direi sim se você puder eliminar recursos do seu projeto para atingir o prazo.

Caso contrário, você só receberá uma parte dos benefícios de uma Abordagem Ágil.

Os prazos finais arbitrários não funcionam

Timescales are tight, and reputations have been staked on delivering on time.

Isso me preocupa, isso é um prazo arbitrário criado a partir da análise otimista de melhores sugestões. Prazos arbitrários não funcionam e, de fato, foram comprovados que funcionam em detrimento de um projeto.

Joel Spolsky escreveu um ótimo ensaio sobre Programação Baseada em Evidências

3) Simulate the future

Rather than just adding up estimates to get a single ship date, which sounds right but >gives you a profoundly wrong result, you’re going to use the Monte Carlo method to >simulate many possible futures. In a Monte Carlo simulation, you can create 100 possible >scenarios for the future. Each of these possible futures has 1% probability, so you can >make a chart of the probability that you will ship by any given date.

Esteja preparado para descartar recursos para economizar tempo

Colocar isso de lado com um prazo fixo para um projeto ágil é bom, mas você precisa ser capaz de priorizar seus recursos mais valiosos em seu produto de software e, em seguida, descartar recursos não tão valiosos para atingir seu marco temporal.

Isso deve acontecer a cada sprint, os únicos recursos que são mesclados em um "release" no final de um sprint são os recursos que são totalmente testados e funcionando. Recursos que não são totalmente testados e funcionando são descartados para o próximo sprint ou próximo "lançamento". Lançamento não significa entrega para o cliente, mas após cada sprint você tem um produto de software totalmente funcional (embora de forma limitada) que é totalmente testado.

Use os melhores recursos do Agile

A ideia de usar o ágil é que seus recursos entre sprints não estão gravados. Em um projeto ágil normal, o cliente tem entrada em cada sprint e pode solicitar que um novo recurso seja adicionado como uma prioridade mais alta do que um recurso solicitado há 3 sprints atrás.

Evite uma corrida de projeto (se possível)

No seu caso, isso provavelmente não vai acontecer, você já tem o recurso definido em seus projetos existentes e, além disso, também parece que você vai ter uma condição de corrida em que você vai estar correndo o seu ciclo de manutenção atual para seus projetos existentes com o novo projeto para que você possa substituí-lo.

If you have been a programmer for more than two or three years, you have probably been significantly slowed down by someone else’s messy code. If you have been a programmer for longer than two or three years, you have probably been slowed down by your own messy code. The degree of the slow-down can be significant. Over the span of a year or two, teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Every addition or modification to the system requires that the tangles, twists, and knots be “understood” so that more tangles, twists, and knots can be added. Over time the mess becomes so big and so deep and so tall, they can not clean it up. There is no way at all.

As the mess builds, the productivity of the team continues to decrease, asymptotically approaching zero. As productivity decreases, management does the only thing they can; they add more staff to the project in hopes of increasing productivity. But that new staff is not versed in the design of the system. They don’t know the difference between a change that matches the design intent, and a change that thwarts the design intent. Furthermore, they, and everyone else on the team are under horrific pressure to increase productivity. So they all make more and more messes, driving the productivity ever further towards zero.

Eventually the team rebels; and they inform management that they cannot continue to develop in this horrific code base. They demand a redesign. Management does not want to expend the resources on a whole new redesign of the project, but they cannot deny that productivity is terrible. Eventually they bend to the demands of the developers, and authorize the grand redesign in the sky.

A new tiger team is selected. Everyone wants to be on this team because it’s a green-field project. They get to start over and create something truly beautiful. But only the best and brightest are chosen for the tiger team. Everyone else must continue to maintain the current system.

Now the two teams are in a race. The tiger team must build a new system that does everything that the old system does. Not only that, they have to keep up with the changes that are continuously being made to the old system. Management will not replace the old system until the new system can do everything that the old system does, on the day of the change.

This race can go on for a very long time. I’ve seen it take 10 years. And by the time it’s done, the original members of the tiger team are long gone, and the current members are demanding that the new system be redesigned because it’s such a mess.

If you have experienced even one small part of the story I just told, then you already know that spending time keeping your code clean is not just cost effective; it’s a matter of professional survival.

Uma alternativa - limpe sua arquitetura existente

Robert Martin como citado acima expressa uma alternativa a um projeto reescrito em sua palestra sobre software craftsmanship. Se você ainda não viu isso antes, vale a pena assistir todo o caminho.

Eu também recomendei alguns métodos para realizar a refatoração gradual em oposição a uma reescrita completa na minha resposta a uma pergunta semelhante.

Primeiros passos

No passado, onde comecei grandes projetos greenfield (sem surpresa também foi SOA). Descobri que a prototipagem inicial da arquitetura e a adoção do framework levaram um pouco de tempo para que eu pudesse reformular minha abordagem, descartar minhas idéias meia dúzia de vezes enquanto protótio e testar teorias e melhores práticas de design.

Não perca tempo escrevendo especificações que só serão descartadas

Usar um grande design inicial em uma nova arquitetura desperdiçará tempo e esforço, portanto, é essencial ter uma abordagem ágil dos requisitos funcionais e das especificações em um documento de especificações totalmente funcional para não perder tempo e descartar ideias ruins que pareciam ótimas papel, mas não deu certo na vida real.

Prototipagem inicial

Este estágio de prototipagem inicial que eu encontrei geralmente não produz nada que seja entregue ao cliente até que ele esteja realmente pronto e funcionando. No entanto, o que você deve acabar no final deve ser uma arquitetura bem pensada, com módulos facilmente configuráveis e refatorar os aplicativos existentes na nova arquitetura deve se prestar muito facilmente a uma metodologia ágil com resultados visíveis ao cliente.

Seguido por um aumento na velocidade

Quando seu protótipo for concluído e sua arquitetura estiver desativada, você perceberá que terá um período de transição em que precisará instruir o restante de sua equipe sobre a melhor forma de migrar ou refatorar seus projetos existentes para adequar-se ao novo quadro. Assim, você pode esperar uma velocidade de aceleração lenta, seguida por uma maior velocidade próxima ao final do projeto, à medida que você obtém mais desenvolvedores on-line e implementa seu design.

    
por 05.08.2011 / 02:57
fonte
1

Acho que o Rational Unified Process clássico funciona melhor para grandes projetos.

A razão pela qual digo isso é que a fase de coleta de requisitos para um projeto grande é demorada e os requisitos interagem de maneira imprevista. Por exemplo, alguém nas contas lhe dirá que precisa do ID do Imposto. de qualquer um que pague uma conta por causa de regulamentações de lavagem de dinheiro - você então tem que voltar e redesenhar seu site para capturar IDs de impostos. na página de registro, e também, acabam com dois formulários extras se o nome no cartão de crédito não coincidir com o nome do cliente registrado.

Em muitos casos, não é possível descartar recursos. Você não pode simplesmente ir ao vivo com "Order Capture" depois de soltar o recurso "Order Delivery".

Depois de se afastar dos aplicativos de finalidade única e começar a desenvolver aplicativos de negócios "reais", você descobre que a maioria dos requisitos é realmente regulamentar. Você precisa fazer coisas por causa de contabilidade, impostos, proteção ao consumidor, leis de privacidade, etc. Em sistemas financeiros isso pode representar até 100% de suas necessidades para alguns sistemas.

O ágil "permite conversar com os usuários e alimentá-los com cookies" simplesmente não é possível quando seu "usuário" é representado por um documento com duzentas páginas de juristas obscuros. Se você eliminar recursos como "Informar imposto sobre vendas", pode acabar na cadeia.

Perversamente, dados os comentários acima, minha resposta é "Sim", você pode usar o Agile e "Sim", mas apenas para projetos "Sub" dentro da estrutura de projeto maior, e, somente se você tomar "ir" live "significa entregar ao ambiente de teste" UAT "ou" SIT ".

    
por 05.08.2011 / 03:56
fonte