Implantar um processo de software é fácil?
Atualmente suspeito muito de resultados de implantação de
processos defendidos por CIOs, e/ou representantes de empresas em congressos e
reuniões. Estas pessoas tem habilidades ímpares de comunicação e convencimento
e podem induzir outras empresas e pessoas ao erro. Particularmente, gosto de
apresentações realistas onde são mostrados os pontos de sucesso mas principalmente as falhas, pois
através dos erros podemos enriquecer a discussão. Aqui gostaria de ressaltar a
apresentação do Antônio Zegunis,
onde ele mostra os pontos que foram falhos e as lições aprendidas na
implantação da metodologia ágil SCRUM.
Será que se tudo fosse tão bonito como se prega ainda
teríamos índices tão altos de falhas nos projetos de TI? É para se pensar!
Acho que cada empresa possui necessidades distintas, algumas
se adaptam com metodologias ágeis e outras com metodologias mais formais. Independente
da abordagem escolhida, acho que as empresas falham em três pontos, o primeiro
seria o objetivo da implantação do processo, o segundo, conhecer a forma de
trabalho e em terceiro envolver pessoas.
Objetivo da implantação do processo: vejo que muitos
processos são criados somente para manter um selo ou para atingir alguma
certificação ou ainda, para mostrar que existem diversos artefatos, que,
teoricamente garantem qualidade, mas no final, artefatos que ficam em quadros
bonitos na parede sem a mínima conexão com a realidade. Nestes casos o
principal é esquecido, software de qualidade e aderente as expectativas do
cliente e como conseqüência, processos inchados e não alinhados a realidade.
Conhecer a forma de trabalho: geralmente um processo de software
é implantado para resolver algum problema, índice de bugs muito alto, sistemas
que fogem totalmente do desejado, ou qualquer outro. Acredita-se que
implantando uma metodologia iterativa e incremental seja a bala de prata,
como o UP, RUP
e SCRUM. Perceba que não
estou me atendo a um processo ágil ou
mais formal. Acho fundamental antes de
implantar o processo conhecer os porquês de cada problema, é interessante
observar o dia a dia da equipe, muitas equipes são julgadas mas nem sempre é
avaliado o motivo de nada dar certo. Pessoas estão sobrecarregadas? Pessoas
exercem papéis que não condizem com sua habilidade?É um problema de gestão? Tudo
isto precisa ser avaliado com cautela. Após entender, temos que escolher a
melhor metodologia ou conjunto de metodologias procurando o que se adere melhor
as necessidades e cultura da empresa, é utopia mudar a forma que algumas
pessoas trabalham, principalmente quando o software não é produto principal. Refinamentos
e customizações do processo são necessários para que ele se torne enxuto e
eficaz. Para mim, um processo enxuto é aquele onde as atividades são seguidas e
artefatos úteis gerados. Já vi casos de artefatos que são gerados apenas para
cumprir a metodologia, isto representa dinheiro jogado fora. Cuidado para isto não
acontecer....
Envolver pessoas: Não envolver pessoas na minha opinião é o
maior erro. Montamos um processo, correto? Quem executa? Pessoas. Você gosta de
fazer algo que lhe foi imposto sem ao menos consultá-lo ou interá-lo do que
será feito? Eu não gosto. Quando for definir um processo, consulte as pessoas,
mostre o que será feito, tome opiniões, entenda as angustias e expectativas,
mostre os benefícios, conheça os funcionários que você tem na equipe, empresas
cometem um erro grande, “Santo de casa não faz milagre”, geralmente as idéias
de como resolver os problemas estão dentro da própria equipe. Hoje estou do
outro lado das linhas inimigas 
,
ou seja, ao invés de definir, estou dentro do processo e dou um parabéns para a
equipe que está definindo o processo onde trabalho. Constantemente estamos em
comunicação para fechar as práticas que sejam úteis e eficientes, a comunicação
flui de forma bidirecional, consigo ver que as idéias da minha equipe foram
absorvidas, isto trás estímulos e a idéia é comprada. Se os amigos permitirem,
coloco o nome deles aqui, são profissionais competentes. Uma vez disse e continuo
a repetir, só acho alguém bom quando vejo os resultados(isto vale para mim),
teoria é ótima, mas como o meu amigo Giggiome
disse uma vez, “os livros levam apenas até a metade” e neste ponto não tenho do que reclamar,
resultados estão aparecendo.
Neste post estou apenas colocando meu ponto de vista sobre minhas
experiências e troca de idéias com outros profissionais. A ciência
de desenvolver software não é fácil, e comparado com outras ciências, ainda
estamos engatinhando, resumindo, não há uma fórmula mágica. A excelência apenas
é adquirida através de provas e experimentações. Não devemos ser reticentes e achincalhar
um ou outro processo de software, cada um resolve um tipo de problema. O melhor
é entendê-los bem e utilizá-los de forma adequada. Tenha a mente aberta, veja
novos paradigmas, realize experimentações, busque outras opiniões e dê oportunidade a talentos.
Até a próxima
Centralizar configuração de clientes WCF
No projeto que estou trabalhando, tenho um componente que será utilizando por diversos clientes e irá realizar a chamada a um serviço WCF. Como sabemos há duas formas de criar um cliente WCF, via código, criando um ChannelFactory onde informamos o famoso trio ABC(Address/Binding/Contract), ou através do utilitário svcutil.exe(Este utilitário também é chamado quando utilizamos o Add Service Reference no Visual Studio) , que cria um Proxy e inclui no arquivo de configuração diversos nodes com as configurações obtidas no serviço. Aí o problema, não gostaríamos que cada cliente fosse obrigado a incluir em seu .config as configurações de nosso framework e caso o endereço do endpoint fosse alterado, teríamos problemas sérios para atualizar todos os clientes(e são muitos). Procurando meios de centralizar o arquivo de configuração do serviço WCF, um integrante da equipe, o Fabio Gouw, encontrou uma classe utilitária no blog do MVP Pablo M. Cibraro. Ele a criou para fazer justamente o que queríamos, basicamente você cria um ChannelFactory através de um classe que o autor criou, esta classe herda de ChannelFactory e ao instanciá-la você informa o contrato e o caminho do arquivo de configuração. Na seqüência você cria o canal, tudo muito simples. Há outras sobrecargas no método que cria o canal, como, por exemplo, informar o binding ou o endereço do endpoint. Vale à pena dar uma olhada nos fontes, o código é simples e totalmente adaptável.
Exemplo de utilização:
FwkClientChannelFactory<IContrato> oChannel = new FwkClientChannelFactory<IContrato>("Path do arquivo de configuração");
IContrato oWcfClient = oChannel.CreateChannel();
oWcfClient.NomeMetodo();
Para baixar a classe utilitária e seus fontes, utilize o link: (http://weblogs.asp.net/cibrax/archive/2007/10.aspx)
Até mais
Quadro de Scrum na Prática
Navegando pelo Youtube, encontrei um vídeo bacana sobre a implentação de um quadro de SCRUM. A idéia empregada pela empresa BlueSoft foi bem criativa. Confira!
Livro gratuito sobre DDD (Domain-Driven Design)
Durante a primeira reunião do
grupo de arquitetura organizada pelo Giggio,
uma sigla foi mencionada diversas vezes a DDD. Fiquei curioso e fui buscar referências
sobre o assunto. O criador do conceito é Eric Evans
e trata-se de uma abordagem interessante
e realista sobre a construção de software.O livro do autor intitulado Domain-Driven Design:
Tackling Complexity in the Heart of Software
fornecerá todo o suporte para o entendimento
do assunto. Entretanto, trata-se de um livro extenso. Para quem quiser uma
introdução rápida, a comunidade InfoQ
disponibilizou uma síntese do livro do Evans para download,
com o título sugestivo Domain-Driven Design Quickly.
O livro em pdf é gratuito e a versão impressa custa $30. Eu li e
recomendo, com certeza abrirá seu apetite para explorar e colocar em prática o
DDD.
Até a próxima!