Quais são os benefícios monetários de se tornar ágil? [fechadas]

Por que ser ágil ? Essa é a primeira pergunta que me vem à cabeça quando penso em me tornar ágil. Quais são os possíveis benefícios financeiros que se pode obter com a agilidade?

A maioria de nós certamente gosta de pensar em clientes e clientes como alguém que não sabe o que deseja. Então, por que ajudá-los? Por que não chupar seu dinheiro sendo uma empresa parasitária e torná-los mais estúpidos a cada dia. O desenvolvimento de software tradicional não é ruim e é provavelmente (principalmente até onde eu vi) um ambiente muito mais fácil de trabalhar em vez de projetos ágeis.

Então, por que ser ágil? O que o ágil pode dar a mais (quero dizer financeiramente) que o desenvolvimento tradicional de software não pode?

O Agile produz melhores resultados (mais perto do que o cliente precisa , não necessariamente o que ele inicialmente diz que quer ), em menos tempo = dinheiro (ou pelo menos com estimativas mais confiáveis). É simplesmente uma maneira melhor de conduzir projetos (em comparação com "cascata"). Os clientes estão mais felizes. Programadores são mais felizes. Projetos são melhores. A comunicação é verdadeira e transparente. A vida é boa. Como não gostar, no sentido profissional?

Se você tiver bons vendedores, poderá vender porcaria aos seus clientes e cobrar mais deles. Financeiramente, isso faz sentido. A realidade é muito mais complicada do que a visão ingênua "se você deixar os clientes felizes, suas vendas aumentarão; se você desapontá-los, suas vendas diminuirão". O mundo não é um lugar justo. Você pode ganhar a vida como um parasita imbecil. Muitos fazem. É sua escolha se você quer ser um. Se você é, eu não vou brincar com você.

Não é um truque ganhar muito dinheiro, se tudo o que você quer fazer é ganhar muito dinheiro. ~ "Everett Sloane" em Citizen Kane

Além disso:

Eu suspeito que por "tradicional" você quer dizer algum tipo de fluxo de trabalho em cascata.

Os benefícios monetários são muitos. O horário de trabalho necessário para a implementação de um recurso extra é o principal. Você não pode interromper o processo depois de iniciá-lo; portanto, se o cliente não estiver satisfeito com o que recebe (e, sendo "estúpido", o cliente só se preocupa em fazer o trabalho dele, por isso, se o seu software não fizer esse trabalho) corretamente, você perderá o cliente).

Outra é a garantia de satisfação do cliente, o que também gera mais vendas e clientes mais felizes (e queremos isso da perspectiva do negócio).

Ter a capacidade de avaliar o ciclo de desenvolvimento também significa que você pode se adaptar às melhorias tecnológicas (por exemplo, asp.NET mvc 4 que está chegando no momento), o que também economiza muito tempo. Depois de definir uma especificação estrita para o projeto, você não pode atualizar para uma nova / melhor tecnologia / biblioteca / ativo que também economizaria tempo.

Tempo é dinheiro.

Vi uma demonstração que é uma boa analogia dos benefícios do Agile em relação aos métodos mais tradicionais. É baseado no jogo Battleship. Você e o outro jogador sentam-se à grade normal do Battleship. Vocês dois têm 20 fotos, cada uma custando US $ 5.000 para uma despesa total inicial de 100.000. Aqui está o problema; você precisa planejar TODOS os seus tiros antes de disparar um único. Seu oponente dispara seus tiros "normalmente"; dê um tiro, veja o que acontece, dê outro tiro.

No final de 20 tiros, adivinha quem marcou mais hits?

A analogia se traduz em Agile vs Waterfall de maneira bastante limpa; No Agile, você pode levar em consideração a soma total de tudo o que já fez ao planejar o que fará a seguir. Você terá uma idéia básica das áreas que serão difíceis e das áreas que serão fáceis com base nas dificuldades ou na falta de dificuldade que você já teve. Você também recebeu feedback do seu cliente em partes menores, afirmando que ele gostou ou não, e pode incorporar esse conhecimento rapidamente, sem ter construído muito código adicional sobre algo que o cliente diz estar errado .

Nas metodologias tradicionais do Waterfall, todo o sistema e o cronograma de desenvolvimento são planejados antes do início da codificação. Essa é a abordagem "planeje todos os tiros antes de disparar um"; você pode entregar exatamente o que o cliente pediu, mas eles podem dar uma olhada e dizer "não é disso que precisamos". Sim, você recebe seu dinheiro porque entregou de acordo com os termos do contrato, mas seus desenvolvedores desperdiçaram seu tempo, seu cliente desperdiçou seu dinheiro e nem estão satisfeitos com o resultado. O Agile foi projetado para ajudar nisso, permitindo que os requisitos do projeto sejam alterados enquanto o desenvolvimento está em andamento. Tudo o que você ainda não fez está aberto a mudanças; tudo o que você já fez também pode mudar,

Além disso, como o cliente decide primeiro o que você trabalha e, com você entregando pequenos pedaços de trabalho concluído com mais frequência, é possível que o cliente tenha um sistema que possa usar mais cedo. Esse ROI é visível para o seu cliente, o que geralmente torna o cliente mais disposto a participar desse processo de desenvolvimento mais envolvido.

Para mim, o benefício vem ao fazer contratos de oferta fixa. Consegui ganhar contratos de lances fixos e estabelecer uma taxa horária efetiva que eu teria vergonha de falar usando métodos ágeis. Mas também exige uma equipe talentosa que se uniu para fazer valer a pena.

Você está certo, é mais fácil fazer um trabalho ruim, faturando o tempo todo. Tendo trabalhado no setor há 16 anos, já vi meu escândalo. Especialmente durante o boom das pontocom. É até possível executar o mesmo golpe, escapando repetidamente dele. Mas a mesma coisa é possível em qualquer setor. Fui enganado por oficinas de reparação de automóveis. Até os supostamente "respeitáveis". Você ouve histórias praticamente todos os dias sobre contadores desviados de seus clientes, pregadores roubando de suas igrejas, políticos recebendo subornos de grandes empresas. E todos esses são classificados como crimes de "colarinho branco" como se isso o tornasse melhor. Oh, eles roubaram milhões de dólares de seus acionistas, mas foi um crime de colarinho branco.

Não há nada para impedi-lo de tirar proveito da confiança e das expectativas das pessoas. Pessoalmente, é uma questão de orgulho. Prefiro ir para a cama sabendo que superei as expectativas daqueles com quem trabalho.

O Agile resolve o problema de como "entregar" software de qualidade com:

a) Alteração dos requisitos - mesmo quando o espaço do problema é muito claro, requisitos não funcionais, como desempenho, segurança, conformidade, etc., podem alterar a funcionalidade principal.

b) Prazos de entrega curtos - o tempo de colocação no mercado é extremamente crítico, portanto, é necessário tomar decisões sobre o que está concluído e os clientes podem esperar receber.

c) Tecnologias em rápida mudança - as mudanças na tecnologia são tão rápidas que dificulta o andamento dos projetos.

d) Aprimoramentos e mudanças nas condições do mercado - as soluções precisam evoluir rapidamente para atender às mudanças nas condições do mercado e adicionar recursos para competir com outros produtos.

Bem, o Agile visa obter um produto acabado em uma data exata.

A cachoeira tradicional se deveria fazer o mesmo, mas geralmente sofre devido à fluência do escopo não ser gerenciada corretamente.

O Agile deve gerenciar melhor isso para guiar o "negócio" para ajudar a impulsionar recursos importantes a terem maior prioridade e serem entregues primeiro. A prioridade dos itens pode mudar no projeto à medida que novas informações se tornam disponíveis.

O benefício é que você fornece algo mais útil, em vez de ficar preso constantemente, perdendo prazos.

Se criar um software melhor não lhe render mais dinheiro, você tem um problema de negócios e não um problema de metodologia de desenvolvimento.

Por que não chupar seu dinheiro sendo uma empresa parasitária e torná-lo mais estúpido a cada dia.

Por que não proporcionar um benefício real à empresa em que eles fazem a conexão dos seus serviços com a lucratividade deles?