seufagner

Estou tremendamente fatigado. O fato de ter que fazer, todos os dias, coisas que não gosto e, de certo modo, tenho repugnância, desgasta e não tem dinheiro que pague.

Além dos processos engessados, contemplo também as mais diversas espécies de profissionais: O empurrador de papéis, o pendate, o escondido, o infeliz, as múmias..

O empurrador de papéis recebe documentos ou requisitos formais e dispara para a equipe competente. Teoricamente ele deveria ler e repassar a informação que obteve junto aos clientes, porém a única frase é: É para fazer o que tem no papel. Se surgir alguma dúvida não tem conversa, literalmente: “Escreva um documento requisitando um reunião para discutir o documento, este que vai gerar outros documentos (os requisitos que serão devidamente homologados através de mais um documento). Se recebermos um requisito falho, o ciclo se repete. Este time, pasmem, é formado pelos antigos secretários(as)  e como já tinham muito tempo de casa, para não ser demitidos, foram alocados neste “novo” setor.

O pedante é aquele cara que lê essas revistas que ensinam a usar um framework, acha “bonito” e, sem nenhuma avaliação elaborada, empurra goela a baixo nos pobres desinformados. Este é o melhor caso. O pior é quando as pessoas da alta gerência enfim notam que as coisas não funcionam e pedem a uma consultoria para rever os processos, tecnologia utilizada, etc. Esta que, através de suas parcerias, empurram produtos desnecessários, sustentados, mais uma vez, pela falta de conhecimento das pessoas que assinam o cheque.

O escondido é aquele terceirizado que não faz absolutamente nada, fica caladinho ali na sua “baia” só esperando para ir embora. Eu conheci, digo, achei um recentemente. Ele falou que estava ganhando o dele sem fazer nada, “e isto é ótimo, não quero mais nada da minha vida”.

Ninguém quer mudar nada, ninguém quer assumir o “risco” da mudança
- “É melhor continuar como está, não dá problema”
Ninguém quer resolver nada, pois o salário está garantido.
Ninguém quer trabalhar “mais”, “eu não sou benevolente”

Ah, o infeliz sou eu, claro.

É, acabei de completar uma semana no meu novo emprego, que na verdade é um grande desafio.

A minha equipe é formada por seis pessoas, eu acho. Quatro líderes de projetos e duas analistas de negócios. Somos responsáveis por todos os projetos de uma grande seguradora, talvez a maior do Brasil. Levantamos requisitos junto ao cliente, aprovamos o que foi desenvolvido pela fábrica e, ainda, somos os primeiros responsáveis pela qualidade do que vai para produção (há uma outra equipe só pra isso).

Saindo de um âmbito mais ágil, que era o da Globo.com, me deparo com um exemplo perfeito da ineficiência do modelo waterfall. Muita documentação desnecessária, muita burocracia para resolver problemas, aparentemente, simples. O que acontece na prática? Todos sempre conseguem um jeito de burlar tal burocracia, quando existe algo mais urgente, “para ontem”, a ser resolvido. O ambiente chamado de homologação praticamente não é usado, ninguém tem a ousadia de assumir toda aquela papelada e, por fim, resolve-se o problema no ambiente de desenvolvimento que, graças a Deus, é um espelho fiel de produção.

As pessoas tem medo de mudanças, ponto. O modelo do sistema, em si, é totalmente engessado e esse papo de Domain Model e Ubiquitous Language não existe. Como o número de papéis que nós, líderes, assumimos é grande, a maioria não tem uma grande experiência com arquitetura, modelagem ou coisas do tipo. Então fica aquele “bacalhau”, a cada nova feature que é requisitada à fábrica vem uma coisa diferente (e nem pense em suíte de testes, leva muito tempo blábláblá..). E como faz? O que poderia ser apenas um novo nível de pacotes, torna-se um novo novo projeto, no CVS e o caralho, que utiliza um core em comum lá. Existe um documento de teste, uma fase de teste, o meu teste, o teste do desenvolvedor e o teste do teste do teste. Hã?

Há grande ávidez por melhorias e eu já estou dando meus pitacos, sutilmente. Primeiramente vou entender todo o domínio, o vocabulário utlizado, os ambientes e como tudo lá funciona para, seguramente, tentar influir na melhoria. A princípio eu já falei muito sobre testes (vários tipo), integração contínua e outras coisas que são praxe na Globo.com, por exemplo, e tudo foi muito bem recebido (embora exista uma equipe de arquitetura que demora, sabidamente, 3 meses para dizer se é viável ou não, e você não pode relutar (lembra do medo de mudanças que citei? Imagina o resultado então..).

Apesar disso tudo, no que concerne ao meu real papel, que é a captura de requisitos e certo gerenciamento de projetos, toda essa experiência será muito valiosa profissionalmente e estou certo que aprenderei e acrescentarei muito valor aos projetos que venha a participar (já sei que, inicialmente, terei dois nas minhas mãos).

Dificilmente abordo temas específicos sobre alguma tecnologia, porém achei este importante pois muitas vezes, em projetos menores com equipes inexperientes, ele é ignorado. Entender os benefícios que a especificação do EJB 3 trouxe facilitará muito sua vida. Então, vamos lá…

Primeiro, é bom ressaltar que deve-se tomar cuidado ao tratar exceções durante chamadas remotas. Por exemplo: Não faz sentido tentar repassar uma exceção que o cliente não conhece, não sabe “o que é”. Exceções que não serão tratadas por outrém não fazem sentido serem, por fim, repassadas.

Para cuidar de coisas como esta, existem dois tipos de exceção no EJB 3:

ApplicationException

Primeiro ponto: Lembre-se que elas são recuperáveis, ponto. Porém, isto não quer dizer que elas são, apenas, unchecked. Não. Elas também podem estender Exception, sem problemas.
Para isto você deve marcar sua exceção como recuperável com a anotação javax.ejb.ApplicationException

@Target(TYPE) @Retention(RUNTIME)

public @interface ApplicationException {

boolean rollback() default false;

}

Esta anotação tem apenas o atributo, que não é requerido, chamado rollback, que indica se a transação onde a exceção foi lançada será marcada com.. rollback. Isto deve ser utilizado principalmente quando você deseja, de qualquer forma, garantir a integridade dos seus dados.

Obs: Caso não queira generalizar, marcando uma exceção com rollback=true, você terá que capturar a exceção e marcá-la manualmente para rollback, com o método setRollbackOnly() da interface javax.ejb.EJBContext (apenas em BMT - Bean Management Transaction)

System Exception

A anotação…. não. Não existe a anotação @SystemException. Este tipo é um conceito e significa que são exceções tratadas pelo Container, estas indicam erros irrecuperáveis dentro de uma chamada remota, onde o Container, que sempre empacota a real exceção lançada pelo Bean como uma javax.ejb.EJBException, torna o que aconteceu transparente para o cliente.
Outra característica marcante é que ele sempre marca a transação onde esta foi lançada para rollback. Caso você tente comitar, uma exceção será lançada e sua transação não terá sucesso.

Obs: Para exceções lançadas por um subsistema remoto, como um Web Service, a exceção será empacotada pelo Container como java.rmi.RemoteException.

Casos de uso, quase sempre associados ao RUP, são uma descrição generalizada de uma interação entre o sistema e um ator, onde este último é um usuário ou outro sistema. Geralmente o modelo proposto pelo Alistair Cockburn é o mais usado.

Uma das difirenças mais óbvias entre estórias e casos de uso é seu escopo. Um caso de uso é sempre maior que uma estória, chegando a descrever detalhes sobre a interface com o usuário. Estórias são semelhantes ao “Main Success Scenario” dos casos de uso, mas não necessariamente iguais (podem descrever casos secundários de sucessso). Em compensação, nestas, um nível maior de detalhamento é alcançado através de conversas com o cliente, o que se mostra muito mais profícuo que concepções individuais de um analista.

Uma das mais importantes diferença é o tempo de vida. Casos de uso são artefatos estáticos, permanentes, que continuam existindo ao longo da vida do produto. Estórias, por outro lado, são transientes, não teêm vida após a iteração terminar, pois eles são adicionados ao software em forma de testes de aceitação automatizados (caso ideal).

É notável, portanto, que cada um é escrito para diferente propósitos: Casos de uso se propõem a serem documentos de aceitação entre o cliente e o time de desenvolvimento. Estórias, por outro lado, são escritas para facilitar o release plain, e servem, também, como lembretes ou mesmo placeholders para conversas entre os envolvidos.

User stories são, basicamente produtos (escritos) de conversações entre o time e o cliente, direta ou indiretamente. Juntos eles definem e entram em um acordo sobre o que realmente deve ser implementado, através já de um teste de aceitação (geralmente).

Mas o que são os 3C?
O Ron Jeffries levantou uma tese de que user stories devem seguir três aspectos (eles adoram isso):

Card é a estória em si, escrita, detalhada e refinada, fruto de Conversations entre as partes envolvidas até que o cliente dê o Ok, o Confirmation da feature.

É apenas uma contextualização com trocadilhos para, por fim, descrever uma prática que soa como óbvia, mas que incita e guia equipes inexperientes pelo caminho certo ao concebê-las.