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

As duas metodologias predominantes de desenvolvimento de software são em cascata e ágil. Ao discutir esses dois, muitas vezes há muito foco nas práticas específicas que os distinguem (programação em pares, TDD, etc. vs. especificações funcionais, grande projeto inicial, etc.)

Mas as diferenças reais são muito mais profundas, pois essas práticas vêm de uma filosofia.

Waterfall diz: A mudança é cara, portanto deve ser minimizada.
O Agile diz: A mudança é inevitável, portanto, faça mudanças baratas.

Minha pergunta é: independentemente do que você acha do TDD ou das especificações funcionais, a metodologia de desenvolvimento em cascata é realmente viável?

Alguém realmente acha que minimizar a mudança de software é uma opção viável para aqueles que desejam oferecer software valioso? Ou é realmente a pergunta sobre que tipo de práticas funcionam melhor em nossas situações para gerenciar a mudança inevitável?

Claro que a cachoeira é viável. Nos trouxe para a 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 mudar.

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

Desejar implementar uma metodologia, porque alguém em um blog de que você gosta falou sobre isso é tão estúpido quanto deixar problemas sem fazer nada.

Primeiro, eu discordo de suas declarações:

Waterfall diz: A mudança é cara, portanto deve ser minimizada.
O Agile diz: A mudança é inevitável, portanto, faça mudanças baratas.

Minha interpretação é:

Waterfall diz: O cliente sabe o que quer.
O 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 eu já vi foi um grande projeto de integração com um cliente financeiro muito grande e havia mais de 40 subprojetos envolvidos. O pacote de desktop e site que fornecemos foi apenas um desses mais de 40 subprojetos. Embora eu pensasse que eles gastaram dinheiro demais com outras pessoas, eles juntaram suas coisas e mantiveram mais de 40 navios diferentes se movendo juntos em formação. O projeto entrou no ar na data prevista (a meta foi movida uma vez durante o projeto) e, embora eu achasse que eles poderiam fazê-lo de maneira mais econômica e ágil, foi feito dentro do prazo e das especificações. A programação da noite de transmissão ao vivo tinha cerca de 100 páginas e cerca de 40 delas eram detalhes de contato de pânico de emergência de todos os tipos de pessoas envolvidas. Fiquei muito impressionado com este cliente.

Ou então, você pode fazer o que fazemos, que é executado por aí e fazer o que é o relatório de reclamação / bug mais recente, e chamar isso de ágil.

Você começa dizendo:

As duas filosofias predominantes de desenvolvimento de software são em cascata e ágeis.

Isto é falso. Essa dicotomia foi construída pela comunidade ágil para criar um oponente contra o qual se posicionar. Antes do ágil estar em voga, as pessoas costumavam falar sobre uma infinidade de abordagens diferentes para a criação de software. Eles ainda existem hoje, mas de alguma forma são frequentemente agrupados em uma grande bagunça chamada "cascata" pelos proponentes ágeis.

Uso 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 software extremamente complexo para aeronaves, sistemas críticos para a vida útil, bancos, etc., usando métodos não-ágeis todos os dias.

Então, sim, é claro que existe uma alternativa viável ao ágil.

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

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

Criando a última interface do usuário da web 2.0 / 3.0 / buzzy marketing term? O Agile é um caminho muito melhor a seguir (você precisa de feedback e mudança rápidos).

Existem o que eu chamaria de princípios de artesanato em software que ainda podem ser aplicados, independentemente da metodologia, por exemplo:

• Fonte de controle
• construção e IC
• programação em par
• TDD
• Dou ^% $$ &

e mais.

Faça o que fizer, não dê ouvidos aos fanáticos dos dois lados da equação, faça o que é certo para você, sua equipe e seu domínio do problema.

O problema decorre da complexidade do software. O Waterfall funciona muito bem para coisas como construção de ponte e pavimentação de estradas, porque a física nunca muda. Claro, em algum momento desenvolveremos um novo asfalto, mas ele não 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 criticar 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 duplica a cada 18-24 meses. No corolário, o número de linhas de código em um programa também dobra. Portanto, a complexidade entre essas linhas de código 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. A alteração do código aumenta a complexidade (e se torna exponencialmente mais complexa à medida que o projeto avança) de maneira exponencial.

Mudança é inevitável. A própria natureza da programação estende a linguagem com classes e métodos personalizados, alterando 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 novas calçadas apenas para pavimentar uma estrada no 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ê já possui as ferramentas de gerenciamento, processos, funcionários treinados, para desenvolver software com versão. Com um método em cascata, você precisaria treinar novamente sua equipe para lidar com pequenas correções de bugs.

enfim, meus 2 centavos.

Para responder à pergunta, existe uma alternativa viável, para o software talvez não - ou ainda não, pelo menos no caso geral. Eu acho que tudo se resume à natureza do software. 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 melhorar a construção de uma casa e operar em um domínio relativamente simples. Nesse ponto, por que não usar uma abordagem de uma só vez?

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

Usinas nucleares e sistemas de cabos diretos são frequentemente dados como exemplos de software que você gostaria de fazer em cascata. Mas o sistema aviônico de transporte não foi desenvolvido iterativamente? Como eram os sistemas de controle de tráfego aéreo do Canadá e dos EUA?

E se OPEN / Metis é 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 de que o Waterfall existe há muito mais tempo que o Agile, mas observe que este não é um argumento para afirmar se uma metodologia é melhor que a outra.

Você usa o método Waterfall quando tem um entendimento muito claro sobre todo o domínio do problema e o que o cliente deseja obter em um pacote de software. Você provavelmente citou um preço fixo ao assinar o contrato e seu cliente entende que eles não podem se desviar de nenhum dos requisitos acordados. Seu processo é estritamente aquele que flui através de uma série de aprovações entre os vários estágios de desenvolvimento, e geralmente é o caso de cada estágio ser concluído por uma equipe diferente - às vezes até uma empresa diferente - cada uma das quais não necessariamente contato com os outros. Você costuma ver o Waterfall aplicado com bons resultados em projetos militares e governamentais quando são oferecidos a empreiteiros externos. O ponto em que o Waterfall e outras abordagens semelhantes têm má reputação é quando os desenvolvedores encontram problemas, tais como estimativas precárias, cronogramas planejados sem tempo de contingência ou um entendimento insuficiente ou incompleto do domínio do problema. A questão nunca é verdadeiramente uma falha da metodologia, mas na sua aplicação.

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 genérico que representa uma maneira diferente de ver como você desenvolve o software. Uma metodologia é apenas 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 que significa ser ágil .

Alguém realmente acha que minimizar a mudança de software é uma opção viável para aqueles que desejam oferecer software valioso?

Toda oportunidade de minimizar as mudanças é valiosa para o desenvolvedor e o cliente. As alterações podem fazer com que uma agenda caia ou que os recursos sejam deixados de fora para atender a uma agenda. É como você gerencia os efeitos das mudanças que afetam o valor de seus projetos.

Ou é realmente a pergunta sobre que tipo de práticas funcionam melhor em nossas situações para gerenciar a mudança inevitável?

Suas práticas podem ajudar no gerenciamento de mudanças ou podem ignorar completamente as mudanças. 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 fins e objetivos Agile entendem que você escolhe um método que funciona para você. Se você gosta de uma abordagem específica, siga-a. Se não atender às suas necessidades, altere-o. A maneira como você desenvolve o software realmente se resume a tentar fazer o melhor uso dos recursos que você tem em mãos e a minimizar as práticas que podem levar seu projeto ao fracasso. projeto em questão.

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

• Indivíduos e interações sobre processos e ferramentas
• Software que trabalha sobre uma documentação completa
• Colaboração do cliente sobre negociação de contrato
• Respondendo a mudanças após seguir um plano

e onde você reúne suas ferramentas, método e sua experiência para aplicar esses valores com sucesso.

Sim, os modelos Waterfall, Spiral, Iterative e outros processos híbridos são todos viáveis, mas a mudança é inevitável. O processo é mais do que apenas como lidar com as mudanças, e (afirmo que) o maior determinante é quão bem você conhece / entende 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" é falso, pois há um espectro de processos de desenvolvimento de software e muitas empresas sintetizam sua própria versão do modelo de processo, mudando frequentemente para um determinado projeto. Existem mais de duas abordagens viáveis ​​para o desenvolvimento de software. Embora o Waterfall e o 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, portanto deve ser minimizada.

O Agile diz: A mudança é inevitável, portanto, faça mudanças baratas.

Mas essa não é a história toda. As empresas precisam ser capazes de planejar e prever, mas o software é um processo criativo e as estimativas geralmente estão erradas. Lembre-se do triângulo bom - rápido - barato? Adicione uma quarta dimensão, processo, e você descobrirá que reduzir o esforço do processo também pode compactar o cronograma, quando as estimativas acabam incorretas e um projeto corre o risco de atrasar. O software é um processo fungível (mutável) e o Agile, Iterative, Spiral oferece a capacidade de fornecer funcionalidade incremental em intervalos mais curtos.

O Waterfall e outros modelos de processo orientados a requisitos têm controles para lidar com mudanças, por isso é impreciso dizer que o Waterfall minimiza as mudanças, é mais preciso dizer que o Waterfall reconhece e gerencia mudanças e comunica o impacto dessa mudança (porque a mudança causa impacto no cronograma quando você tem requisitos e design com antecedência). Ao criar um produto ou precisar definir totalmente os requisitos (funcionalidade), você é direcionado para 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 cascata maduras são indistinguíveis uma da outra. 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, precisa analisar qual abordagem fornecerá o menor atrito à adoção. No final, curtos ciclos de desenvolvimento, uma equipe sólida de controle de qualidade e um negócio que impulsiona o desenvolvimento são os mais importantes para a produção de software de primeira linha.