Blog da QUALIDATA

Já esbarrei com vários desenvolvedores que estranharam o fato de utilizarmos aqui metodologias ágeis e ao mesmo tempo termos atividades de elicitação de requisitos, descrições de casos de uso e modelagem de domínio antes de um sprint de construção propriamente. Para eles a leveza do Agile parece pedir sempre a leveza das “User Stories” e da comunicação face-a-face preconizadas pelo eXtreme Programming. Mas nem sempre é assim.

Por que descrevemos casos de uso na Qualidata?

Bom, primeiramente não quero em nenhum momento dizer que use-case é melhor ou pior que user-story. São coisas totalmente distintas, que servem para propósitos distintos, e discutir o que é melhor só faz sentido dentro do contexto de um projeto ou uma realidade específica. A nossa realidade na Qualidata em geral é o desenvolvimento de sistemas corporativos com muitas regras de negócio, e você deve manter este contexto em mente ao ler o restante deste artigo.

Primeiramente, acreditamos realmente que “software em funcionamento mais que documentação abrangente” (do manifesto ágil) seja algo muito importante. É óbvio que no manifesto ágil, a parte da direita não é necessariamente banida, mas apenas a parte da esquerda é mais valorizada. Ainda assim esta frase do manifesto pede uma discussão muito mais fundamental, e que talvez seja a causa de muita das confusões em torno do assunto. Descrição de caso de uso é documentação? Parece óbvio que sim, mas depende do que entendemos por documentação.

Em geral quando as pessoas falam de documentação de um componente de software (e de outras coisas diferentes de software) elas estão se referindo a uma representação, textual ou não, do comportamento desse componente visando facilitar seu entendimento quando no futuro alguém precisar lidar com ele. Em outras palavras, documentação em geral é vista como uma ferramenta de comunicação e um registro para uso futuro, para facilitar a vida de quem for lidar com isso no futuro.

Considerando esta visão de documentação, não, não tratamos descrição de caso de uso como mera documentação, pois não fazemos isso pensando primariamente na comunicação e no uso futuro. Utilizá-lo na comunicação ou ter um registro para o futuro para nós é mais um eventual bônus do que um objetivo.

E aqui talvez esteja o parágrafo mais importante desse artigo. Para nós na Qualidata, descrever casos de uso é apenas mais um tipo de instrumento que utilizamos para REFLETIR, COMPREENDER e REPRESENTAR as necessidades dos usuários e as soluções de software que acreditamos serem mais adequadas. Antes de ser um instrumento de registro (documentação) ou mesmo de comunicação, é para nós, desenvolvedores, um instrumento de trabalho, um instrumento útil para o desenvolvimento de software. E nesse sentido ele não é o único. Dependendo da situação teremos análise de domínio com diagramas UML, wireframe de telas, ou o que mais for considerado realmente importante para o desenvolvimento.

Se você é um defensor do Agile (nós somos), e torceu o nariz neste último parágrafo, das duas uma: ou você não desenvolve sistemas com complexidade de negócio e de cliente que exijam grande esforço para elicitação de requisitos (o que não quer dizer que o sistema não possa ser complexo), e por isso não entendeu direito o nosso cenário, ou você atua em um contexto parecido com o nosso, mas encontrou um outro caminho dentro dos princípios Ágeis, o que é totalmente possível, e eu teria muito prazer em conhecer através dos seus comentários.

O fato é que quando estudamos mais profundamente sobre metodologias ágeis, vamos perceber que existem metodologias super leves e também metodologias inevitavelmente complexas e pesadas, se o contexto assim o exigir. Fazer um software para um equipamento hospitalar de suporte à vida é diferente de fazer um site para venda de equipamentos eletrônicos, por exemplo. Logo ser ágil não é ser super leve, mas é saber aplicar os princípios apresentados no manifesto ágil numa realidade que nem sempre admite um processo super leve.

Se você ler sobre DSDM (Dynamic Systems Development Method) ou Crystal Family Methodologies, todas metodologias ágeis, vai notar que existem muitos situações que não admitem um processo baseado em comunicação face-a-face da equipe de desenvolvedores com o “cliente” puramente.

Resumindo, por que então descrevemos casos de uso? Porque nos ajuda a entregar software de qualidade com um prazo/custo menor do que se deixássemos tudo emergir, confiando na refatoração de código, que apesar de ser totalmente viável por causa do nível de desacoplamento que adotamos, tem um custo elevado dentro do processo de desenvolvimento de sistemas grandes e complexos.

Além das descrições de casos de uso trabalhamos com outros tipos de artefatos que chamamos generalizadamente de ARCs – Artefatos de Representação do Conhecimento (evitamos propositalmente a palavra documentação) que utilizamos para construir e representar esse conhecimento que depois será mapeado em software pelos programadores, que obviamente precisarão tomar muitas decisões de construção, mas partirão de um problema discutido e mapeado previamente, consistente o suficiente para dar fluidez no planejamento da construção. Pode parecer estranho para alguns, mas no nosso contexto é natural que existam questões que levarão muitos dias ou semanas para serem respondidas, dependendo de várias reuniões com diferentes pessoas do cliente. Independente de quem irá conduzir essas reuniões, o fato é que neste caso, deixar esse problema emergir no meio da construção para então ser analisado me parece muito improdutivo.

É importante destacar que para nós descrições de casos de uso não servem para evitar comunicação face-a-face, seja com o cliente ou com analistas de negócio. Muito pelo contrário, a comunicação dos desenvolvedores com os demais envolvidos deve acontecer continuamente, tendo as descrições de caso de uso e demais ARCs sobre a mesa para permitir uma discussão mais sistemática e organizada. Mas ela precisa acontecer face-a-face. Mesmo porque os ARCs não são registros estáticos. São artefatos dinâmicos, que evoluem junto com o código e os demais artefatos. Talvez documentação seja exatamente isso, mas em geral as pessoas tendem a tratar documentação de outra forma, por isso evitamos o termo.

Se nosso argumento ainda não foi suficientemente forte, resta dizer que não estamos sozinhos nisso. Alistair Cockburn, um dos 17 desenvolvedores que redigiram o manifesto ágil, utiliza casos de uso. Aliás, “Por que eu ainda utilizo casos de uso” (http://alistair.cockburn.us/Why+I+still+use+use+cases) é um ótimo artigo para quem quer entender melhor porque user-story em nossa realidade não nos atende bem.

Também Scott Ambler, em seu livro “UML in an agile way” (p.261) defende o uso de casos de uso mas com certos cuidados: “Utilize os artefatos corretos, crie vários modelos em paralelo, e interaja com os outros artefatos quando estiver modelando. O resultado final disso é que não tentará colocar tudo em seus casos de uso, mas utilizará cada tipo de artefato naquilo em que ele é melhor” (a tradução é minha). E é exatamente nesta linha que trabalhamos nossos ARCs na Qualidata. Como diz nosso colaborador Marcelo Arrevabeni, até história em quadrinhos pode ser utilizada como ARC, se isso parecer ser o mais adequado para o projeto. Os tipos de ARC utilizados variam de projeto para projeto, pois cada realidade exige um processo de software com o peso adequado, observando sempre os princípios do manifesto ágil.

É sempre bom quando precisamos quebrar uma regra e depois vemos que não estamos só, que a mudança realmente era necessária. Há alguns anos atrás tivemos de fazer alguns ajustes nas descrições de caso de uso, criando o conceito de “sub-caso de uso” para permitir que descrevêssemos os casos de uso de forma incremental e que trabalhássemos com sprints de 2 semanas, pois um caso de uso grande não ficava pronto nesse tempo. É curioso notar que Ivar Jacobson, pai do diagrama de casos de uso da UML, e um daqueles caras que aparece em todo livro de Engenharia de Software ao lado de Rumbaugh, Booch, Ambler e outros, publicou em dez/2011 o eBook “Use-Case 2.0 – The Guide to Succeeding with Use Cases”. O principal conceito apresentado por ele nessa versão 2.0 foi, adivinhe, “use-case slice”, que nada mais é do que uma forma de dividir um caso de uso que descreve uma funcionalidade grande e complexa em partes menores, facilitando o uso de descrições de casos de uso em metodologias ágeis como o Scrum. Até a ideia de utilizar números como “7.1”, “7.2” para as partes de um caso de uso “7” foi igual ao que fizemos.

No final das contas, metodologias Ágeis podem ser nada burocráticas e até mesmo, quando necessário, muito burocráticas, pois ser ágil tem mais a ver com saber aplicar os princípios do Agile do que utilizar certo grupo específico de metodologias e técnicas.

Se você trabalha em uma realidade de sistemas/clientes parecida com a que apresentei, gostaria muito de ouvir como tem lidado com essas questões, afinal, apesar de não acreditarmos em uma forma certa, buscamos sempre formas melhores de desenvolver software.

Há alguns meses estive em minha primeira viagem de implantação de um sistema. Muitas das minhas expectativas foram concretizadas, outras não. Pensava em coisas como “pra que devemos levar o código fonte se estamos indo implantar um sistema que já está pronto?” Descobri que apesar de, num plano ideal, uma implantação ser somente instalar o sistema no servidor, dar os treinamentos e tomar suco de laranja no final do dia, o que ocorreu, na verdade, me surpreendeu. Bastante, diga-se de passagem.

1 – Checklist antes da implantação: como esse cara é importante.

Dentre as dificuldades normais de uma primeira implantação, algumas poderiam ter sido evitadas se seguíssemos à risca a checklist de testes antes de viajarmos. Tivemos que lidar com vários problemas encontrados que nos atrasaram bastante, erros pontuais que poderiam ter sido facilmente evitados. Nós tínhamos a checklist pra verificar antes da viagem, mas por não termos tempo de executá-la devido aos detalhes finais de acertos no sistema, deixamo-la de lado.

Dica 1: EXECUTE toda sua checklist antes da implantação, isso te evitará surpresas na hora do fogo cruzado, mesmo que isso custe horas extras de trabalho.

2 – Não conte com a situação ideal onde tudo está devidamente no seu lugar.

Tivemos de cara problemas com a configuração do servidor. Precisamos formatar o servidor e prepará-lo todo, inclusive instalar o windows (o que já devia ter sido feito antes de chegarmos lá). Além disso, ninguém (entenda-se aqui 98% dos funcionários de lá) colaborava com a nossa equipe na implantação. Incrível!

Dica 2 – só quem faz seu trabalho por você amigo é sua mãe quando você estava no primário. NÃO CONTE com a ajuda de terceiros, somente com sua equipe e faça seu cronograma tendo isso em mente.

3 – O teste mais fundamental do mundo.

5h de sexta-feira da semana 1. Nesse momento nós apreciamos com todas as dores do mundo o que é não seguir a checklist antes de viajar pra implantação. Quando íamos terminar o expediente felizes, sabendo que na segunda iniciaríamos os treinamentos dos funcionários no novo sistema, percebemos algo ligeiramente estranho na aplicação: ao abrir dois usuários simultâneos o sistema caía. Detalhe ridículo: o sistema é WEB. Bom, o que você faria? É. Agora ficou tenso! Não sabíamos o que fazer (então pedimos socorro! ).

Dica 3 – NÃO IGNORE nenhum teste, mesmo que seja ÓBVIO que deva funcionar. Instale e use o sistema numa máquina virtual simulando o que seria feito no ambiente real antes da viagem de implantação (:s fizemos isso depois – antes tarde do que nunca!).

4 – Levar o sistema para ser implantado não significa dizer que ele está pronto.

É estranho dizer isso, concordo. Mas é verdade. Ao iniciarmos os treinamentos fomos solicitados a fazer várias adaptações no sistema a pedido dos usuários. Mas isso não deveria ter sido feito no levantamento de requisitos? Sim, mas não foi. E aí!? Faz agora ué, ou vai dizer não a quem te pagou pra tê-lo? É claro, alterações simples que não prejudiquem o cronograma. Alterações maiores faça depois numa outra versão do sistema, lembre-se que você está numa implantação.

Dica 4: NÃO ASSUMA que está tudo pronto, por que não está. Acertos no código fonte são normais na primeira (principalmente) implantação por que é onde você está em contato direto com o trabalho do cliente e sua forma de fazê-lo. Além disso, poder contar com uma equipe em condições de realizar tais alterações ajuda muito!

Enfim, esses foram alguns pontos que quis destacar da minha primeira implantação. Valeu a experiência!

créditos da imagem: http://noticias.r7.com/blogs/julio-cardozo/tag/festa/

De uns tempos para cá, não me lembro exatamente quando, o assunto concurso público tomou conta de quase todas as rodas de conversas. E isso é notável pelos números, em 2001, quase 11 milhões de pessoas se inscreveram para concursos em todo país tentando ocupar as 650 mil vagas oferecidas no serviço público federal, estadual e municipal.

O grande aumento veio do renascimento do serviço público após quase três décadas de sucateamento e baixos salários. Assim, muitas pessoas, entre elas grande parte dos meus amigos, começaram uma corrida contra o tempo se inscrevendo em muitos concursos, estudando dia e noite, sendo que alguns deles deixaram seus empregos e começaram a viver as custas dos pais, ou das economias guardadas, para se dedicar aos estudos. Criou-se um mercado de cursinhos preparatórios, apostilas, sites com provas etc.

A pergunta que fica: o que tanto se procura? A grande maioria responderá – Estabilidade! Concordo, que em determinadas áreas a oferta de emprego está baixa. Concordo também que, em alguns setores, a diferença salarial entre ser concursado ou de iniciativa privada é muito grande e um exemplo clássico são pessoas formadas em Direito. Outro caso a se citar, vem da área de biomédicas que, dependendo da região do país, está bem saturada.

Considerando isso mas olhando de uma forma ampla, com o cuidado de não generalizar, me parece que concurso público virou “moda”, a ponto de se pensar que somente se terá sucesso na vida ao passar em um. E isso, por vezes, remete a uma visão antiga em que era necessário conhecer alguém (o famoso QI – Quem Indica) para se ter ascensão profissional (ou até se obter um emprego).

Muitas vezes, as pessoas que prestam um concurso não pensam na vaga em si, naquilo que vai se trabalhar, onde vai trabalhar, simplesmente olham o salário e o fator estabilidade. Existem diferentes realidades nas diferentes áreas de trabalho. Focando no nosso lado, a área de computação é uma das que mais cresce no país, com bons salários, possibilidades de crescimento, facilidades (com pouco investimento) para se abrir o próprio negócio. Não é perfeita mas, comparando com outros setores, estamos melhores e temos mais possibilidades de mudanças.

É admirável a quantidade de jovens pensando em estabilidade com 20 e poucos anos, e me surpreende mais ainda quando esses são formados em ótimos cursos, são bons profissionais, muitas vezes recém-formados e ainda sem família para sustentar. Não é que não se deva pensar assim, mas quando converso com pessoas de computação, concursados, a grande maioria não está trabalhando no que gosta, porém o emprego público paga um salarial inicial que ele demoraria alguns anos (não muitos, muito menos a vida toda) para conseguir. Outros começaram um ciclo vicioso, em que se faz um concurso que seja mais fácil de ser aprovado, para, ao começar a trabalhar, usar o “tempo livre” para estudar para outros concursos mais difíceis e consequentemente de salários mais altos.

E como fica a empregabilidade¹? Será que ela é tão baixa assim na nossa área? Por que tantos estão escolhendo a estabilidade ao invés dela?

Na área de computação o que mais vemos são mudanças. O mercado privado exige que você mude, muito mais rápido do que o público. Com isso, os profissionais que se dedicam acabam se destacando e crescendo na empresa, sendo reconhecido por isso. Nem tudo é perfeito, como já citei anteriormente, mas estamos bem melhores que outros setores. As startups, o “boom” da utilização de dispositivos mobile dentro outros casos, mostram como as mudanças não param de acontecer aumentando assim a necessidade de pessoas dispostas (e preparadas) a encará-las, por vezes, correndo riscos sozinhas ou dentro das próprias empresas que trabalham.

O objetivo foi levantar a discussão sobre empregabilidade e porque muitos, olhando especialmente para a área de computação, estão escolhendo a estabilidade financeira. De forma alguma estou condenando o serviço público, só acredito que, como passamos a maior parte do nosso tempo no trabalho, deve-se pensar bastante se o que você faz realmente é bom para você. Não que os empregos privados sejam perfeitos, mas será que eles não permitem uma maior maleabilidade? E entrar em um emprego para “vida toda” é realmente o melhor com a tendência de um mercado que muda tanto e tão rápido. Vale a pena pensar um pouco sobre isso.

Definição
1) Empregabilidade: termo criado no fim dos anos 90 referindo à competência de um profissional estar empregado, baseando-se na capacidade de adequação do profissional às novas necessidades e dinâmica dos novos mercados de trabalho.

O evento FastShow chegou a sua 6ª edição, a primeira no ano de 2012. Só para relembrar, esse evento é organizado como um ciclo de apresentações de 20 minutos cada, feito pelos próprios colaboradores e tratando de assuntos de interesse tanto da equipe de desenvolvimento como de outros setores da empresa.

O colaborador Adeilson Brito começou o evento com uma apresentação sobre otimização em banco de dados chamada “Analisando Consultas EF4″. A seguir, Adriano Della Valentina falou sobre Tortoise SVN, Dicas e Boas Práticas. Por fim, Henrique Netto fez um overview sobre a ferramenta Git.

Os vídeos das apresentações dessa 6ª edição do FastShow estão listados aqui, não deixe de conferir.

Para saber sobre todas as edições do evento clique aqui.

6º FastShow – Analisando Consultas EF4 from Qualidata on Vimeo.

6º FastShow – TortoiseSVN – Dicas e Boas Práticas – Parte 1 from Qualidata on Vimeo.

6º FastShow – TortoiseSVN – Dicas e Boas Práticas – Parte 2 from Qualidata on Vimeo.

6º FastShow – Git Overview from Qualidata on Vimeo.

Ao mesmo tempo em que tentamos acompanhar e utilizar novas tecnologias, metodologias ou padrões, também somos obrigados a questionar e às vezes até duvidar de tudo isso.

Mas também nos encontramos e nos identificamos no meio de todo esse “caos tecnológico”.
O problema é quando inserimos as novidades citadas no primeiro parágrafo em um novo projeto e/ou em um em andamento sem testarmos ao ponto de responder algumas questões. Como por exemplo:

Essa escolha poderá gerar atraso na entrega?
Temos especialistas nesse novo recurso a ser utilizado?

Será fácil contratar esses especialistas caso exista a necessidade de substituição de um membro na equipe?
Será possível reutilizar conhecimentos adquiridos no passado nesse novo recurso?
As questões acima ainda podem aumentar e muito, e acredito que elas podem nos dar uma ideia melhor do risco da implementação de algumas novidades.
E porque seria importante medir tudo isso?
Por que ninguém gosta de assumir para o cliente que o projeto está atrasado, isso é chato e pode dar motivo ao mesmo para pedir o que ele quiser. Pode gerar desconfiança e o pior, abalar a relação com prejuízos para ambos os lados.

Mas como resolver esse impasse? Mantemos-nos na zona de conforto e continuamos do jeito que está ,“desatualizados”, mas com nossa renda e prazos “garantidos” ou encaramos a realidade e metemos a mão no bolso e enfrentamos a barreira do novo?

Uma possível solução seria o investimento em P&D (pesquisa e desenvolvimento).
Abaixo algumas Sugestões.

Que tal tentarmos investir um valor aceitável para a empresa, como por exemplo, de 1% a 5% do faturamento de nossos projetos em P&D.

-investir em treinamento de multiplicadores do conhecimento, que seriam profissionais internos;
-participar de conferencias nacionais e internacionais de arquitetura e desenvolvimento de software;
-laboratórios de analises de novas tecnologias sendo possível até aproveitar a infra estrutura atual da empresa, sem construção de novas salas e compra de novos equipamentos.
-laboratórios de metodologias ágeis;

Os laboratórios podem ser praticados com a construção ou migração de módulos de sistemas já existentes na empresa.  Inicia-se pelos módulos mais simples até módulos mais complexos, podendo ter uma medição mais detalhada do andamento do laboratório sem o risco de um projeto oficial para um cliente X.

E nesses laboratórios poderíamos como seria a implementação de tecnologias e metodologias, poderíamos ainda, inserir pessoas em posições diferentes para podermos descobrir futuros gestores, arquitetos, analistas, etc.

Tudo parece interessante, mas quem vai pagar a conta?

Simples, o cliente e a empresa contratada, pois se a relação é no formato ganha-ganha nada mais justo que isso.

Como cobrar isso?

Uma possibilidade seria pensar em modificações no modelo de negócio, embutindo esses custos no valor final do projeto. Claro que não precisamos detalhar esse processo para o cliente. Pois o que ele quer é o software funcionando como esperado.
E nós como desenvolvedores de software o que desejamos?

Não sei quanto a vocês, mas não devemos esquecer que nosso retorno também esta na construção de componentes reutilizáveis, na construção de ativos de software e também na solidez de nossos processos seja utilizando metodologias ágeis, PMP ou o que for melhor para o nosso perfil e também para o perfil do cliente.

Até chegarmos ao ponto em que esse conjunto de soluções ganhe consistência e confiança, mas sempre ficando alerta a modificações.

Mas será que com tudo isso nossos projetos poderão se atrasar?
Sim, eles podem continuar se atrasando, mas por novos problemas, e esses problemas voltam para o laboratório para a tentativa de terem sua origem e solução encontradas.

Mas será mesmo que as novas tecnologias e metodologias vão atrasar o seu projeto? Só depende de você saber quando e onde utilizá-las.

E pra finalizar, compartilho meu pensamento.

A ausência de ação não deve ser justificada pela utopia da perfeição, e não podemos deixar a utopia da perfeição nos cegar da certeza da inexistência de uma solução.