Scrum não subistitui gerenciamento de projetos

Esse assunto é de natureza polêmica. O Scrum é uma metodologia ágil focada em gerência de projetos. Na minha opinião dentre as metodologias agéis disponíveis no mercado Scrum é a mais eficiente e mais realista. Porem o que acontece é que existem vários níveis de gerenciamento começando com o planejamento diário, passando pelo gerenciamento da Sprint(Iteração) e por fim no gerenciamento do projeto.

Scrum atua no gerenciamento de tarefas, ou seja, no planejamento diário e no planejamento da Sprint. Isso por si em muitos casos não é suficiente. Em projetos de manutenção de sistemas, caso você não considere o uso do cliclo de projetos EUP, o Scrum é uma excelente opção. Em termos de desenvolvimento de sistemas pode ser uma boa opção também mas ai existem outros fatores na jogada.

O que é bom no Scrum é a questão da escalabilidade, de fato ele pode suportar o crescimento de sua equipe, através de um S.O.S ( Scrum of Scrums). Além de poder ser aplicado em projetos grandes e pequenos provendo um protocolo da comunicação e colaboração muito eficaz.



Onde os equívocos começam?

O ser humano por natureza tende a culpar qualquer coisa, inclusive outros seres humanos quando o mesmo fracassa. O mesmo acontece com ferramentas e processos, é comum que quando as coisas dão errado essas(Ferramentas,processos) são os primeiros a levar a culpa. E claro as pessoas não tem culpa nenhuma. Isso é muito errado e muito comum.

A polêmica dos Cronogramas

Muitos agilistas questionam veemente o uso de cronogramas. E dizem que eles não servem para nada e sempre estão errados. Eu particularmente tenho uma opinião agnostica sobre o assunto. Por que de fato em um projeto de software é extremamente complicado prever com precisão a data de termino de um projeto. Porem eu acho eXtremo dizer que "Cronogramas não funcionam" simplesmente por que:

• Muitos cronogramas falharam
• Um projeto de software é sempre diferente de outro projeto
• A predicatibilidade de se construir um software é menor do que a de se construir uma ponte ou uma casa.
• Só deus sabe o futuro

Ao meu ver essas questões são obvias e de fácil percepção. A verdade é que o problema não são os cronogramas, mas sim as pessoas. Pessoas são imprecisas e muitas vezes não estão capacitadas para gerenciar um projeto.

Quanto maior o projeto, e não necessariamente estou falando de projetos de missão critica, mais complicado será do gerente gerenciar. Projetos maiores ou de missão crítica exigem um gerente com muita experiência e com grandes skills de gerenciamento de projetos.

O cronograma é uma excelente ferramenta, mas muitas vezes os gerentes de projeto não conseguem utilizar bem esse recurso.

A verdade sobre projetos de software

Muitos projetos de software fracassam. E eu não estou falando de projetos que utilizam ou dizem utilizar os "recursos" clássicos da engenharia de software e rup. Projetos agéis falham também e muito... Quem duvida, confira o projeto C3.

A verdade é que a aérea de desenvolvimento de software e engenharia de software é muito nova. Comparada com Engenharia e outras aéreas a aérea nem é um espermatozóide ainda. Então podemos concluir, até mesmo pelos resultados de projetos tradicionais ou agéis, que talvez nos não estamos preparados o suficiente para desempenhar a função.

Existem profissionais muito bons e outros nem tanto, mas o fato é que só com o passar de muitos anos nos vamos amadurecer e a cada vez mais entregar produtos de qualidade.

Scrum + GP

Para finalizar que Scrum não substitui gerencia de projetos, pelo contrário um ajuda o outro. Acredito que eles se completam. Mas ainda assim necessitamos de um bom GP; O fato de simplesmente ignorar cronogramas e custos e tudo mais relacionado a abordagem tradicional não vai fazer com que os problemas sumam.

Até a próxima.

Os lemmings corporativos Vs Os buzzwords do momento

Isso mesmo lemmings é aquele joguinho do super nes, que por sinal era muito bom! Nos últimos 5 anos vem acontecendo dois fenômenos distintos nas empresas de TI, eu chamo esses fenômenos de Lemmings corporativos e Buzzwords do momento.

Vamos começar pelos lemmings. Lemmings são criaturinhas pequenas que ficam andando de uma lado pro outro até que você faça alguma coisa, que pode ser explodir uma bomba ou até mesmo matar um lemming, muitas empresas de ti no mercado se encaixam nesse cenário. Eu digo isso não só por experiência própria mas também por relatos de colegas e amigos.

Muitas empresas seguem a abordagens de desenvolvimento by the book, ou seja, a risca e isso muitas vezes é um problema. Esse fato acontece tanto para tecnologias como para processos e métodos. Um exemplo disso: A empresa usa todo o RUP e para desenvolvimento segue um padrão orientado a dados ou uma solução clássica de Swing com EJB.



OBS: Não estou criticando aplicações orientadas a dados, até por que em determinados cenários é muito mais simples e se resolve o problema de maneira muito mais eficiente do que uma abordagem OO. Também não estou criticando Swing e EJB que em determinados cenários podem realmente ser uma boa solução.

A questão é ficar seguindo essas "Arquiteturas de Referências" e os processos by the book, muitas vezes gerando um tempo de resposta muito baixo e outras até afundando o projeto literalmente. Essa filosofia é muito comum em empresas grandes que preferem seguir fazendo os projetos da mesma forma mesmo sabendo que existem perdas, mas pelo menos com a garantia de que funciona.

Tanto é que linguagens como Cobol e PL/I ainda estão por ai. Mas o fato é que existe essa tendência de seguir o caminho conhecido já. Essa abordagem tem pontos positivos e pontos negativos.

O outro fenômeno é o do Buzzwords do momento. Consiste em *palavras* mágicas, que adicionadas ao projeto dão falsas idéias de:

• Maturidade
• Solução Correta
• Elegância
  
• Confiança

Isso veio de diversas formas e ainda está muito presente. Hoje em dia se fala em arquitetura de software as pessoas pensam:

• Frameworks
• Pojos
• Web
• Ajax
• SOA

Na verdade dependendo do caso a solução pode ser essa, mas a arquitetura está muito além disso ou muito além de um mero MVC (Action/Service/Dao). Existem níveis de arquitetura e não apenas a arquitetura de aplicação.

O que acontece é que as pessoas acham que devem apenas aprender frameworks, pojos e web e pronto, já posso montar uma arquitetura, e isso no mercado tem muito!

Imagine a seguinte situação você vai ao médico por que está com dores de cabeça;

• Médico: Olá, o que você tem?
• Você: Tenho dores de cabeça doutor.
• Médico: Hm... entendo...
• Você: Mas é grave doutor, o que eu tenho?
• Médico: Câncer e se duvidar AIDS também
• Você: o que ???
• Médico: É e os remédios são A, B e C.

Totalmente absurdo não acham? Mas hoje em dia arquiteturas são montas apenas usando os buzzwords do momento, aplicando a metáfora do médico isso seria, dar uma solução arquitetural sem nem mesmo conhecer o domínio do problema.

Em termos práticos o que isso significa? Significa que enquanto você não levantar os Casos de uso/Requisitos/Features não é possível construir uma solução. Nesse ponto tanto faz se você usa casos de uso que seria uma abordagem mais RUP e Open UP, ou se você usa Features no caso do FDD ou se você usa Requisitos no caso de uma abordagem mais estilo engenharia de requisitos.

Precisamos construir software de forma pragmática, mais uns meses e essa palavra entra para lista de buzzwords também, mas equilibrando as anciendades de uma solução precoce e a possível copia de uma solução estilo leemings.

Nesses aspectos eu gosto muito da abordagem do RUP e do Open Up, se no marco de concepção essas coisas não ocorrerem e prosseguirem corretamente no marco de elaboração o projeto não avança para próxima etapa. Claro que isso pode ser perigoso, pode levar ao cascateamento do projeto.

Abraços.

Estão todos errados: Banquinho Rules!

Esse fim de semana eu estava me divertindo lendo o livro Agile Software Development: Evaluating theMethods for Your Organization do Alan S. Koch. Esse livro possui um ponto que ele fala sobre Processos, Ferramentas e Pessoas.

Simplesmente fantástico. Ele simplesmente detona os Lunáticos do Agile que dizem que Pessoas é o que importa e o resto que se dane. Na verdade ele detona também os vendor de ferramentas e os processos. O que importa na verdade é as 3 coisas e o balanceamento entre elas.

Como uma imagem fala mais do que 1000 palavras olha a imagem a baixo:

Como você pode perceber se uma dos pés do banquinho for removido ele vem a baixo. Assim [e um projeto de software os três pés são fundamentais no sucesso de um projeto. Por mais que lunáticos do movimento ágil digam "Esqueça o processo e as ferramentas fique só com as pessoas " eles estão totalmente errados.

Você consegue imaginar alguem trabalhando sem um IDE ou controle de versão ou uma ferramenta de Issue Tracking ou um editor de textos? Não! Não é possível, então esqueça essa de que apenas as pessoas basta!

Nesse banco as pessoas tem destaque, e de fato, sem pessoas não se constrói software, mas só isso não é o bastante. Os pilares, pés do banco, completam as deficiências das pessoas.
Por que pessoas se esquecem de coisas, são imprecisas e erram nos prazos, nesses pontos que um processo pode ajudar, mas valhe salientar que não estou dizendo qual, não interessa se é RUP ou algo mais agile.

Precisamos dos 3 pés do banquinho. Senão ele cai ou fica capenga, adicionado riscos desnecessários ao projeto.

Abraços.

O Papel dos Requisitos

No cenário atual do desenvolvimento Java existe uma visão errada da Engenharia de Requisitos, eu particularmente também possui essa visão. Na verdade isso se constituiu pelo fato de muitos analistas não terem a menor idéia de conceitos OO e bem como técnicas de análise orientada a objetos. Isso ocorre pelo cenário em que o Java se encontra no Brasil, quem nunca trabalhou com uma analista de mais idéia que trabalhava com alguma tecnologia legada e mal sabe o que significa polimorfismo?

O problema é ainda maior. Se fosse apenas o caso de não conhecerem OO Analisys seria uma coisa, a questão é que normalmente esse tipo de profissional mal sabe Análise estruturada Moderna e quando me refiro a isso não falo apenas de conhecer as ferramentas como DHF, DFD , ER , etc. Estou falando de método e de técnicas. Hoje em dia isso ocorre com o suposto analista OO também que por que sabe UML acredita que isso é o bastante, mas vale a pena lembrar que UML é só a linguagem e não tem método.



Estudando cada vez mais sobre o assunto percebo que é uma assunto de extrema importância e cada vez mais chego a conclusão de que existem pouquíssimos profissionais qualificados para o papel. Tudo começa com a questão dos requisitos.

O que é um requisito?

É uma característica desejada para o sistema que é observada externamente. Pode ser algo do tipo o sistema deve fornecer suporte a multi-idiomas ou algo do tipo o sistema deve permitir diferentes níveis de acesso customizaveis. Para identificar se um possível requisito podemos aplicar as seguintes perguntas:

1) É uma característica observável extremamente do sistema?
2) Satisfaz alguma necessidade do cliente?

Caso a resposta seja sim para as duas perguntas, estamos falando de um requisito.

Por que requisitos são importantes?

Primeiro que, pelo principio básico de que é bom saber o que construir antes de começar a construir, esse principio é valido por que para se atingir qualidade é necessário atingir um grau de precisão desejável.

O grande vilão são os Assumptions que fazemos. Por não investirmos tempo suficiente em requisitos acabamos fazendo softwares que não atendem as necessidades dos clientes e muitas vezes tem funcionalidades que nem são utilizadas. Por isso é importante documentar um requisito e ter claro em mente o que o sistema deve fazer.

Falando de XP

Como conselhos nunca são de mais, o problema é que as pessoas não escutam os conselhos. O grande problema do XP é tratar os requisitos de forma muito simplista e inúmeros projetos que utilizaram XP falharam. Quero deixar claro novamente que isso não é uma posição religiosa minha contra o XP e a favor do RUP como muitos já devem estar pensando nesse momento. Mas meramente fazer um User Stories não é o suficiente.

Todo o tempo gastado em cima de requisitos é bom! Quando mais cedo você detectar uma mudança ou engano mais barato será sua implementação. Essa questão dos requisitos está diretamente ligado ao problema da priorização.

A prática de priorizar é de suma importância. Meramente entregar software iterativamente e colher feedback com o usuário não é o bastante. É necessário entregar valor ao cliente.

Falando de Scrum

Esse é o ponto que o SCRUM erra! No Scrum o Product Owner é quem prioriza e dá uma importância aos itens do backlog. Tanto é que a equipe até pode discutir mas no final das contas é o P.O quem decide. Pedir para o P.O priorizar os itens do backlog é perda de tempo, muitas vezes ele ira dar a mesma importância a vários itens. Outras vezes ele irá dar prioridades muito diferentes para itens que devem entrar na mesma Sprint. Essa constatação não é somente minha mas vem também do Alan M. Davis em seu livro JERM.

Outros aspectos importantes

Aspectos importantes quando tratamos de requisitos são: identificação, clareza, rastriabilidade, gerencia e aceite. Identificar requisitos por um ID unico é uma boa idéia. A clareza deve se estabelecida atreves de sucessíveis perguntas por que? Através desse recurso que estaremos descobrindo requisitos de verdade e não a solução propriamente dita.

A rastreabilidade é muito importante. Precisamos saber quanto uma mudança em um requisito irá afetar outros requisitos, essa rastreabilidade de começar a nível de requisitos e através dos requisitos refletir casos de uso e por fim código. Esse é um ponto que as pessoas erram muito também. Muitas vezes elas não dão bola a essa questão. Já trabalhei em empresas em projetos que não queriam de jeito nenhum ter um CCB. O ideal é ter o comite de mudanças, e as mudanças partirem dos requisitos. Já participei de projetos que a análise de impacto era feito a partir do código, bom ai vocês já podem até imaginar o CAOS.

O aceite é um contrato, pode ser incorporado como parte do processo de revisão de requisitos. Em cenários corporativos onde existem múltiplos sistemas é muito importante analisar o impacto em termos de custo e tempo. Possuir esses recursos sobre requisitos irão prover uma base para aplicatibilidade dessa necessidade.

Abraços.

O Grande problema dos processos e metodologias

Nos últimos 30 anos fomos bombardeados de processos e metodologias de desenvolvimento de software. Mas mesmo nos dias de hoje existe muita discussão sobre o assunto e bem como graves problemas de interpretação das coisas como elas são.

Para começar gostaria de deixar bem claro que esse não é um artigo a favor do RUP e contra as metodologias ágeis ou vice-versa. Recomendo que os leitores que tem maior clamor religioso por metodologias que leiam a frase anterior pelo menos umas 10x. :)

Agora gostaria de estabelecer dois marcos segundo o próprio Per Kroll. Uma coisa é o modelo de cliclo de vida de um projeto que pode ser cascata, sashimi, iterativo incremental, prototipação evolutiva , etc. Outra questão é o grau de formalismo de um projeto. No grau de formalismo as coisas podem variar do RUP ao XP. Essas metodologias tem um contraste de formalismo grande.

Isso pode ser representado pela figura a baixo:




Qual é um erro crasso que as pessoas cometem ao usar RUP? Não adaptar o processo. O próprio RUP enfatiza que quem utiliza o RUP deve adaptar o processo. O Processo unificado foi a unificação de 3 metodologias mais utilizadas na época, a idéia não foi ruim, eu particularmente gosto de vários aspectos do RUP porem também gosto muito de SCRUM e de certas práticas do XP.

O fato é que as pessoas usaram o RUP de maneira errada e simplesmente instanciaram todo o processo e isso acarretou em pilhas de documentos inúteis mas repito a culpa não é do processo. O mesmo problema acontece com métodos ágeis. Se você ler o manifesto ágil até se emociona! Mas uma diferença do manifesto ágil para o RUP é que o RUP especifica tudo e o manifesto ágil não especifica nada. Mas eu não estou dizendo que isso necessariamente é um problema. São abordagens diferentes.

Mas as pessoas que erraram com o RUP vão errar com o XP e com as metodologias ágeis também. Por que o problema é a falta das práticas e do tailoring da coisa. Um dos engenheiros da Google e um dos responsáveis pelo TestNG já diz também que prefere encarar metodologias ágeis como uma caixa de ferramentas ao invés de uma ferramenta. Muitas vezes nem todas as práticas ágeis são aplicáveis a todos os projetos. Eu estou utilizando SCRUM ultimamente em uma grande corporação e lá nos não seguimos os SCRUM a risca por que muitas coisas do SCRUM simplesmente não fazem sentido no nosso ambiente.

Em que ponto que o RUP peca? Peca por que em alguns pontos ele não evolui, ele continua com uma séria de artefatos e atividades que hoje em dia não tem muito sentido. Um exemplo é que o RUP diz que o arquiteto de software deve participar de qualquer criação de uma interface, hoje em dia com a programação para interfaces isso se torna inviável e sem sentido.

Em que ponto o XP peca? Peca por que trata os requisitos de software de maneira muito simplista e dependendo do projeto isso seria um tiro no pé. Existe um grande número de projetos que usaram XP e falharam também.

Hoje em dia uma metodologia promissória e que me atrai muito é o Open Up. Que é uma metodologia que parte de um subset do RUP e agrega valor principalmente do SCRUM e práticas ágeis. Porem o Open Up também não pode ser instanciado sem o tailoring.

Até a próxima. :)

SOA: Cuidado com o Lock-In.

Hoje em dia essa com certeza é uma palavra que está no top 10 das Buzzwords dos vendors de soluções como Oracle, IBM e BEA. Todos tentam lhe vender SOA, mas eu pergunto será mesmo que isso é possível? Bom se a resposta de vocês foi sim, vou mudar a pergunta. É possível vender uma solução chamada "Compre e você será Feliz"? Bom acho que agora alguem deve ter respondido não, :). Não é possível vender SOA.

SOA é uma filosofia ou você desenvolve seus sistemas com isso em mente sempre ou nunca terá isso. Não é possível ter SOA em um produto, pelo menos não para sempre. Ok, mas e quanto a um ESB? ESB é uma excelente solução mas é uma solução para integração. Não é uma solução para qualquer problemas de uma empresa corporativa diferente do que diz a ORACLE.

Então ESB é uma grande inimigo e um grande Lock-In? Na maioria das vezes sim, que é caso da Oracle com o BPEL e o da Sonic. Bom sem falar que o BPEL da oracle ainda é muito instável e você conta facilmente nos dedos os casos de sucesso hoje em dia. Talvez isso mude mas hoje, é complicado.

O Pessoal da JCP fez um remédio para o Lock-In de um ESB que é a especificação JBI a qual o ServiceMix da Apache implementa. Na minha opinião o melhor ESB do mercado hoje.

Como diz o Jim Webber o que importa é a maneira que você encara seus sistemas. Você pode ter SOA com WebServices, Contrato e Meta-Data. SOA é uma filosofia que acredita em dar valor ao negócio, não meramente em uma sistema de interação. Mas os vendors se aproveitaram disso para criar uma nova onda de Lock-In.

Pense com cuidado quando um vendor lhe oferecer uma solução SOA. Muitas vezes a sugeria só vai para de baixo do tapete. A Solução está na concepção arquitetural dos sistemas que podem ser feitos com WebServices ou com arquiteturas mistas contendo por exemplo EJB, JMS ou até mesmo um ESB.

Abraços.

JQuery: Fazendo mais com menos?

JQuery é um biblioteca escrita em JavaScript. Seu intuito é de facilitar o desenvolvimento de scripts com JavaScript; A biblioteca facilita diversos tipos de manipulações com dados e também a chamadas Ajax. Com JQuery algumas operações que era complexas se tornam mais fáceis.

Para usar a biblioteca basta fazer o include js padrão. A Grande vantagem do JQuery é prover compatibilidade para browsers como Opera, IE, Saffari, Mozilla e outros, além de compatibilidade com CSS.

$(document).ready(function() {
alert('Ola mundo!');
}

No código acima temos a sobre-escrita da clássica função onLoad do formulário, mas dá maneira JQuery. O os códigos do JQuery devem estar dentro de alguma função para funcionarem. Para descobrirmos se o Browser é o Firefox poderíamos fazer algo do tipo:

$(document).ready(function() {
alert("O Browser é o mozilla? " + $.browser.mozilla);
});



O JQuery possibilita um série de facilidades, dentre elas eu destaco os filters. Veja o código a baixo:

$("input").filter(".btn").click(function(e){
$("#dv01").html("Hahaha! JQuery Rocks!").insertAfter("#teste");
}).end();

Nesse código estou percorrendo todos os elementos do formulário que forem do tipo "input" e que tenham a class css "btn". Após achar esses elementos estou adicionando o evento onClick em todos os resultados encontrados. Também estou programando o que acontecera se o evento OnClick for disparado. O objeto de HTML com o id "dv01" que pode ser um div por exemplo, recebera o conteúdo html. Ainda estou dizendo para posicionar o elemento após outro elemento de id "teste".

Utilizar Ajax é muito simples também, pode ser feito com o simples código:

$("#meuDiv").load('TesteJQuery2.html');

Sendo que esse código deve estar dentro de uma função para funcionar. Para chamas mais complexas ou quando você precisa de uma função de callback o JQuery possui outras opções mais avançadas para o uso de Ajax. Você pode encontrar essas informações e muito mais no livro JQuery in Action.

Atenção: É evidente que o uso de JQuery facilita o trabalho com JavaScript, mas não posso deixar de lembrar que o fato de usar JQuery não significa mais performance. JavaScript deve ser usado com cautela, aplicações 100% podem ter problemas com os browsers dos clientes. Eu já trabalhei em uma empresa em que o projeto era 100% Ajax e browser em questão parado sem o usuário fazer nada pesava 90mb na memória do cliente.

Até próxima. :)

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.