Melhor caso para se deslocar para uma metodologia de desenvolvimento ágil? [fechadas]

https://stackoverflow.com/questions/200626

03-07-2019
|

Pergunta

Se você tivesse que fazer um caso para um negócio sobre adotar ou mudar-se para uma metodologia de desenvolvimento ágil (como SCRUM ou XP etc) que caso você faria (como você vender o conceito)?

por exemplo.

Como você descreveria os conceitos e benefícios para uma pessoa não técnica?

Se você tem feito com sucesso afirmativo, qual foi a vencedora argumento / case / lógica?

Edit: A razão que eu peço é que um amigo meu (ele é o arquiteto de soluções em uma empresa) está tentando decidir como abordar a sua gestão sobre exatamente este assunto, e eu dei a ele o que eu posso em termos de sugestões. Curioso especialmente para ouvir aqueles que têm feito com sucesso um caso para se deslocar para uma methdology alinhado ao ágil.

Solução

pessoas não-técnicas estão interessados ??em projetos feitos no prazo e dentro do orçamento com boa qualidade e que satisfaça as suas necessidades no momento da entrega. Você deve se concentrar em como Agile ajuda a fornecer essas qualidades.

Às vezes é muito difícil de vender Agile a uma pessoa não técnica por dois motivos:

O conceito de não tentar planejar 100% à frente não é realmente intuitiva
Um monte de pessoas afirmam que eles usam Agile, falhar miseravelmente para entregar qualquer coisa e dar o grande SDP um mau nome

Discussão sobre Agile capacidade processo de mudanças punho.

Geralmente é mais fácil se você trabalhar com o cliente que já trabalham com você. Você poderia facilmente mostrar-lhes, por exemplo, todas as solicitações de mudanças acumuladas ao longo do tempo e mostrar como elas afetaram o cronograma e os custos do projeto. Você poderia, então, entrar em explicando como processo Agile vai ajudar a lidar com tais casos.

Na mesma linha, você poderia tomar as estimativas iniciais feitas em um 'projeto em cascata' e compará-los com os resultados da vida real.

Também gostaria de falar sobre a abordagem Agile com a qualidade. Testando durante iterações aumentar a qualidade consideravelmente. iterações curtas com feedback imediato são grande ajuda também, mencioná-los.

Outras dicas

O meu caso: A organização goleou em torno de um bom 2 anos e falharam antes de finalmente saltar para o movimento ágil ... não há melhor alternativa (a partir de agora ... opinião pessoal) para software de qualidade de produtos à taxa de que muda o mundo. Você não pode dar ao luxo de fazer as coisas da maneira antiga anymore. Alguns aprendem da maneira mais difícil.

o elefante na sala:. Só porque uma idéia é boa não significa que ele será aceito

argumentos lógicos:

loop de feedback é curto. Os clientes podem ver software trabalhando no final de cada mês / iteração, jogo com ele ... refinar e ajustar a gosto. Não há mais desenvolvedores sugando massa por um ano e voltando com um elefante embriagado para a espera do cliente para um cavalo.
Você não precisa de tudo o set em pedra (os SRS santos) antes do desenvolvimento começa a trabalhar. Você pode mudar de idéia para refletir a mudança nas prioridades de negócios / condições de mercado como o tempo passa .. (desenvolvedores não vai fazer uma birra).
Melhor comunicação : Não mais '! Este não é o que eu pedi' quando nada pode ser feito para salvar o navio. Dev falar com clientes reais em tempo real para esclarecer dúvidas e verificar se eles constroem a coisa certa. A responsabilidade recai diretamente sobre cliente + desenvolvimento para garantir que o produto certo é construído ... por falando uns aos outros .. o tempo todo.
processo humano: Agile reconhece o fato de que o software é feita por pessoas para outras pessoas As práticas facilitar a interação, aprendizagem e respeito entre a equipe.. Melhor moral também é observado
Na sequência de práticas como TDD, testes automatizados, Pair Programming, etc. levam a Melhor qualidade produtos. Tempo tradicionalmente gasto na fase de 'fixação de e-agitando-bug' no final do projeto é minimizado.
Facilidade de manutenção . testes de regressão é um SNAP! Os sistemas construídos são passíveis / mais fácil mudar / extensões .. Se bem feito. Os desenvolvedores valor simplicidade vs excesso de engenharia como uma segunda natureza. Os desenvolvedores não têm medo para 'ir lá e alterá-lo' vs 'Eu não vou tocar aquela coisa torcida .. cicatrizes da última vez ainda não curada.'
possibilidade mais realista de cumprimento de prazos devido ao desenvolvedor buy-in. As estimativas são revistas com base na velocidade da equipe real em vez de gut-estima da pessoa encarregada de criar o gráfico / MPP / plano
progressos visíveis - Big gráficos visíveis (burndowns, etc.) dizer exatamente o que está acontecendo no projeto sem ter que mina-lo fora do secretismo / pessoas relutantes / muito ocupadas. Questões estão em sua cara e não pode ser ignorado / escondido por muito tempo. Desenvolvimento não tem a mudança de contexto para o modo 'progresso relatórios' por um dia por semana para gerar informações para a gestão ... fácil reunir métricas que os desenvolvedores não parecem se importar.

Será que eu quebrar o limite de char:?)

As coisas que vendem-lo bem é:

produto tangível após cada iteração que pode ser testado, jogado com, e liberado. (Bom para o proprietário de um produto que gosta de ver o que seus / suas compras de dinheiro)
Ele traz transparência ao processo de desenvolvimento, especialmente durante stand-ups diários e assim reduz a duplicação de funcionalidade e confusão
Tendo uma demonstração após cada sprint educa colegas de trabalho sobre que direção o produto está se dirigindo, o que está disponível após o trabalho de desenvolvimento e recebe as pessoas falando e pensando sobre o que poderia torná-lo ainda melhor
Desenvolvimento pode ser feita com uma precisão razoável após uma dúzia de sprints. Pelo menos depois de algumas modificações para se concentrar fatores.
Melhora desenvolvedor buy-in como eles começam a possuir uma funcionalidade específica
Custo de mudanças de produto quando utilizar Agile tende a ser muito menor do que quando se utiliza uma cachoeira metodologia

Excelente para equipes de desenvolvimento deveras pequeno, mas requerem buy-in da equipe de desenvolvimento.

É quase impossível introduzir uma nova metodologia sem se referir especificamente a problemas com a metodologia antiga e como a nova metodologia vai corrigir esses problemas.

Na realidade, você provavelmente precisará oferecer um monte de opções e, em seguida, terminar com recomendando o seu favorito. Venha preparado com uma boa explicação de por que é o seu favorito, e com um bom conhecimento dos pontos fracos de sua metodologia escolhida.

E certifique-se que você não está confundindo a força de seu sentimento para a força de seu argumento, e que você não está tentando passar escolhas de valores pessoais e anexos culturais como avaliações técnicas objetivas. Seus colegas não são estúpidos - eles saber se você está fazendo isso, e eles rapidamente virar a pouco bozo em você

Se você quiser obter filosófica sobre isso, a comunicação não realmente dependem eloqüência, retórica, ou articulação, mas no contexto emocional em que a mensagem está sendo ouvida. As pessoas só podem ouvi-lo quando eles estão se movendo em direção a você, não quando suas palavras estão a persegui-los.

Na minha experiência, a única coisa que vende instantaneamente Scrum para a gestão não-técnico é o gráfico de burndown. A ideia de que há uma carta de papel - disponível para todos verem e compreender facilmente - que mostra progresso diário é um vencedor instante. Claramente mostra muito cedo sobre se um projeto está dentro do cronograma.

Uma vez que o atraso, sprints, diariamente scrum etc são todos necessários para fazer o trabalho gráfico de burndown, vender a idéia do gráfico burndown primeiro, em seguida, explicar que há uma necessidade para o resto de Scrum e, finalmente, salientar que é viável para realizar um julgamento de três semanas do processo com o mínimo impacto para a programação.

Eu acho que o número um ponto de venda para o negócio é que eles decidir o que você está indo para o trabalho, então eles serão definição das prioridades.

As minhas vaias, uma pessoa não técnica, geralmente preferem Listem sobre como uma nova metodologia irá melhorar a produtividade da equipe. Então, o nosso aproach para introduzir SCRUM , como Gestão metodologia, com foco em ganhos em visibilidade progresso , melhor comunicação e feedbacks mais cedo .

Todos os outros ganhos, como um fato da matéria, seens intangível para pessoas como meu chefe.

Pelo que tenho lido e ouvido o termo Agile parece ter um mau rap e assusta as pessoas. A partir de uma perspectiva de negócio Eu acho que tudo se resume a é como eu posso fornecer valor de negócios de uma forma mais ágil. Agile é um método de apoiar o conceito de entregar valor de negócio rapidamente.

Em vez de discuti-lo em termos técnicos Gostaria de sugerir o seu amigo discuti-lo em termos de negócios e afirmam que ele tem algumas idéias que poderiam ajudar a entregar valor de negócio para seus clientes finais mais rapidamente.

Eu não recomendo ele discutir XP ou ágil como os métodos, mas sim introduzir suma, entrega focado reuniões (ie SCRUM) e, em seguida, tentar crescer a partir daí. Sinto-me se você contar o negócio que você pode obter o que eles querem mais rápido e de forma mais predictible e você cumprir essa declaração que você vai ter buy-in para as práticas que você chegar lá.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow