Commercial pressures of today’s economy result in imposed deadlines being the norm for technology projects. Yet the nature of software projects demands that teams deal with the constant dynamics of change. This creates extreme degrees of project risk and perpetuates the so-called “software crisis,” whereby a large percentage of projects are canceled, delivered late, over budget, and/or poor quality. However, knowing the nature of these dynamics empowers managers to make decisions on promised functionality, thereby controlling the very factors that degrade software quality and reliability.

Fonte: http://www.cutter.com/workshops/03.html

Atualização em 18/08/09 – Depois de esvaziar o buffer neste post, continuei lendo e pesquisando sorbe o assunto. Pretendo formatar um modelo que funcione bem para as características específicas aqui da Myfreecomm. Nas leituras achei este post que responde exatamente as minhas perguntas.

Atualização em 06/08/09 – A questão não é a literatura sobre P.O. e Scrum Master em si, mas o que é vivenciado na prática. Algumas literaturas dizem que o P.O. deve ser o cliente, outras dizem que pode ser um representante dele e por aí vai. Minha idéia é tentar entender como isso funciona em alguns casos práticos. Realmente a pergunta no título ficou muito ruim, deveria ser: Como funciona pra você?

***

Este post é fruto de uma conversa que tive ontem sobre a necessidade de delimitar as responsabilidades de cada papel no SCRUM. Essa conversa vai de encontro com um ponto que queremos melhorar no processo desenvolvimento na Myfreecomm.

Geramos algumas dúvidas que eu não sei a resposta exata, mas pretendo respondê-las após alguns estudos e experimentos na prática. Se você tiver alguma resposta, deixe um comentário.

O P.O. é o cliente? Cliente e P.O. são as mesmas coisas? O P.O. tem que ser necessariamente o representante do cliente?

O P.O. precisa entender de software?

É papel do P.O.trazer o que ele quer já detalhado em forma de itens do software a ser desenvolvido ou é papel do Scrum Master entender a necessidade de negócio e traduzir em software?

Dado um cliente externo (ou interno off-site) não se faz necessário designar um “P.O. Interno” que seja um analista e que faça a ponte com o cliente?

O “P.O. Interno” pode ser o Scrum Master, dado o fato de que o Scrum Master entende de tecnologia e é um analista de sistema em geral?

É responsabilidade do Scrum Master definir o prazo real para o desenvolvimento e demonstrar ao P.O. no Sprint Planning ou é responsabilidade do P.O. ter o entendimento de desenvolvimento para criticar o prazo estipulado?

Qual a sua opinião?

Eu fiz uma palestra sobre a gestão do desenvolvimento de software na Myfreecomm para uma empresa parceira. Abaixo a apresentação publicada no SlideShare

Gostaria de agradecer ao Juan Bernabó da Teamware que me ajudou bastante no processo de aprendizado e deu boas dicas de implementação que viabilizaram o rápido sucesso em nossos processos na Myfreecomm. A Teamware é uma empresa líder em consultoria e treinamento de equipes de desenvolvimento que estão adotando processos ágeis.

Para conferir todas as minhas palestras, visite meu perfil do SlideShare.

Abraço e até a próxima.

Na Myfreecom criamos uma série de regras que são o início do que virá a ser o conjunto de melhores práticas no desenvolvimento de software na empresa. “O Rei” é a inteligência superior resultante da opinião pessoal de cada um em relação a desenvolvimento de software.

Todos nós temos estas “melhores práticas” definidas em nossa mente, mas nem sempre elas são iguais entre a equipe. Esta diferença muitas vezes causa frustação, pois nem sempre as práticas do companheiro de equipe atinge nossas espectativas, ou vice-versa.

O Rei da Myfreecomm diz:

Programação

• Todo o código de programação deve ser escrito em inglês.
• Os nomes de variáveis são em inglês.
• Os parâmetros são em inglês.
• Não devemos usar abreviação em variáveis e parâmetros.
• Nunca uma variável e parâmetro terá apenas uma letra, ela será sempre uma palavra (em inglês) auto-explicativa (com excessão de variáveis locais em iteração, exemplo clássico a variável “i”).
• Nunca suponha em seu código qual será o endereço de uma url ou localização de arquivo. Mantenha suas funções parametrizadas.
• Nunca coloque o nome do produto ou do cliente em variáveis ou nome de projetos.
  

Deployment

• Nunca duplique um código.
• Quando pensar em duplicar um código, por precisar de uma solução rápida e mais segura, Pare!
• Um código deve sempre estar em um ÚNICO lugar nos ambientes de produção.
• Uma hora ganha por duplicar o código hoje, equivale a uma semana perdida amanhã.

Banco de Dados

• O banco de dados é sagrado, apenas uma programação (a dona do bd) deve ter permissão de acesso.
• Não escreva qualquer programação que acesse direto o bd, além da dona, mesmo que seja apenas para leitura.
• Os nomes de banco de dados, tabelas e campos.. em inglês.
• Nunca teste um código em um banco de dados em produção, pois você destruirá a integridade das informações do banco.

URL

• A definição de uma URL de acesso interno é um recurso caro. O custo de mudança é muito alto.
• Ao definir uma URL de acesso interno, pense bem no escopo em que ela se encontra e abstraia o máximo possível.
• Não use caracter “_” em domínios e sub-domínios, o Internet Explorer vai te dar uma rasteira.
• Prefira “-” para substituir o espaço nos domínios e sub-domínios.

Nós acreditamos que esta lista é dinâmica e nunca se completará. Conforme formos trabalhando, aprendendo novas tecnologias, o Rei vai soltando mais regrinhas e a euipe vai mantendo a equipe com uma idéia única. Sabemos que esta lista mesmo está incompleta ainda…

Acreditamos também que não existe uma única lista “correta” e que cada empresa vai achar o seu conjunto de melhores práticas, de acordo com a sua situação, mercado e visão.

Não tenho dúvidas, que O Rei da Improve-it, por exemplo, vai dizer muita coisa em relação à testes, BDD e afins…

E você, o que acha destas regras, discorda de alguma? Alguma vez já escreveu seu conjunto de melhores práticas? O que o Rei da sua empresa diz?

Convido cada um postar em seu blog a sua lista de melhores práticas e colocar um trackback para cá, que tal?

Seria um MEME interessante, talvez com o apoio de blogs mais fortes, que lêem este, conseguimos começar a trocar uma idéia sobre esse assunto

Abraços e até a próxima.

Não posso deixar de escrever aqui sobre o FinanceDesktop. Este programa é maravilhoso para organização de finanças pessoais. Não é a toa que foi a “Escolha INFO” da Revista INFO Exame.

Estou trabalhando neste produto e posso dizer que por conta disso estarei escrevendo sobre algumas tecnologias bem avançadas no que tange ao desenvolvimento de software híbrido, ou seja, desktop e web ao mesmo tempo.

Não perca tempo e faça uma avaliação do FinanceDesktop.

Abraços