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

8

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?

agile development-methodologies

— minusSeven
fonte

1

+1 Esta é uma boa pergunta. Os proponentes ágeis enfatizam estudos de que o ágil é mais eficiente . É um dado adquirido que as pessoas querem melhorar como profissionais. Mas e se você não se importa com isso: e se você só quer ganhar dinheiro ? O ágil é bom para isso?

— Joonas Pulakka

13

Você parece cansado como alguém que trabalhou em uma empresa de queda ágil, experimentou a disfunção extrema e, em seguida, disseram-lhe que era ágil. Muitos de nós pensamos que entendemos quando estamos começando, e então temos pessoas mais experientes nos dizendo como deve ser feito. Nos disseram isso, mas nunca experimentamos o porquê. O Waterfall tem uma tendência para o fracasso, onde o verdadeiro Agile tem uma tendência para o sucesso e até experimentarmos o fracasso de um e o sucesso do outro que nunca saberemos verdadeiramente. Se você está pensando em benefícios financeiros, então você já prova que não entende.

— Maple_shaft

4

Ter experiência Agile em seu currículo pode fornecer benefícios monetários para você.

— jfrankcarr

3

O problema é que os clientes não são estúpidos e, se você tentar ser parasitário, eles acabarão chegando a um ponto em que não querem mais trabalhar com você. E não será o tempo que você quiser. Você quer ser mais eficiente, porque pode fazer lances mais baixos do que seu concorrente, o que proporcionará mais negócios.

— Andy

1

Um pouco questão relacionada: programmers.stackexchange.com/questions/125429/...

— SoylentGray

16

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:

insira a descrição da imagem aqui

— Joonas Pulakka
fonte

É a diferença "bom lucro" e "mau lucro". "Bom lucro" = cliente satisfeito, "Ruim lucro" = você roubou o cliente

— Atif 08/8

4

-1 Não creio que concorde com qualquer um dos seus primeiros parágrafos como uma declaração geral. Se você tem um projeto e um gerenciamento de baixa qualidade, mudar para um processo ágil não deixará repentinamente feliz a equipe, o projeto será ótimo ou os clientes apreciarão seus esforços.

— precisa saber é o seguinte

2

Bem, sim, alterar processos no meio de um projeto mal gerenciado pode não fazer diferença para esse projeto . Mudar processos como uma estratégia de longo prazo para melhorar o desempenho geral.

— 31812 DaveEtiqueta

1

-1: Primeiro, não consigo descobrir se o primeiro parágrafo está vendendo óleo de cobra ou balas de prata. Já era hora de essa indústria crescer e parar esse tipo de porcaria. Acredito que o Agile é uma abordagem melhor para o desenvolvimento de software do que o Waterfall, mas não muito melhor.

— mattnz

2

mattnz - Se você definiu bem, requisitos com escopo bem definido o cascata funciona perfeitamente. O Agile funciona melhor no mundo real ao se ajustar à fluência do escopo e às mudanças nos requisitos. Às vezes um martelo funciona e outras vezes uma chave de fenda é melhor.

— precisa saber é o seguinte

8

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.

— Mihalis Bagos
fonte

Eu gosto da sua declaração final. +1

— Andrei G

2

Na minha experiência, não há garantia absoluta de satisfação do cliente. Às vezes, eles querem o impossível e serão infelizes no quanto você se aproxima. Além disso, eles geralmente não conseguem entender a diferença entre o que querem e o que realmente precisam. No entanto, as técnicas de desenvolvimento seqüencial não são melhores que a agilidade na solução desse problema. Eles são apenas melhores na definição inicial de linguagem jurídica do que você vai entregar e não deixam espaço para o cliente verdadeiramente patológico se livrar do pagamento.

— Joris Timmermans

2

Haha sim, o cliente sempre vai querer mais, isso é verdade. No entanto, acredito que, obtendo constantemente a confirmação de que as coisas estão indo na direção certa, o produto final valerá a pena pelo menos. Então, se o cliente precisar de mais recursos, etc., já que ele concordou que o produto estava bom (na época), você pode justificar custos adicionais de desenvolvimento.

— Mihalis Bagos

Minha pesquisa me leva a acreditar que a economia de tempo na implementação de recursos é realmente menor. É a solução certa que é mais rápida.

— precisa saber é o seguinte

6

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.

— KeithS
fonte

Sua analogia é bastante falha. Para tornar a abordagem ágil mais análoga à Battleship, você teria que permitir que seu oponente alterasse a localização dos navios após cada iteração. Então sua analogia seria mais apropriada.

— Dunk

De onde veio esse mito de que os clientes dos desenvolvedores de cascatas estão sempre infelizes e o ágil teria resolvido esse problema? Parece que muitas pessoas estão bebendo o kool-aid.

— Dunk

Não era a minha analogia, e a ideia é que, mesmo tendo um plano para o que o cliente diz que quer, ser capaz de "atingir" de forma confiável o que realmente quer sem feedback ao longo do caminho sempre será mais difícil (e mais caro, já que é esperado que o cara do Agile e do Waterfall atinja todos os seus objetivos, mas o Waterfall precisará de mais dinheiro para mais rodadas de desenvolvimento).

— Keith

Dunk, você e eu já passamos pela amoreira no Agile antes. Você não gosta disso. Você não acha que funciona. Muitos discordam, mas a realidade é que, se você não gosta do Agile, sinta-se à vontade para continuar com o Waterfall. Garanto que você acabará adotando algumas das idéias que o Agile promove (como feedback rápido do cliente e o que o cliente deseja que seja feito primeiro), independentemente da metodologia SDLC que você escolher.

— Keith

Eu nunca disse que o Agile não funciona. No entanto, ele só funciona bem para certos tipos de projetos. E essa é a minha objeção. Para um agilista, ágil é a bala de prata. não existe falha em um agilista desde que você tenha uma liberação. Não importa se não atende às necessidades do cliente. No que diz respeito à adoção de algumas das idéias que o Agile promove, isso já foi realizado por praticantes bem-sucedidos de cachoeiras muito antes de o Agile ser concebido. Portanto, não dê crédito ágil por conceitos que o Agile roubou dos mesmos processos que eles reviram e criticam.

— Dunk

4

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.

— Michael Brown
fonte

Eu te dei um +1, embora não esteja claro o que você escreveu. Acho que você disse que o benefício da cascata é para contratos de oferta fixa. Qual é exatamente o meu ponto. Se sou cliente, quero saber exatamente o que meu dinheiro está comprando. Não quero pagar milhões e acabar com metade do que preciso. Como cliente, eu chamaria isso de falha. Como agilista, isso seria chamado de sucesso, porque eles têm um programa de meio trabalho. Independentemente do fato de ser bastante inútil para o cliente nesse estado.

— Dunk

Na verdade, uso o Agile para contratos de oferta fixa. Você obtém uma boa imagem do que o cliente deseja e planeja o projeto. Em seguida, use iteração e entrega rápidas para dar continuidade ao ciclo de feedback. No final, se você fizer o que é certo, acaba entregando mais do que o cliente esperava.

— Michael Brown

Ou você fica sem dinheiro muito antes de fornecer ao cliente o produto que ele precisa. Você pode ter alguns recursos importantes, mas isso não ajuda muito sem o pacote inteiro. Como eu disse antes, aviões que podem decolar, mas não pousar, não são muito úteis. No entanto, um agilista chamaria isso de sucesso.

— Dunk

Eu nunca chamaria um projeto que resulta em um sucesso incompleto do produto.

— 22712 Michael Michael

2

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.

— Stephen Senkomago Musoke
fonte

1

+! Eu acho que essa é a melhor maneira de olhar para o ágil. Como uma ferramenta na caixa para lidar com esses problemas.

— precisa saber é o seguinte

1

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.

— ozz
fonte

Contanto que seu cliente não se importe em obter um produto acabado pela metade, seus pontos serão válidos.

— Dunk

@ Dunk bem, sim, essa é a visão negativa. Eu o vejo do ponto de vista do "copo meio cheio". Eles obter os recursos corretos em primeiro lugar, com a capacidade de alterar facilmente construído dentro.

— ozz

Como engenheiro, é meu trabalho analisar todos os riscos e olhar para o cenário geral, não enterrar minha cabeça na areia e apenas olhar para a tarefa imediata em mãos e assumir que todas essas outras coisas funcionarão perfeitamente. Essa não é a visão negativa, é a visão de um profissional. Se metade de um sistema de trabalho atender às necessidades do cliente, tudo bem, o ágil pode ser a melhor abordagem, mas nunca foi o tipo de projeto em que trabalho. Também me oponho totalmente ao seu comentário "capacidade de mudar facilmente incorporada", já que a capacidade de criar software como esse requer habilidade.

— quer

@ Dunker - oh certo, você é profissional e eu não sou, qualquer que seja cara. Em nenhum lugar eu disse que a abordagem enterra a cabeça na areia. Eu nem sou um fanático ágil, observe o "suposto" em itálico na minha resposta. O Waterfall tradicional sofre exatamente os mesmos problemas, seja meio acabado ou ridiculamente acima do orçamento. Ambos os processos podem funcionar, ambos podem falhar, já vi tudo acontecer. Eu estava apenas tentando responder à pergunta original de como "pode" economizar dinheiro. Agile NÃO é uma bala de ouro, nem garante o sucesso.

— 31512 ozz

@ Dunk - vejo seus comentários sobre outros pontos. Concordo que há muitos fanáticos ágeis que o veem como uma bala de prata. Eu não sou um deles, mas acho que o Agile tem seus méritos quando feito corretamente com uma equipe madura e um cliente engajado. Eu não acho que a anologia do "plano" funcione bem, no entanto. Para construir um avião, TODAS as solicitações precisam ser conhecidas antecipadamente. Não acho que o Agile funcionaria bem nesse cenário. Mas para muitos aplicativos, talvez mais aplicativos de negócios em que o cliente tenha uma idéia confusa do que deseja / precisa, e isso muda com o tempo, o Agile funciona muito bem.

— 31512 ozz

0

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?

— JeffO
fonte