Que métodos Ágeis de desenvolvimento de software teve mais sucesso com?[fechado]

Question

Existem inúmeros Desenvolvimento ágil de software métodos.Quais foram usadas na prática, para entregar um projeto de sucesso, e como o método de contribuir para esse sucesso?

Answer 1

Eu estive envolvida com muito poucas organizações que pretendia trabalhar em um "ágil" o caminho, e a sua processados normalmente, parecia ser a base de XP (extreme programming), mas nenhum deles nunca seguido em qualquer lugar perto de todas as práticas.

O que disse, eu provavelmente posso comentar algumas das práticas de XP

• O teste de unidade parece ser muito útil se ele é feito desde o início de um projeto, mas parece muito difícil entrar em um código já existente-base e começar a tentar adicionar testes de unidade.Se você tem a oportunidade de começar do zero, desenvolvimento orientado a testes é uma ajuda real.

• Integração contínua parece ser uma coisa realmente boa (ou melhor, a falta dele é muito ruim).Dito isso, as organizações que tenho visto têm sido geralmente tão pequenas quanto para fazer qualquer outra abordagem de parecer tolo.

• Usuário dos cartões de história são bons no que é ótimo ter um objeto físico para jogar em torno de definição de prioridades, mas eles não são quase detalhado o suficiente, a menos que o programador sabe realmente o domínio, ou você tem um restaurante no local do cliente (o que eu realmente nunca vi).

• Standup reuniões tendem a ser muito útil para os novos membros da equipe para conhecer toda a gente, e o que trabalhar.O velho mãos muito rapidamente, slack off, e dizer coisas como "eu ainda estou trabalhando em X', o que eles estão fazendo para a semana passada - É preciso um líder forte para obrigá-los a mergulhar em detalhes.

• Refatoração agora é muito mal empregado termo, mas quando você tem suficiente testes de unidade, ele é muito útil para conceitualmente separado a atividade de "mudar o projeto de código existente sem alterar a funcionalidade' de 'adicionar nova funcionalidade'

Answer 2

Scrum porque mostra onde os preguiçosos são.Ele também identifica muito mais rápido do que a unidade de negócios, geralmente, não têm a menor idéia de que eles realmente querem entregue

Answer 3

Scrum.

O daily standup meeting é uma ótima maneira para se certificar de que as coisas que ficam na pista e o progresso está sendo feito.Eu também acho que é a chave para obter o produto/mercado pessoas envolvidas no processo real, de forma significativa.Ele vai criar um ambiente de colaboração e remove um monte de contraditório lixo que vem à tona quando a equipe de produto e o dev equipas estão separadas "silos".

Answer 4

Tendo regulares retrospectivas é uma ótima maneira para ajudar a equipe a se tornarem mais eficazes/ágil.Mais do que a adesão a um tipo específico de Agile esta prática pode ajudar a equipe a identificar o que está funcionando bem e se adaptar a um ambiente em mudança.

Apenas certifique-se de que a pessoa que executa a retrospectiva sabe o que ele/ela está fazendo, caso contrário, pode degenerar em um reclamando sessão.

Há uma série de exercícios que você pode tomar uma equipe para ajudá-los a refletir e extrair valor a partir de retrospectiva.Eu sugiro ouvir a entrevista com Linda Rising em Engenharia de Software Rádio para uma boa introdução.

Fazer uma pesquisa no Google por "Heartbeat retrospectivas" para mais informações.

Answer 5

Eu tenho trabalhado com uma equipe usando o XP e Scrum práticas polvilhado com alguns magra.Tem sido muito produtivo.

Daily Standup- ajuda-nos a manter o controle do que e onde toda a gente está trabalhando.

Programação Em Par- melhorou a nossa base de código e ajudou a remover o "bobo" bugs que estão sendo introduzidos no sistema.

desenvolvimento iterativo- usando a 1 semana iterações ajudou até melhorar a nossa velocidade por definição mais direta metas que também nos ajudou requisitos de tamanho

TDD- ajudou-me a mudar o meu modo de programação, agora eu não escrever qualquer código que não corrigir uma fratura de teste e eu não escrever qualquer teste que não tem claramente definido exigência.Nós também estamos usando o executável requisitos que realmente ajudou a devs e BAs alcançar os requisitos de entendimentos.

kanban placas- mostra em tempo real onde estamos.Temos uma para o Marco, bem como a iteração atual.Em um piscar de olhos você pode ver o que está a fazer e o que está sendo feito e o que é feito e aceito.Se você não informar seu dia-standup algo pertencente à qual o conselho que você tem explicações a dar.

co-localizado equipe- todo mundo está a acelerar e na página com o que todo mundo está fazendo.a comunicação é just-in-time, muito produtivo, eu não perca o meu cubo em tudo.