Existe uma alternativa viável à metodologia de desenvolvimento ágil?

É claro que a cachoeira é viável. Ela nos trouxe à lua!

E é um treinador ágil falando aqui!

A menos que você possa identificar claramente os problemas relacionados à maneira como gerencia seus projetos, não há motivos válidos para alterá-los.

Como alternativa às metodologias Ágil e Waterfall , sugiro SUA metodologia . Adaptado ao seu negócio específico, sua equipe específica, seus produtos, sua maneira de trabalhar, a cultura de sua empresa ... É por isso que o Scrum é chamado de estrutura simples em vez de uma metodologia.

Querer implementar uma metodologia porque alguém em um blog do qual você gosta de falar é tão estúpido quanto deixar os problemas sem fazer nada.

Primeiro, discordo de suas declarações:

Waterfall says: Change is costly, so it should be minimized.
Agile says: Change is inevitable, so make change cheap.

Minha interpretação é:

Waterfall diz: O cliente sabe o que quer.
Agile diz: O cliente não sabe o que quer, então teremos que fazer algumas versões diferentes.

A melhor implementação de "cascata" que já vi foi um enorme projeto de integração com um cliente financeiro muito grande e havia cerca de 40 subprojetos envolvidos. O pacote de desktops e websites que fornecemos era apenas um desses 40 subprojetos. Enquanto eu pensava que eles sopravam o dinheiro de outras pessoas em vez de excessivamente, eles tinham suas coisas juntos e mantinham mais de 40 naves diferentes se movendo juntas em formação. O projeto entrou em operação na data prevista (o alvo foi movido uma vez durante o projeto) e, embora eu achasse que eles poderiam ter feito isso mais frugalmente e agilmente, ele foi feito a tempo e no spec. O horário da noite de vida foi de cerca de 100 páginas e cerca de 40 dessas páginas eram detalhes de contato de pânico de emergência de todos os tipos de pessoas envolvidas. Fiquei muito impressionado com esse cliente.

Ou você pode fazer o que nós fazemos, o que é feito e o que é o relatório de reclamação / bug mais recente, e chamar esse ágil.

Você começa dizendo:

The two predominant software-development philosophies are waterfall and agile.

Isso é falso. Essa dicotomia foi construída pela comunidade ágil para criar um adversário contra o qual se posicionar. Antes que o Agile estivesse em voga, as pessoas costumavam falar sobre uma miríade de diferentes abordagens para a construção de software. Eles ainda existem hoje, mas de alguma forma eles são frequentemente agrupados em uma grande bagunça chamada "cachoeira" por defensores ágeis.

Eu tenho usado OPEN / Metis e suas variantes há mais de 10 anos com grande sucesso. Definitivamente não é ágil, e definitivamente não é cascata. Milhares de desenvolvedores criam softwares extremamente complexos para aeronaves, sistemas essenciais, bancos, etc., usando métodos não ágeis todos os dias.

Então, sim, é claro que há uma alternativa viável para o agile.

Sim, várias técnicas de desenvolvimento de software são viáveis, dependendo do domínio do seu problema. É "cavalos para cursos".

Por exemplo, você está escrevendo software para controlar uma usina nuclear ou para dirigir o ônibus espacial da NASA. Este tipo de domínio de problema é provavelmente mais adequado para uma abordagem em cascata (ou mesmo mais rigorosa), você quer resolver todos os problemas na frente, se possível (ou BOOM!).

Criando a interface do usuário mais recente do web 2.0 / 3.0 / buzzy? Ágil é uma maneira muito melhor de ir (você precisa desse feedback rápido e mudar).

Há o que eu chamaria de princípios de software artesanal que ainda podem ser aplicados independentemente da metodologia, por exemplo:

• Controle de origem
• build e CI
• programação em par
• TDD
• eu dou um ^% $$ &

e mais.

O problema decorre da complexidade do software. Cachoeira funciona muito bem para coisas como construção de pontes e pavimentação de estradas, porque a física nunca muda. Claro, em algum momento vamos desenvolver um novo asfalto, mas isso não vai revolucionar a maneira como as estradas são construídas. O aço na suspensão de uma ponte é do tamanho certo ou não é. Você não pode kludge ou stub um projeto de construção real, como você pode com o software.

Alterações de software. O software muda rapidamente. A lei de Moore afirma que o número de transistores em um chip dobra a cada 18-24 meses. Em corolário, o número de linhas de código em um programa também dobra. Complexidade entre essas linhas de código, portanto, aumenta com um bigO de algo como 2 ^ (2t).

O software muda rapidamente e a complexidade aumenta exponencialmente com ele.

Ao controlar o custo do software, você deseja controlar fatores exponenciais , não apenas multiplicativos ou aditivos. Mudar código aumenta a complexidade (e se torna exponencialmente mais complexo à medida que o projeto avança) de uma maneira exponencial.

A mudança é inevitável. A própria natureza da programação estende a linguagem com classes e métodos customizados, mudando assim a própria linguagem. Você não pode fazer isso em nenhum outro tipo de disciplina de engenharia (como construir estradas. Você não inventa novo asfalto apenas para pavimentar uma estrada em Kansas sobre a Califórnia).

O método ágil também oferece uma plataforma para lidar com versões futuras e correções de bugs. Você também tem as ferramentas de gerenciamento, processos, funcionários treinados para o desenvolvimento de software com versão. Com um método cascata, você precisaria treinar novamente sua equipe para lidar com pequenas correções de bugs.

de qualquer forma, meus 2 centavos.

Para responder a pergunta, existe uma alternativa viável, para o software talvez não - ou ainda não, pelo menos no caso geral. Eu acho que se resume à natureza do software. O software, sendo informação, pode ser duplicado gratuitamente. Ao contrário de uma ponte ou uma casa. Isso significa que, com a prática, eu poderia ser bom em construir uma casa e estar operando em um domínio relativamente simples. Em que ponto, por que não usar uma abordagem única?

Mas como o software tem zero custo de duplicação, por que você faria a mesma coisa duas vezes? Software tende longe de fabricação. Então, se todo software é a criação de um novo produto, então estamos sempre operando em um domínio complexo, onde, até certo ponto, não sabemos o que estamos fazendo. Ou é caro saber de antemão e é mais barato descobrir fazendo. Em um domínio complexo e arriscado, eu gostaria de experimentar experimentos e incrementar e iterar.

As usinas de energia nuclear e os sistemas fly-by wire costumam ser dados como exemplos de software que você gostaria de fazer em cascata. Mas o sistema aviônico do ônibus espacial não foi desenvolvido iterativamente? Como foram os sistemas de controle de tráfego aéreo canadense e norte-americano?

E se OPEN / Metis for iterativo e incremental, então, para mim, parece que ele tem a filosofia ágil, mesmo que não se associe a outras práticas ágeis comuns.

O método Waterfall é certamente viável e é tão filosoficamente correto quanto qualquer outra abordagem. Lembre-se que o Waterfall tem estado muito mais tempo do que o Agile, mas note que este não é um argumento para afirmar se uma metodologia é melhor do que outra.

Você usa o método Cascata quando tem um entendimento muito claro sobre todo o domínio do problema e o que o cliente deseja alcançar em um pacote de software. Você provavelmente citou um preço fixo ao aceitar o contrato, e seu cliente entende que não pode se desviar de quaisquer requisitos acordados. Seu processo é estritamente um que flui através de uma série de assinaturas entre os vários estágios de desenvolvimento, e é frequentemente o caso que cada estágio é completado por uma equipe diferente - às vezes até uma empresa diferente - cada qual não necessariamente em contato com os outros. Você vê frequentemente que a Waterfall é aplicada com bons resultados em projetos militares e governamentais quando são oferecidos a contratados externos. Onde a Waterfall e outras abordagens similares obtêm uma má reputação é quando os desenvolvedores se deparam com problemas, tais como estimativas precárias, cronogramas planejados sem tempo de contingência ou uma compreensão deficiente ou incompleta do domínio do problema. A questão nunca é verdadeiramente uma falha da metodologia, mas na aplicação dela.

A comparação entre o Agile e qualquer metodologia é falsa. Agile não é uma metodologia, é uma filosofia, ou talvez seja melhor dizer que é um termo abrangente que representa uma maneira diferente de ver como você desenvolve o software. Uma metodologia é meramente uma ferramenta e, como tal, seu valor sempre será menor do que os indivíduos e as interações que estão no centro do o que significa ser Ágil .

Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?

Todas as oportunidades para minimizar a mudança são valiosas para o desenvolvedor e para o cliente. As alterações podem fazer com que um cronograma escorregue ou que os recursos sejam deixados de fora para cumprir um cronograma. É como você gerencia os efeitos da mudança que impactam no valor de seus projetos.

Or is the question really about what sort of practices work best in our situations to manage the inevitable change?

Suas práticas podem ajudar no gerenciamento de mudanças, ou elas podem ignorar mudanças completamente. O que importa é a combinação de suas práticas de desenvolvimento e o gerenciamento de seu relacionamento com seus clientes, e se essas coisas funcionam juntas de maneira eficaz para todas as partes envolvidas.

Aqueles de nós que são, para todos os efeitos, Ágil entendem que você escolhe um método que funcione para você. Se você gosta de uma abordagem particular, siga-a. Se não se encaixa perfeitamente às suas necessidades, altere-o. O modo como você trabalha na criação de software realmente se resume a tentar fazer o melhor uso dos recursos disponíveis e minimizar as práticas que podem levar o projeto à falha, e você geralmente acha que precisa mudar o método para se adequar ao software. projeto específico em mãos.

É realmente uma coisa dizer "Ok, então agora somos Ágeis", e totalmente outra é realmente viver e trabalhar pela filosofia que o Agile é. Se você usa Cascata, Incremental, Espiral, SCRUM, XP, FDD ou qualquer outro método, você é basicamente Ágil onde você valoriza:

• Indivíduos e interações sobre processos e ferramentas
• Software de trabalho sobre documentação abrangente
• Colaboração do cliente sobre negociação de contratos
• Respondendo para mudar depois de um plano

e onde você coloca suas ferramentas, método e sua experiência juntos para aplicar esses valores com êxito.

Sim, os modelos de processos híbridos Waterfall, Spiral, Iterative e outros são todos viáveis, mas a mudança é inevitável. O processo é mais do que apenas sobre como lidar com mudanças, e (eu afirmo que) o maior determinante é quão bem você entende / compreende o problema, e com que precisão você pode planejar e prever.

Afirmar que "as duas metodologias predominantes de desenvolvimento de software são cascatas e ágeis" é desonesto, pois há um espectro de processos de desenvolvimento de software e muitas empresas sintetizam sua própria versão do modelo de processo, muitas vezes mudando para um determinado projeto. Existem mais de duas abordagens viáveis para o desenvolvimento de software. Embora Waterfall e Agile tendam a cair em extremos opostos do espectro de "mudança", é razoável tipificar essas metodologias concorrentes como,

Waterfall diz: A mudança é cara, por isso deve ser minimizada.

Agile diz: Mudança é inevitável, então faça mudanças baratas.

Mas essa não é toda a história. As empresas precisam ser capazes de planejar e prever, mas o software é um processo criativo e as estimativas muitas vezes estão erradas. Lembre-se do bom - rápido - triângulo barato? Adicione uma quarta dimensão, processo, e você verá que reduzir o esforço do processo também pode comprimir o cronograma, quando as estimativas se mostrarem erradas e o projeto estiver em risco de atraso. O software é um processo fungível (mutável), e o Agile, Iterative, Spiral, todos oferecem a capacidade de fornecer funcionalidade incremental em intervalos menores.

Waterfall e outros modelos de processos orientados por requisitos têm controles para lidar com mudanças, por isso é impreciso dizer que a Waterfall minimiza mudanças, é mais preciso dizer que a Waterfall reconhece e gerencia mudanças e comunica o impacto dessa mudança (porque a mudança causa cronograma impacto quando você tem requisitos e design na frente). Quando você está criando um produto ou precisa definir totalmente os requisitos (funcionalidade), você é direcionado a um dos modelos híbridos.

E quando as estimativas estão erradas, muitas vezes o processo (a quarta perna do triângulo de ferro) é sacrificado para cumprir o cronograma.

As abordagens ágeis e em cachoeiras maduras são indistinguíveis umas das outras. Sua suposição sobre o objetivo da abordagem em cascata está incorreta. Ambos têm o objetivo de produzir software de qualidade. Quando você não tem uma abordagem de desenvolvimento sólida para a empresa como um todo, é necessário observar qual abordagem fornecerá o mínimo de atrito para a adoção. No final, ciclos de desenvolvimento curtos, uma sólida equipe de QA e uma empresa que impulsiona o desenvolvimento são o que é mais importante para a produção de software de primeira qualidade.