Acessando o Internet Banking do BB no Ubuntu 9.10

Olá pessoal,

Apesar deste blog não ter o foco em Linux, gostaria de compartilhar a solução de um problema que tive, para aqueles que como eu utilizam o Linux.

Comprei um novo notebook e coloquei Ubuntu 9.10, e toda vez que tentava acessar meu Internet Banking do Banco do Brasil, dava erro. Vamos a solução:

Abri o terminal e digitei os comandos:

sudo apt-get update

e depois:

sudo apt-get -y install sun-java6-bin sun-java6-fonts sun-java6-jre sun-java6-plugin

e depois:

sudo aptitude purge icedtea

Depois destes 3 comandos eu inicializei meu browser... e FUNCIONOU!! uhuuu...

Bom dia a todos!! Em breve retorno com mais novidades.

Reflexão: É possível integrar metodologias adaptativas com metodologias prescritivas?

Finalmente depois de muitos dias sem postar, eu voltei. =D E desta vez resolvi utilizar do blog para elaborar uma reflexão da qual tenho tido nos últimos dias: É possível integrar duas metodologias de desenvolvimento de software, sendo que uma delas é adaptativa e outra prescritiva?

Nestes dois últimos dias participei do VI Seminário em Gerenciamento de Projetos de Goiás realizado pelo PMI-GO, que inclusive agregou muito conhecimento e foi muito interessante. Neste evento, tive a oportunidade de participar de duas palestras, uma que o palestrante acreditava ser possível integrar processos adaptativos com os prescritivos e outro que o palestrante não concordava com tal integração.

O palestrante que não acreditava em tal integração justificou sua opinião baseando no conceito que os processos prescritivos são aqueles dos quais devem ser planejados no início do projeto tudo o que deve ser feito durante o projeto e deve-se registrar todas as informações pertinentes do projeto e do produto em construção. Por outro lado os processos adaptativos como o próprio nome sugere são aqueles dos quais se adaptam às mudanças, isto é, o planejamento geral é feito bem em alto nível e, em cada iteração, há um planejamento mais específico.

Estudando mais a fundo sobre estes tipos de processos/metodologias e conversando com outros colegas cheguei a uma teoria: É possível integrar o melhor dos dois mundos, ou seja, creio que apesar de tais tipos de processos parecerem tão distintos, teoricamente, é possível e as vezes até desejável integrar boas práticas de um processo adaptativo com boas práticas de um processo prescritivo.

Segundo a experiência que adquiri durante os anos de trabalho com definição de processo numa instituição pública percebi que nenhum processo que seguiu-se à risca garantiu sucesso absoluto ao final. Pelo contrário, a experiência nos mostra que qualquer que seja o processo escolhido para ser implantado deverá ser ajustado (adaptado) ao cenário do ambiente em questão. Portanto ouso dizer que não existe processo/metodologia melhor que outro, existe sim os cenários certos para cada processo, e ainda, há cenários em que os processos deverão ser adaptados e modificados para atender as necessidades particulares de cada ambiente.

Pra finalizar, ressalto que tal conclusão é apenas de ordem expeculativa, pois não apliquei efetivamente tal integração na prática. Tudo isso se resume a resultados racionais de estudos e pesquisas a respeito deste tipos de processos.

=D

Curso de Scrum

Olá pessoal,

Sábado passado aconteceu no Castello Hall o curso de Scrum, ministrado pelo Rodrigo Yoshima, da Aspercom.

O curso foi muito bom, esclareceu muitas das minhas dúvidas, além de ter agregado conhecimento. Tenho muitoooo o que compartilhar com todos sobre tudo que aprendi ali.

O próximo post, certamente, será sobre algumas questões polêmicas, levantadas no curso!

Até breve...

Lições aprendidas de uma gerência falha de projetos

Hoje quero compartilhar com vocês uma das experiências que adquiri com um projeto problema do qual gerencio.

Inicialmente este projeto de software era para ser piloto do processo padrão de desenvolvimento de software que definimos aqui. Este processo, por sua vez, foi definido com o foco em manutenção do software e na certificação do nível G do MPS.BR.

A equipe do projeto foi definida e composta por 4 pessoas: 1 gerente de projetos, 1 analista e 2 desenvolvedores. Tudo seria perfeito se não tivéssemos cometidos erros graves.

Testamos um processo com foco em manutenção num projeto que era de desenvolvimento. Além disto, o projeto em questão passou a ser piloto também de uma nova arquitetura que seria definido como padrão, isto é, o projeto passou a ter um foco correndo com os demais já estabelecidos anteriormente. A equipe por ser toda inexperiente (uns sem experiência com as regras de negocio e outros com o própria função) focou mais em preencher os templates e seguir o processo a risca do que na própria essência do projeto (extrair os requisitos do cliente, modelar uma solução viável e eficiente, etc). A equipe não era envolvida já que tudo chegava por documentos, a comunicação verbal era escassa. Enfim tivemos muitos problemas inerentes da inexperiência.

Então vamos às lições aprendidas:

1 - Nunca defina uma equipe no qual todos sejam inexperientes;

2 - Nunca deixe que os documentos de gerência (relatório de acompanhamentos semanais, atas de reunião, cronograma, ...) substitua a comunicação verbal. Pelo contrário, utilize os documentos apenas para registrar o que foi decidido pela equipe.

3 - Evolva toda equipe, para que cada um se sinta responsável por TODO o projeto;

4 - Escolha uma ferramenta de Gerência de Projetos que mais atenda as necessidades do projeto - isso ajudará em muito no controle e na visibilidade do andamento do projeto;

5 - Não se prenda a artefatos que DEVEM ser produzidos, mas sim às práticas do gerenciamento de projetos;

6 - Faça SEMPRE atas das reuniões e obtenha a aprovação de todos os participantes - não confie na sua memória e nem na dos outros - a ata te garante todas as decisões registradas e aprovadas;

7 - Nunca mude no meio do caminho a tecnologia utilizada para desenvolvimento da aplicação, sem antes avaliar os recursos disponíveis para tal mudança - e ainda que essa decisão venha "de cima" (dos chefes-mor), elabore argumentos que convence-os a mudar de idéia;

8 - Decida-se preferencialmente, para que um projeto não seja piloto para testar um novo processo aliado a ser teste de uma nova arquitetura.

Diante disso, o projeto começou a mudar de direção quando mudamos as práticas. Passamos a fazer reuniões semanais com a equipe interna para definir as tarefas da semana e resolver os impedimentos que surgiam. O resultado desta prática, foi um envolvimento maior da equipe, que passou a trabalhar em prol de todo o projeto e não apenas de resolver os problemas relacionados a sua função. Além disto, as atividades do projeto passaram a ser resolvidas em menos tempo. Começamos a utilizar o REDMINE (assunto para um outro post) para gerenciar as atividades do projeto. Foi incrível como a adoção desta ferramenta ajudou na visibilidade e organização do projeto.

Enfim, o que quero deixar para vocês são resultados de experiências, para que possamos avaliar como temos feito nosso trabalho e o que podemos melhorar.

Espero ajudar outras pessoas que se encontram em situações semelhantes.

Qual o real papel do analista?

Quero começar compartilhando um artigo de um blog que li, muito interessante.

Qual o verdadeiro papel do analista? O perfil dele deve ser de desenvolvedor como o mercado hoje exige, ou deve ser alguém totalmente independente de tecnologia e focada apenas no entendimento das regras de negócio?

Segundo Philip, o autor deste artigo, o analista deve ser focado nas regras de negócio.

"O analista deve trabalhar em conjunto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente."

"Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos."

Particularmente, eu sou de acordo com a idéia que o analista deve sim ser expert em entender a regra de negócio, ou ainda, ter perfil de negociador, isto é, alguém que sabe como fazer o cliente expor as informações chaves e  necessárias para solução do problema dele, e principalmente para convencer o cliente do que ele realmente necessita. Pois o que temos hoje são equipes que possuem desenvolvedores que não entendem do negócio e clientes que não sabem exatamente o que necessitam, resultando em sistemas que vão ao ar não contendo "exatamente o que o cliente necessita, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores".

Para uma metodologia mais ágil de gerenciamento de projetos, essa visão de analista seria muito mais eficaz, uma vez que o analista seria o facilitador para que a equipe pudesse trabalhar de forma mais objetiva e específica, atuando no problema bem definido e não na "lista interminável de desejos do cliente" que só descobre não serem necessários no final, quando já se gastou muito tempo e esforço para o seu desenvolvimento.

Portanto é preciso avaliar cada cenário e diagnosticar qual será a verdadeira função de um analista dentro de cada cenário.

Quem quiser ler o artigo do Philip, acesse: http://blog.fragmental.com.br/2008/11/23/deixa-para-os-analistas-de-verdade/ - Deixa Para os Analistas de Verdade… por Philip