O que é um projeto de sucesso

Em uma discussão na lista AN-BR, o Luiz Cláudio Parzianello fez um comentário que gostei bastante:

Só para você ter idéia, costumo apresentar os seguintes critérios de sucesso para um projeto de software em minhas apresentações:

• Cliente satisfeito com o investimento
• Fornecedor satisfeito com o lucro
• Usuários satisfeitos e elogiando o produto
• Equipe satisfeita e orgulhosa dos resultados
• Equipe ainda mais competente
• Todos prontos para um novo projeto!

Isso pode parecer utópico para muita gente, mas já existem empresas vivenciando diariamente esses critérios em seus ambientes de negócio.

Créditos para o Luiz Cláudio Parzianello

Ronan Lucio Pereira

Boas Práticas para a Melhoria do Processo de Desenvolvimento de Software

Dando continuidade ao post 3 Palavras-Chave Para a Melhoria do Processo de Desenvolvimento de Software, vamos falar sobre algumas práticas e ferramentas que têm nos ajudado (bastante) a melhorar a eficiência, segurança e produtividade na nossa equipe.

Este post é uma compilação do trabalho de melhoria do processo de desenvolvimento de software e do setor (de desenvolvimento) como um todo, que temos feito nos últimos anos.

A intenção aqui é de compartilhar a nossa experiência, de forma que sirva de inspiração também para outros colegas de profissão, discuti-las e evolui-las.

Especialista ou Generalista?

OK, voltamos à boa e velha discussão: Especialista ou Generalista?
Pelo número de recorrências que eu tenho visto sobre o tema, entendo que este ainda não está encerrado.

A minha opinião é que “você precisa ser bom no que faz.” (ponto)

Isso quer dizer que você precisa ser:

• Especialista o suficiente para executar a sua função, com qualidade;
• Especialista o suficiente para buscar e aplicar novas propostas/melhorias para as suas atividades;
• Generalista o suficiente para entender o todo a sua volta.

Vamos a um exemplo:

Protegendo a Equipe

Um ponto importante para um processo de desenvolvimento de software eficiente, é que a equipe consiga trabalhar, de fato, no projeto.

A empresa pode ter um processo eficiente, com bons procedimentos, regras, ferramentas e pessoas certas, porém, se a equipe não estiver protegida de interferências externas, boa parte da eficiência do processo cai por água abaixo.

A razão disto é a mesma citada no post “A Importância de Manter o Foco no Projeto”: A mudança de contextos.

Para evitar a mudança de contextos (e a perda de produtividade) é preciso manter o foco no projeto.

Para isso é importante que clientes de projetos anteriores não tenham contato direto com a equipe de desenvolvimento, ou seja, a equipe de desenvolvimento não deve ser transformada em uma equipe de suporte. São tarefas distintas.
Preferencialmente o pessoal do Service Desk deve fazer o contato com a equipe técnica (através de um suporte nível 2) – Isso fará que a equipe seja interrompida apenas quando necessário.

A Importância de Manter o Foco no Projeto

Quando uma equipe precisa trabalhar em vários projetos, a mudança de contextos entre um projeto e outro é um dos fatores que quebram a produtividade.

Quando um profissional precisa mudar de um projeto para outro, ele(a) “precisa” mover o foco do projeto atual para um novo domínio (de problema e de solução).

Uma vez que o profissional está focado em gerar soluções para a aplicação em desenvolvimento, é comum que a mudança de foco para outro projeto não aconteça por inteiro.
Mesmo contra vontade, o profissional ainda fica com a mente parcialmente focada nos problemas do projeto anterior.

Este processo de “desintoxicação” do projeto atual e “reabsorção” do novo contexto não costuma acontecer imediatamente, e é uma fonte bastante comum de queda de produtividade.

O Novo Gerente de Projetos

Um assunto que costuma render bons debates é quanto ao papel do Gerente de Projetos no cenário atual, principalmente quando nos referimos a Projetos Ágeis.

A minha opinião é que o papel do Gerente de Projetos, no seu conceito tradicional, deverá sofrer mudanças expressivas nas empresa de tecnologia ou empresas orientadas à criatividade e inovação.
Ou seja, nas empresas onde a inovação, criatividade e produtividade do setor de tecnologia impactam diretamente no core business. Ou ainda, para as empresa que não vêem a TI como um centro de custos, mas como um setor estratégico para o negócio.

Estimativas Incertas

CONE DA INCERTEZA

 
No livro Agile Estimating and Planing, Mike Cohn comenta sobre o Cone da Incerteza, um conceito de Barry Boehm, introduzido em 1981.

Segundo Boehm, as estimativas vão ficando mais precisas a medida que o projeto avança.

3 Palavras-Chave Para a Melhoria do Processo de Desenvolvimento de Software

Após escrever o post Fortalecendo os Processos de Negócio e falar um pouco sobre a importância de um processo de desenvolvimento de software eficiente, vamos dar continuidade ao tema falando um pouco sobre como tornar isso possível.

Neste post falaremos mais conceitualmente sobre o assunto e, em um próximo post, faremos uma abordagem mais técnica sobre algumas mudanças que aplicamos e que, de fato, trouxeram maior eficiência ao nosso processo de desenvolvimento.

Agile tem que Produzir Valor

No Agiles2009 de Florianópolis eu tive o prazer de assistir a excelente palestra do David Hussman: Coaching Agility and Producing Value.

David iniciou a palestra com duas perguntas:

1) How can I coach agile? (Como eu posso treinar metodologias ágeis?)

E complementou:
- Não. A pergunta não deve ser essa.
- A pergunta deve ser:

2) How can I produce value? (Como eu posso produzir valor para o negócio?)

Qual o papel do Analista de Negócios em um projeto ágil?

Em um artigo publicado no blog “Zen Agile” o autor fez o seguinte comentário:

“So what is a business analyst’s role in an agile world? There is no BA role. But everyone should definitely have a business analysts skills.”

http://zenagile.wordpress.com/2009/11/24/what-is-a-business-analysts-role-in-an-agile-world/

Ele diz que não há um papel para um Analista de Negócios em um projeto ágil, mas que toda a equipe deve ter habilidades de Analistas de Negócios.

Como eu não concordo totalmente com esta afirmação, vou responder a pergunta expondo a minha opinião:

Qual o papel do Analista de Negócios em um projeto ágil?

O papel de um Analista de Negócios (AN) em um projeto ágil é o mesmo que em qualquer outro projeto ou metodologia: Entender os objetivos e metas do negócios, seus processos mais críticos e trabalhar para que o desenvolvimento proceda dentro desta expectativa.

Uma das coisas que muda em um projeto ágil é que alguns profissionais (como eu) defendem que no Scrum (que é apenas uma das metodologias) o AN é um grande candidato a fazer o papel de Product Owner (PO), atuando como uma ponte entre o cliente real e a equipe. Ele passa a ser o cliente “presente”.

O que muda também é que o desenvolvimento ágil dá maior valor aos relacionamentos e a comunicação.
Isso faz com que o AN esteja presente, junto a equipe, discutindo os Requisitos e transmitindo o conhecimento adquirido sobre o negócio.

Sim, em desenvolvimento ágil é muito importante que a equipe também tenha conhecimento sobre o negócio, porém, na maioria dos casos é preciso que alguém assuma a responsabilidade sobre este conhecimento e priorize esta tarefa.
Este alguém é o Analista de Negócios.

Ronan Lucio