XP vs gestão bom projeto tradicional [fechado]

Question

Eu estive na indústria de TI há 10 anos, mas têm trabalhado em equipas de projecto "tradicionalmente" gerenciados (ambos bem gerido e mal gerida queridos).

Eu ouvi do scrum "novo" ou do tipo XP de gerenciamento de projetos e ansiava por ser parte de um (como s / w pessoas sempre gostam nada de novo palpite I), mas não tenho uma oportunidade.

A minha pergunta é esta - Quais são suas experiências em se mudar para o modo "novo" - foi significativamente melhor ou pior ou não diferente? Houve alguma melhora taxa de sucesso do projeto ao usar modo XP do desenvolvimento ou é mesmo que todos os projetos tradicionais bem gerido?

Isso não deve ser uma questão política, mas apenas suas experiências como você se mudou para o novo mundo ou experimentado pelo menos uma vez e para trás.

Agradecemos antecipadamente

Answer 1

Antes que eu já ouvi de XP, eu tive realmente um bom gerente (Mike) em um trabalho mais cedo que eu tinha. Ele foi usado para engenheiros de gestão e transição para o gerenciamento de software. Depois de alguns maus trabalhando experiências que eu olhei de volta para o seu estilo versus conduta típica projeto que eu tinha antes e depois de trabalhar com ele.

• Met com todos, pelo menos uma vez por dia, mas nos deu espaço para trabalhar
• Usado um quadro com duas colunas, as pessoas que trabalham e que eles estão trabalhando em qualquer um poderia olhar para aquela placa e ver se algo tinha sido feito ou estava sendo feito
• Had todos cross-trem. Eu aprendi RCS e, em seguida, cvs lá e como usar arquivos make
• Ran produtiva "mortum post" quando uma tarefa foi concluída. Ele iria fazer a pergunta como "teria ajudado se X?" ou "da próxima vez, podemos tentar ..."
• todos continuaram a trabalhar em tarefas curtas e conseguiu nosso tempo por isso sempre trabalhando em algo, mas nunca tive uma tonelada de coisas empilhadas

Mike fez tudo no papel. Ele iria manter notebooks e cartões de índice com ele. Ele insistiu que nada lhe pedia pela administração ser convertidos em tarefas gerenciáveis, muitas vezes escritos em cartões de nota. Ele se recusou a ter qualquer trabalho em qualquer coisa que não podia ser claramente explicadas ou tinha um objetivo claro. Ele iria pedir os VPs "O que você quer dizer com mais rápido?" "Que tipo de métricas são os relatórios destinados a mostrar?" "Por que esse ser uma prioridade?" Ele parecia ter perto de infinita paciência, por escrito, o que precisava ser feito e que se entende por "feito"

Quando eu li o livro XP, fiquei espantado com o quanto era familiar como "o caminho Mike trabalhou"

Parece que Agile é apenas sobre a implementação de um conjunto de melhores práticas e avaliar como eles funcionam em seu ambiente. Quando eles não funcionam, alterá-los. Quando eles fazem trabalho, cumpri-los.

Eu acho que o verdadeiro problema com gestão tradicional projeto é que mais frequentemente do que não, ele realmente não existe. Estou impressionado pela forma como muitas lojas afirmam usar RUP ou código completo ou mesmo Agile e realmente não têm reconhecido qualquer coisa como gerenciamento de projetos. Claro, existem reuniões. E as pessoas chamado gerentes de projeto. Mas uma pergunta simples como "o que foi feito no projeto X" ou "o que é deixado de fazer no projeto Y" e ninguém tem uma resposta. Eles têm que cavar embora e-mails ou apontar para um arquivo de projeto MS comicamente impreciso.

Se uma pessoa alegou ser em uma dieta e não poderia responder a perguntas sobre o que comiam ou como eles estavam se exercitando; você aceitaria que eles estavam realmente em uma dieta?

Answer 2

Você pega sua bagagem de idade com você quando você vai. O que significa que quaisquer práticas de gerenciamento de projetos ruins que você tinha antes ainda vai descansar.

No entanto, vou dizer que as coisas melhoraram muito quando começamos a fechar o ciclo entre nós eo cliente. Maior e feedback mais freqüente e protótipos com os meios de clientes muito menos momentos do cliente dizendo: "Este não é o que eu queria."

Answer 3

Eu usei (a ligeiramente modificada) Scrum antes no trabalho e aqui estão meus pensamentos:

• As reuniões diárias e queimar-down fornecido motivação para progredir nas tarefas.
• Nosso gerente poderia falar com colegas do outro lado da lagoa e mostrar-lhes "é isso que estamos trabalhando este mês".
• Você sabia exatamente o que tarefas que precisava ser feito, e já tinha estimado o tempo necessário para se completar.
• Quando prioridades mudaram (novas tarefas, erros importantes adicionado), houve um processo bem definido para lidar com adicionando-os à Sprint ou simplesmente empurrá-los para o atraso.

Answer 4

Estes são adoráveis ??respostas, mas acho que confundindo gerenciamento de projetos de todos com metodologias de desenvolvimento / projeto.

Answer 5

Eu estou em uma equipe que começou Scrum há alguns meses e parece que estamos recebendo as coisas mais rápido e com muito menos "lixo" (projetos que estão sucateados). Apenas as minhas observações da nossa pequena equipe (4 devs).

Answer 6

Eu encontrei o movimento global de práticas Agile / XP muito positivos, em muitos aspectos de qualidade ele carrega frente no processo de projeto / desenvolvimento. Você vai precisar de buy-in de gestão e da equipe para realmente ver o sucesso ... algumas sugestões:

• julgamento qualquer mudança com um pequeno projeto (2-3 pessoas)
• entender quais áreas sua equipe atual pode mais melhorar (qualidade? Produtividade? Time-to-market?) E incorporar alguns Agile / XP / Scrum (o que nunca) processos em ... não incorporá-las todas em pelo ao mesmo tempo e compreender que processa endereço que questões antes de qualquer mudança
• se possível - rastrear essas áreas que você está olhando para mudar e comparar com outro projeto em execução ao mesmo tempo (o mero foco de melhorar algo, muitas vezes é suficiente para melhorá-lo, há um estudo / prazo para isso, mas eu esqueço o que é)
• às vezes você vai ver um mergulho no desempenho quando você começa um novo processo, isso faz parte da curva de aprendizagem
• nunca assumir que uma boa mudança de hoje continuará a ser uma boa mudança de amanhã, sempre rever suas áreas de projeto e estar pronto para mudar qualquer processo a qualquer momento
• nenhuma mudança permanece boa para sempre, assim como refatoração de código, refatorar seus processos
• garantir que você obtenha comprar da equipe e gestão, você não pode forçar o sucesso

Answer 7

Eu gosto de algumas das coisas que as abordagens ágeis fazer, mas eu também valorizam algumas das coisas que as abordagens tradicionais fazem.

Ambos podem trabalhar, como pode uma mistura dos dois, que é o que eu acho que funciona melhor para minha equipe agora. Eu tenho implementado desenvolvimento incremental e ele realmente nos ajuda; desenvolvimento iterativo é um pouco mais difícil e ainda estamos trabalhando nisso. No entanto, temos uma variedade de constituintes, e muitos dos nossos partes interessadas (e PMs) preferem artefatos e marcos tradicionais. Então temos que manter a encontrar o equilíbrio certo.

Eu também descobri que ainda mais importante do que a metodologia é o povo de aplicação. Pessoas boas encontrar uma maneira de fazer um bom trabalho e fazer as coisas independentemente da metodologia, embora certamente a metodologia pode ter efeitos sobre a eficiência (e moral :)). recursos mal alinhados, no entanto, pode utilizar a metodologia melhor e encontrar formas de fornecer resultados pobres.

Answer 8

Para os desenvolvedores, as grandes lições da XP & Co. são os ciclos de lançamento menores, e uma abordagem mais evolucionária - no sentido de que a mudança de requisitos é aceito como uma parte natural de qualquer projeto. Além disso, os Clientes sugerir soluções, mas os designers e desenvolvedores precisam entender os problemas.

Lições para os gestores: Os desenvolvedores não são intercambiáveis ??especificação para código-conversores, suas forças e fraquezas individuais podem fazer a diferença de produtividade de 10 ou mais para um determinado tópico. Conhecimento e experiência são os mais habilidades valiosas em sua equipe, e os desenvolvedores podem ensinar cada oterh. Os gerentes não precisa entender o que os desenvolvedores fazer a fim de reforçar os resultados desejados.

---

XP & Co. são geralmente misturando soluções para estes com o problema a fazer uma mudança empresa . O consultor heróica XP singlehandledly salvar um projeto condenado, atrasado e descarrilou atua como grande parte como um amortecedor entre desenvolvimento e gestão. Mas se você está olhando para o que aprender, você tem que separar estes aspectos.

O que eu aprendi nos últimos anos é que os erros não são uma falha de personalidade, e que o céu não cai quando a mudança especificações. Eu aprendi que, enquanto erros de projeto ainda são os mais caros para fazer, não há um único projeto "perfeito". Em vez de começar uma coisa certa precisamos implementar salvaguardas que de todos os muitos detalhes nada der errado - e eu aprendi a utilizar a margem de manobra entre o "certo" e "não é errado" a nossa vantagem.

Answer 9

A minha experiência tem sido que eu prefiro usar Scrum sobre abordagens tradicionais como isso não aconteceu muitas vezes que os requisitos poderia permanecer inalterada durante a duração de um projeto onde normalmente projectos parecem correr pelo menos 6 meses para o meu atual que é mais de um ano.

Também pode haver o caso em que não há qualquer gerenciamento de projetos e todos apenas a luta para "fazer o trabalho" para ter alguma estrutura formal é bom por nada. Há algo para a questão de como é que a equipe se unir e egos raramente aparecem, uma vez que não é código de alguém, mas sim o código da equipe e há um tipo de pensamento de grupo onde, enquanto cada pessoa tem seu ponto de vista, ninguém tenta fazer com que toda a gente vê as coisas dessa forma.

Às vezes parece-me que alguns Scrum e Agile se aproxima Eu tenho end usado por ser como corredeiras em vez de uma grande cachoeira. O que quero dizer é que o ciclo de reunir os requisitos - analisar e projetar - Executar - Test - Implantar e obter requisitos actualizados parece ser repetido várias vezes para que o que sai no final seria extremamente difícil de estado no início do projeto a menos que o patrocinador do projeto poderia dar requisitos muito detalhados que nunca iria mudar.