O que faz a diferença usando XP, Rup, Scrum ?
Estou participando de um projeto de Governança de TI. Nos últimos 2 meses venho estudando: XP, Agile, Scrum, Rup, metodologia, processos, universo e tudo mais :) Essa também é minha desculpa de TCR por não estar postando tanto como o de costume.
Estou em um projeto de Governança de Ti e para criar processos e metodologia estamos usando Scrum entre outras práticas e valores agíeis. Venho lendo muito sobre o assunto, mas não me refiro apenas a métodos agíeis mais também ao Processo Unificado e tudo mais.
Acredito que em determinados cenários uma metodologia seja melhor que outra, mas isso não é regra geral. Em projetos que Compliance é fundamental acredito que algo mais ágil como o XP de maneira pura seja bem complicado. Em outras vias em um projeto com uma equipe pequena e um escopo de 3 meses , acredito que usar Rup seria um tiro no pé.
Do Processo unificado as metodologias ágeis existe um grande abismo de discrepâncias. O Rup tira muito peso das pessoas e coloca no processo, isso não significa que quando alguem usa Rup as competências técnicas das pessoas devem ser ignoradas, mas significa evitar as coisas do tipo "Está na cabeça do fulano" ai o fulano sai da empresa... bom ai vocês já sabem. Já as metodologias agíeis como o Xp pregam que o importante são as pessoas, funciona bem. mas você deve manter as pessoas nas empresa. Agora vou fazer um parênteses ( Não é um critica ao Xp ou aos métodos ágeis mas do jeito que está o mercado Java hoje em dia, acho complicado manter uma equipe por mais de 2 anos).
Mas usar Xp ou Rup não irá garantir que um projeto tenha sucesso, nem mesmo meramente ter pessoas vai garantir isso; Por que estou falando disso? Bom recorrendo ao Scott Ambler (no EUP, que basicamente é o Rup porem adicionado as fazes de manutenção e desativação) que já mostrou a importância da fase de manutenção de um sistema. A Sun fez uma pesquisa e o resultado foi que 80% do esforço em cima do um código fonte está na manutenção e apenas 20% em sua construção, logo apenas ter pessoas boas e fazer o software pode não ser o suficiente. Muitas vezes o sucesso depende da manutenção do sistema, e o custo para adicionar funcionalidades novas.
O que vai fazer a diferença entre Rup e Xp e tudo mais? Práticas! As práticas vão fazer a diferença, pode parecer simplório, mas nesse ponto que a maioria dos projetos falham. Eu nunca vi um projeto falhar por que os desenvolvedores utilizaram if ao invez de switch. Os projetos falham por conta da gerência e da Arquitetura.
Segundo o Open Up os papéis mais importantes são os de Arquiteto e Gerente de projetos. E não é por nada isso, o Rup já é centrado na arquitetura, O Scrum é centrado em tarefas de baixa granularidade, leia-se, micro-ambiente. As práticas para Arquitetura e GP são fundamentais.
Algumas práticas importantes
Projeto Interativo: Desenvolva seu projeto em interações, isso pode parecer ridículo, mas mesmo nos dias de hoje eu já participei de projetos em cascata. Essa prática é fundamental, com releases freqüentes podemos colher feed-back e aplicar melhorias continuas ao nosso trabalho.
Riscos: Fazer com que o projeto seja orientado a riscos é fundamental, mitigar riscos não é uma tarefa apenas do gerente de projetos e sim da equipe toda. Apenas levantar riscos no documento de visão(Rup) não é o suficiente, é necessário criar planos de ação para os riscos e estar sempre de olho neles.
Priorização de Tarefas: Esse é outro fator que todos erramos, 45% das funcionalidades entregas nunca são utilizadas e 19% raramente são utilizadas, logo entregar funcionalidades com valor para o cliente é fundamental. A priorização não pode partir do cliente( ou no Scrum Product Owner) apenas deve partir de todas a equipe, leia-se, Arquiteto, QA, Desenvolvedor, Gerente e cliente.
Ajuste o processo: Se você esta usando: Rup, Xp, Scrum, FDD, Open Up ou algo do gênero, não esqueça de adaptar o processo ao sua realidade. Não utilize cegamente as metodologias como se fosse leis, você deve adapta-las a sua realidade. Qualquer extremo é sempre ruim, sempre devemos buscar o ponto de equilíbrio.
Existem outras práticas muito importantes como: utilizar Patterns, Centrar o desenvolvimento na Arquitetura, entre outras, mas isso já é uma conversa para outro dia :). Lembre-se as práticas fazem a diferença, não adianta usar uma metodologia e sair produzindo artefatos ( ou não, no caso de ágile) sem utilizar as práticas.
Até a próxima.
Estou em um projeto de Governança de Ti e para criar processos e metodologia estamos usando Scrum entre outras práticas e valores agíeis. Venho lendo muito sobre o assunto, mas não me refiro apenas a métodos agíeis mais também ao Processo Unificado e tudo mais.
Acredito que em determinados cenários uma metodologia seja melhor que outra, mas isso não é regra geral. Em projetos que Compliance é fundamental acredito que algo mais ágil como o XP de maneira pura seja bem complicado. Em outras vias em um projeto com uma equipe pequena e um escopo de 3 meses , acredito que usar Rup seria um tiro no pé.
Do Processo unificado as metodologias ágeis existe um grande abismo de discrepâncias. O Rup tira muito peso das pessoas e coloca no processo, isso não significa que quando alguem usa Rup as competências técnicas das pessoas devem ser ignoradas, mas significa evitar as coisas do tipo "Está na cabeça do fulano" ai o fulano sai da empresa... bom ai vocês já sabem. Já as metodologias agíeis como o Xp pregam que o importante são as pessoas, funciona bem. mas você deve manter as pessoas nas empresa. Agora vou fazer um parênteses ( Não é um critica ao Xp ou aos métodos ágeis mas do jeito que está o mercado Java hoje em dia, acho complicado manter uma equipe por mais de 2 anos).
Mas usar Xp ou Rup não irá garantir que um projeto tenha sucesso, nem mesmo meramente ter pessoas vai garantir isso; Por que estou falando disso? Bom recorrendo ao Scott Ambler (no EUP, que basicamente é o Rup porem adicionado as fazes de manutenção e desativação) que já mostrou a importância da fase de manutenção de um sistema. A Sun fez uma pesquisa e o resultado foi que 80% do esforço em cima do um código fonte está na manutenção e apenas 20% em sua construção, logo apenas ter pessoas boas e fazer o software pode não ser o suficiente. Muitas vezes o sucesso depende da manutenção do sistema, e o custo para adicionar funcionalidades novas.
O que vai fazer a diferença entre Rup e Xp e tudo mais? Práticas! As práticas vão fazer a diferença, pode parecer simplório, mas nesse ponto que a maioria dos projetos falham. Eu nunca vi um projeto falhar por que os desenvolvedores utilizaram if ao invez de switch. Os projetos falham por conta da gerência e da Arquitetura.
Segundo o Open Up os papéis mais importantes são os de Arquiteto e Gerente de projetos. E não é por nada isso, o Rup já é centrado na arquitetura, O Scrum é centrado em tarefas de baixa granularidade, leia-se, micro-ambiente. As práticas para Arquitetura e GP são fundamentais.
Algumas práticas importantes
Projeto Interativo: Desenvolva seu projeto em interações, isso pode parecer ridículo, mas mesmo nos dias de hoje eu já participei de projetos em cascata. Essa prática é fundamental, com releases freqüentes podemos colher feed-back e aplicar melhorias continuas ao nosso trabalho.
Riscos: Fazer com que o projeto seja orientado a riscos é fundamental, mitigar riscos não é uma tarefa apenas do gerente de projetos e sim da equipe toda. Apenas levantar riscos no documento de visão(Rup) não é o suficiente, é necessário criar planos de ação para os riscos e estar sempre de olho neles.
Priorização de Tarefas: Esse é outro fator que todos erramos, 45% das funcionalidades entregas nunca são utilizadas e 19% raramente são utilizadas, logo entregar funcionalidades com valor para o cliente é fundamental. A priorização não pode partir do cliente( ou no Scrum Product Owner) apenas deve partir de todas a equipe, leia-se, Arquiteto, QA, Desenvolvedor, Gerente e cliente.
Ajuste o processo: Se você esta usando: Rup, Xp, Scrum, FDD, Open Up ou algo do gênero, não esqueça de adaptar o processo ao sua realidade. Não utilize cegamente as metodologias como se fosse leis, você deve adapta-las a sua realidade. Qualquer extremo é sempre ruim, sempre devemos buscar o ponto de equilíbrio.
Existem outras práticas muito importantes como: utilizar Patterns, Centrar o desenvolvimento na Arquitetura, entre outras, mas isso já é uma conversa para outro dia :). Lembre-se as práticas fazem a diferença, não adianta usar uma metodologia e sair produzindo artefatos ( ou não, no caso de ágile) sem utilizar as práticas.
Até a próxima.
