Quais são algumas situações em que Agile é inapropriado? [fechadas]

StackOverflow https://stackoverflow.com/questions/348611

Pergunta

Eu tenho ouvido e lido sobre Agile por anos. Eu possuo um livro ou dois sobre ele e eu gosto da idéia.

Estou finalmente em uma posição onde eu poderia rolar algo como isso, onde eu trabalho, mas tenho sérias preocupações sobre se é o caminho a percorrer para nós:

  • Não há um tamanho mínimo para este? Big projetar-se frente deve ser mais eficiente para um projeto de três ou quatro semanas ... Certo?
  • Nossos clientes geralmente exigem preços fixos. Eles precisam saber o que está lidando, excepto em casos especiais em que somos contra um buraco negro óbvio e mesmo assim as pessoas são mais confortáveis ??com uma tampa. Então, como você pode fornecer uma citação se você estiver indo com um processo que é tolerante a mudanças de requisitos em curso?
  • Eu entendo que Agile pode oferecer melhores chances de sucesso em projetos mais complexos, mas não vai elevar os custos para o cliente? E, claro, há o custo do fracasso de considerar -. Talvez estamos de volta com a pergunta tamanho mínimo aqui
  • Como no mundo você explicaria essa abordagem contra-intuitiva para os clientes? intervenientes não technicial pode não ter a experiência para envolver suas cabeças em torno de qualquer coisa além de Cachoeira.
  • Mesmo para projetos internos, existem orçamentos. O que eu estou ausente?
  • Parece que há alguma reação contra Agile recentemente. É outra coisa vai começar ganhando força em breve?

Nota: Nós somos uma loja 5 dev com projetos que vão desde um ou dois dias por todo o caminho até vários meses. Eu não acredito que há uma metodologia para governá-los todos, mas seria ótimo para encontrar algo suficientemente flexível que podemos adaptá-la a todos os nossos projetos.

Muito obrigado!

Brian MacKay

Foi útil?

Solução

Eu não acho que uma metodologia pode governá-los todos. Sinto muito. Eu sou um crente firme em encontrar o modelo certo para o projeto certo. Por exemplo, como você se sentiria se seu fosse para a cirurgia e você sabia que a máquina que foi mantê-lo vivo foi desenvolvido em um ciclo iterativo rápido com pouco projeto inicial.

Mas de qualquer maneira, para a sua pergunta. Eu sou um grande crente em abordagens ágeis, de manter suas iterações suma, incidindo sobre o que o usuário quer, e não a construção do navio de guerra mas apenas construir exatamente o que você precisa. Eu diria que 95% de todos os projetos poderia usar abordagens ágeis, e se eles não podem normalmente é uma questão cultural, não uma questão de projeto.

Agora, tanto quanto BDUF (projeto Big Frontal), tivemos grande sucesso com uma equipe de 20 pessoas em um projeto de quatro meses, que levou o projeto partiu-se em 3 de quatro ciclos de semana, no início de cada um de nós ciclo todos se encontram em uma sala, e disse ok aqui é o que precisamos para construir, aqui está como vamos construí-lo, e levou uma facada em que nossas interfaces seria semelhante, quais os dados que precisávamos etc ... Mas foi só uma facada , que, em seguida, voltou para nossas mesas, e quem possuía as várias peças lavadas para fora os detalhes.

Essencialmente nós fizemos o suficiente adiantado BDUF para alavancar a equipe (e garantir que cobriu todos os requisitos de negócio). Nós costumávamos chamar estes dias sessões de Desenvolvedor e foi uma boa maneira de alavancar a equipe. Se você tem o dinheiro levar a equipe fora do local você pode enchê-los em uma sala de conferências em um hotel alimentá-los lotes de sucata e assistir os sucos fluir.

Outras dicas

a solução simples tem 2 etapas:

  1. não estimar os custos e cronogramas para projetos, estimativa de custos e cronogramas para apresenta
  2. medida e informações suficientes registro para calcular sua velocidade e erros de estimativa

começar pequeno e em casa se possível para obter alguns números de base. Se você ainda quer fazer 'big up-front design, fazê-lo por características individuais. Isso vai ajudar as suas estimativas iniciais ser mais exato, e também o que granularidade de 'recurso' você está confortável com.

Nota: isso só funcionará se o cliente está empenhada em fazer a sua parte , ou seja, para ser altamente disponível para os desenvolvedores (para responder a perguntas, histórias escrever e descrições de teste, et al), e não mudar sua mente durante uma iteração

boa sorte com a sua transição, e deixe-nos saber como ele vai!

De longe o maior contra-indicação que eu vi é uma incompatibilidade valores. Extreme Programming assenta no respeito, comunicação, feedback, coragem e simplicidade. Em uma organização que se comporta com base nos valores incompatíveis, aplicando XP vai causar atrito e não resultará em qualquer mudança duradoura (IME).

Depende de quem você perguntar e se eles acreditam em ágil ou não ...

Quanto a isto:

Eu gostaria de encontrar uma metodologia para governá-los todos.

http://www.opaquelucidity.com/facepalm.jpg

Tem todos os seus clientes o mesmo? Você já disse que as durações variam muito ... Por que você suponha que todos os tipos de diferentes projectos seria adequado para uma única metodologia?

Pesquise o que fazem prática Agile falhar ... Se você tem 1-2 menores pontos vão para ele, você vai encontrar maneira de passar por cima deles. Senão, você está procurando um fracasso. E uma vez que você falha, você não terá outra oportunidade de experimentá-lo. Mesmo se não é a prática Agile que falhou ...

Comece com projetos internos para obter alguma experiência com como funciona o seu processo ágil e como você pode melhor estimativa como as coisas longos vão tomar. Quando você sente que você está pronto para assumir um cliente real, escolher um que você tem um monte de confiança com e escolher um razoavelmente pequeno projeto para começar. A chave aqui é que você quer construir a confiança. Explique o que você está fazendo e por quê - você quer para proporcionar um melhor software para os que melhor reflete suas prioridades mais cedo - e mostrar-lhes como você tem sido bem sucedida em seus projetos internos. Entregar em suas promessas -. Pois acredito em métodos ágeis, eu não acho que isso vai ser muito difícil de fazer

Uma vez que você conseguiu (e wow-ed o cliente), eles vão pedir-lhe para usar o método em seus outros projetos. Depois de ter um cliente feliz você pode começar a expandir-se para outros, usando seu primeiro cliente como uma referência. Muito em breve você vai descobrir que as práticas que você está usando o trabalho tão bem que eles fluência em seus processos "Cachoeira" também. Eventualmente, você vai ter bastante bêbado do Kool-Aid para ser como o resto de nós agilistas. : -)

Oh. E sim, há projetos que não são particularmente passíveis de métodos ágeis. Coisas como sistemas críticos de vida, controle de usina nuclear, indústrias altamente reguladas podem exigir design mais up-front e processo do que ágil permite. A maioria de nós não sempre trabalho nestes projectos.

Scott Ambler é uma autoridade bom para um resposta sobre isso. Seu artigo faz um bom trabalho de destacar algumas das armadilhas de preço fixo, mas é definitivamente possível. Alistair Cockburn concorda é possível também, mas salienta que alguns dos benefícios que você começa de ágil são perdido em contratos de preço fixo.

Um problema básico com o "Projeto grande up-front" (BDUF) é o tempo gasto funcionalidade concepção que é raramente, se alguma vez, utilizado. Se você precisa ter um produto acabado em um mês ou menos, o problema deve ser muito bem definida de antemão.

Como para o custo do fracasso, isso é uma preocupação muito legítima. Um dos benefícios do Agile é que quaisquer falhas acontecer mais cedo e com um custo muito menor do que em um projeto seguindo a metodologia cachoeira. Ser capaz de aprender com os fracassos e obter um bom produto no final não é um resultado que a metodologia cachoeira pode entregar. O governo federal tem um bom número de falhas de alto perfil de projetos de software que se seguiram a metodologia cachoeira e BDUF. Eu tenho Blogged sobre Case Virtual do FBI fracasso do projeto arquivo.

Que metodologias você uso será determinada tanto pelo ajuste com sua equipe como o tipo de software que você está construindo, e seus clientes. tvanfosson está muito certo sobre os projetos que não são adequados para os métodos ágeis. Concordo com Kent Beck na ideia dos valores de incompatibilidade. Algumas organizações não estão prontos para Agile a partir de uma perspectiva cultural, independentemente de seus méritos e sucesso em outros lugares.

Deixe-me responder às suas preocupações ponto-a-ponto:

Não há um tamanho mínimo para este? Projeto grande na frente deve ser mais eficiente para uma semana três ou quatro projeto ... Certo?

Eu não tenho certeza que o faz pensar que o desenho retângulos em papel deve ser mais rápido do que a refatoração de código.

De qualquer forma, mesmo que fosse, a questão de saber se BDUF paga de volta seria muito mais uma função da quantidade de aprendizado que você espera durante o projeto que do tamanho do projeto. Quanto mais você pode esperar para aprender algo sobre o design, os requisitos, etc. durante a implementação do sistema, mais o seu up design frente torna-se perdido.

Eu ainda tenho que encontrar um projeto onde eu não aprendi coisas importantes durante a implementação do sistema.

Nossos clientes geralmente exigem fixo preços. Eles precisam saber o que eles estão lidando, exceto em casos especiais onde estamos diante de uma óbvia buraco negro e mesmo assim as pessoas estão mais confortável com uma tampa. Então, como você pode fornecer uma citação se você estiver indo com um processo que é tolerante das mudanças nos requisitos em curso?

Somente aceitar mudanças de requisitos que não mudam esforço total. Ou seja, quando novos requisitos de entrar, deixar cair as menos importantes. Deixe o cliente decidir para que ele possa obter a maioria de estrondo para o fanfarrão.

Você não terá todos os benefícios do Agile desta forma, mas é tão bom quanto o preço fixo pode obter, tanto quanto eu posso dizer.

Eu entendo que Agile pode oferecer melhores chances de sucesso em projetos mais complexos, mas não vai elevar os custos para o cliente?

Você está sugerindo que os projetos executados da maneira Agile são mais caras do que projetos tradicionais? Na verdade, existem empresas lá fora que experimentaram o oposto, até uma redução de custos em 50%.

E, claro, há o custo do fracasso de considerar -. Talvez estamos de volta com a pergunta tamanho mínimo aqui

Custo de falha vai para baixo com um projeto Agile, por causa do feedback inicial. Você pode notar o fracasso - e, portanto, decidir cancelar o projeto -. Muito mais cedo

Como no mundo você explicaria essa abordagem contra-intuitiva para os clientes? intervenientes não technicial pode não ter a experiência para envolver suas cabeças em torno de qualquer coisa além de Cachoeira.

Por que pagar Agile Software Development?

Mesmo para projetos internos, existem orçamentos. O que eu estou ausente?

Eu não sei. Agile funciona bem com orçamentos - implementar as funcionalidades de maior prioridade até que o orçamento é usado para cima. Você tem o sistema mais valioso que poderia ter sido implementado para que o dinheiro.

Parece que há alguma reação contra Agile recentemente. É outra coisa vai começar ganhando força em breve?

Houve reação contra ele desde o início. E, como está se tornando mais popular (e é!), É apenas natural que você também vê mais folga.

magra Desenvolvimento de Software está ganhando muita tração. Não está em competição para o desenvolvimento Agile, mas sim complementar, no entanto. As comunidades na verdade são bastante sobreposição.

No que diz respeito a "única metodologia para governá-los todos" - dê uma olhada família de Alistair Cockburn "Crystal" de processos ágeis. Ele argumenta (bastante competentemente) que cada projeto precisa de seu próprio processo, e que as necessidades de processo mesmo um projeto para mudar ao longo do projeto. E ele fornece uma estrutura leve para o desenvolvimento de seu processo.

Como faz Scrum, como eu penso sobre isso. Scrum realmente não lhe diz muito sobre como executar o seu projeto, mas muito mais sobre como descobrir o que está funcionando e como habilitar o team para se adaptar a essas conclusões.

Eu não necessariamente usar ágil para um projeto onde tudo é conhecido na frente. Agile funciona bem quando a mudança é altamente provável. No caso em que mudança não é likley, pode-se usar o processo de previsão ou cachoeira para gerenciar um projeto como este.

As respostas às suas perguntas particulares seguir: Não há um tamanho mínimo para isso? De uma perspectiva prática, Agile é o tamanho independente. Dito isto, o maior projeto a mudança mais provável ocorrerá. Se um projeto é pequeno enaough então tudo é cognoscível e mudança é improvável.

Big projetar-se frente deve ser mais eficiente para um projeto de três ou quatro semanas ... Certo? Simples e evolutivamente design orientado pelo TDD é sempre mais eficaz. Você deve ter apenas o suficiente arquitetura feito na frente para saber onde as principais peças caem. Não use arquitetura de adivinhar o que você vai fazer, só captura o que é cognoscível. Vamos simples e design evolucionário permitir-lhe evoluir seu projeto detalhado como você criar o aplicativo.

Nossos clientes geralmente exigem preços fixos. Eles precisam saber o que está lidando, excepto em casos especiais em que somos contra um buraco negro óbvio e mesmo assim as pessoas são mais confortáveis ??com uma tampa. Então, como você pode fornecer uma citação se você estiver indo com um processo que é tolerante a mudanças de requisitos em curso? Alguns educação é necessária inicialmente. Você estabeleceria um product backlog, peça ao proprietário do produto para priorizá-los e, em seguida, fazer uma estimativa inicial da obra. Isso exige que o proprietário do produto estabelecer uma linha de corte na carteira para a oferta fixa. Então você dimensionar a equipe e duração para atender a estimativa. O contrato estipula então você vai usar a capacidade fixa da equipe para a caixa de tempo estabelecido. Isto irá manter o proprietário do produto focado na timebox e orçamento ao fazer chamadas prioritárias no backlog.

Eu entendo que Agile pode oferecer melhores chances de sucesso em projetos mais complexos, mas não vai elevar os custos para o cliente? Um projeto bem sucedido é sempre mais barato do que um falhado.

Como no mundo você explicaria essa abordagem contra-intuitiva para os clientes? intervenientes não technicial pode não ter a experiência para envolver suas cabeças em torno de qualquer coisa além de Cachoeira. Educação (ou seja, boot camp ágil) e visitando equipes ágeis de sucesso vai ajudar tremendamente. Em seguida, obter a equipe vai. O trabalho vai keept-los ocupados e os resultados vão vendê-los.

Mesmo para projetos internos, existem orçamentos. o que estou perdendo? Parece que há alguma reação contra Agile recentemente. É outra coisa vai começar ganhando força em breve? A única repercutiria Estou ciente de projetos ágeis que não utilizam práticas de engenharia de forma eficaz (ou seja, SCRUM apenas). A equipe usando SCRUM e XP effectivley vai fazer muito bem no momento do parto e ritmo sustentável.

Eu sugeriria contra Agile ao desenvolver um novo sistema de controle de tráfego aéreo.

Imho:

Agile ou não, você deve projetar o que é conhecido antes de implementar - antes de "apenas tentando coisas". Recursively quebrar as coisas em tarefas gerenciáveis, em seguida, criar o que é conhecido, seja pequenos detalhes ou apenas conceitos amplos. Coisas como interface do usuário e cada-dia requisitos de negócios quase nunca são ajustados na pedra antes do desenvolvimento, ao passo que recursos de simulação de aeronaves pode ser.

Uma maneira de tentar "vender" ágil aos clientes é conceder-lhes duas opções: 1. Cachoeira, onde não há nenhum cancelamento, enquanto nós (os devs) atender a nossa final do contrato. 2. Agile, onde você obtém atualizações semanais sobre status, hands-on demos assim que estiverem disponíveis, e o direito de descontinuar o serviço a cada 2 semanas (no caso de você não gostar do nosso trabalho).

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top