Postagens

Mostrando postagens de Fevereiro, 2017

Afinal, o que é qualidade?

Esse blog é sobre qualidade, mas sabe de uma coisa? Não conceituamos qualidade até agora. Bem, há diversas definições, de vários autores diferentes, e a que mais gosto é:

"Qualidade é a conformidade do produto às suas especificações" - Philip Bayard Crosby.
Adaptando para nosso contexto, qualidade é a conformidade com os requisitos. Então, para atingi-la, eu preciso compreender profundamente a necessidade do cliente, para a atendê-lo plenamente.
No entanto, esse é apenas um ponto de vista do conceito. Nesse caso, o produto final tem qualidade, o que já é uma grande coisa. Porém, a que custo chegamos a esse ponto, do estado da arte no atendimento aos requisitos? Então cabe uma reflexão, que é a respeito de como fazemos. Ora, o produto é o que vamos entregar. O modo de fazer diz muito também sobre a qualidade. Será que o cliente estaria disposto a pagar qualquer valor para obter um produto de alta qualidade? E o tempo? O fato de entregar com qualidade nos permite gastar quanto …

Cada tarefa deve ter um e somente um dono

Esse blog já introduziu o conceito de processos. Hoje quero dar ênfase na importância de cada tarefa de um processo ter um dono. E somente um.

Vou aproveitar o post anterior, em que são mencionadas as práticas arquiteturais e sobre o papel do arquiteto. É possível dizer que a arquitetura, no contexto da engenharia de software, é um processo. Neste, são recebidos os requisitos, que são analisados e discutidos, de forma a criar ou transformar a proposta arquitetural para o software. Como produtos de trabalho, podemos ter um documento de arquitetura e/ou modelos diversos, sugestões de aplicações de patterns, algum código de referência ou scaffolds (códigos comuns, baseados em modelos para resolver problemas simples e recorrentes), entre outros.

Dado que a arquitetura pode ser vista como um processo, a mesma é dividida em tarefas. Cada tarefa é de responsabilidade de uma única pessoa. Por que isso? Ora, se ninguém responder para uma tarefa, a mesma simplesmente não sai. É despriorizada ou…

Arquitetura de software e o papel do arquiteto

Quando falamos em grupos a respeito engenharia de software, acabamos nos deparando com experiências bem diversificadas, tanto de sucesso quanto de grandes falhas. Dentre esse indivíduos, há várias posturas sobre o assunto arquitetura e o papel do arquiteto, os quais podemos citar aqueles que:desconhecem e/ou ignoram o papel do arquiteto ou as práticas arquiteturaisconhecem, mas não percebem valor em ter um arquiteto no timeconseguem ver valor, mas não compreendam plenamente o seu escopo de atuaçãoadotam as práticas de arquitetura e valorizam o papel do arquiteto na medida certa Para fugir um pouco dos conceitos acadêmicos, vou falar como entendo a arquitetura: 
Trata-se de um conjunto de atividades e práticas, com o objetivo de descrever o domínio da solução, com base numa visão geral do domínio do problema e uma boa compreensão dos requisitos, de modo a viabilizar a entrega do software com qualidade, atendendo à expectativa do cliente.
O arquiteto de software, por sua vez, é o profiss…

Testes de comportamento

No último post, comentei sobre a importância da boa comunicação para a correta interpretação dos requisitos. Também escrevi sobre o gap de comunicação. Para continuar nessa linha, gostaria de introduzir um assunto que vai auxiliar bastante no processo de elicitação dos requisitos e, de brinde, vai gerar um ativo importante na automação dos testes. Trata-se do emprego das ferramentas de testes de comportamento.

Quando algum stakeholder solicita algo para o sistema, o faz num linguajar próprio, não técnico, muitas vezes vago ou ambíguo. Dizemos que se trata de uma necessidade. Esta não é passível de teste, por ser subjetiva. Então, precisamos transformar uma necessidade em um requisito. Este, por sua vez, é objetivo, claro e passível de verificação. Uma necessidade pode ser evoluída para um ou mais requisitos, que podem ser funcionais ou não funcionais.

As ferramentas de testes de comportamento permitem registrar os textos dos requisitos de uma maneira mais formal, mas de uma forma simp…

Dica de comunicação

Hoje resolvi falar sobre comunicação. Há inúmeras estatísticas que citam a comunicação como uma das principais vilãs nos fracassos de projetos diversos, inclusive os de engenharia de software.
É evidente que comunicação é um tema amplo e, por isso, vou focar num ponto, que vou chamar de gap de comunicação.

O gap de comunicação, nesse contexto, é a diferença entre o que o emissor da mensagem quis dizer e o que o receptor efetivamente entendeu.

Imagine a fase de elicitação (levantamento) de requisitos. Independente do processo adotado ou técnica empregada, todo software precisa partir de requisitos (ou histórias de usuário, ou use cases, ou o que quer que seja). Cada stakeholder (envolvido ou afetado) que participar dessa etapa irá se comunicar com o time técnico e poderão acontecer várias coisas, a saber:

A pessoa pode pensar alguma coisa, mas ter dificuldade de se expressar e comunicar algo diferente;Haver um pensamento complexo, mas transmitir uma explicação simplista, insuficiente;Se…

Software profissional tem teste, incondicionalmente

Já se foi o tempo em que um desenvolvedor só programava. E esse tempo não deixou muita saudade. O fato é que é impossível, hoje, desvincular da atividade de desenvolvimento, a etapa de construção dos testes automatizados. Afinal, como eu sei se eu terminei de codificar, que meu objetivo foi atingido? Os teste ajudam a saber isso. E muito mais!

É muito comum adotar a prática conhecida por TDD, brilhantemente descrita pelo ilustre Kent Beck. Segundo essa proposta de abordagem, primeiro é pensado no teste, para depois fazer o código propriamente dito. Não é meu objetivo explicar TDD aqui, pelo menos não nesse post. Recomendo fortemente a técnica. Se não conhece, vá atrás. Agora.

Os testes ajudam a definir o critério de pronto (done), indicando que o código está apto a ser entregue. Além disso, a bateria de testes roda de forma automática, a um custo muito baixo. Isso ajuda a evitar o que é conhecido como regressão do software. Em um cenário em que a cobertura de testes está boa, se há al…

Documentação de processos - por onde eu começo?

Que tal discutir um pouco sobre como documentar os processos? Em primeiro lugar, para documentar, o processo já deve ter sido discutido com o time, os especialistas, os consultores (se aplicável), enfim, todos os envolvidos. É comum ter um esboço de um fluxo que representa o processo. Particularmente, gosto do diagrama de atividades UML para isso, que é simples, permite representar desvios, paralelismo e atende bem. Mas o mais importante é escolher alguma forma de diagrama que o time compreenda. Se for um padrão de mercado, ótimo. No entanto, é essencial que as pessoas que precisem entender do processo saibam compreender perfeitamente o desenho.

Critérios para escolher uma ferramenta:

Facilidade de uso, inclusive de dar manutenção no que já foi gerado - essa particularidade é especialmente importante, já que o processo é vivo e sempre, sempre evoluiCusto Qualidade da exportação do conteúdo - eu prefiro as que exportam em HTML e eu possa gerar um portal, acessível a todosPossibilidade d…

Processos formais na sua empresa - primeiros passos

Olá pessoal! Hoje eu gostaria de falar um pouco sobre o pilar de processos e citar uma ferramenta. Já sabemos que as pessoas formam a peça mais importante para a produção de software com sucesso. Mas os processos ajudam muito em pontos como previsibilidade, produtividade e padronização, enquanto que as ferramentas agilizam e conferem maior precisão.

Não vou explorar um processo específico hoje, mas o conceito, de uma forma mais geral. Em primeiro lugar, o que é e para que serve um processo? Bem, processo está relacionado a algum tipo de transformação: há entrada, processamento, saída. Os processos são registrados para formalizar e garantir que as boas práticas sejam empregadas. A inteligência corporativa acumulada tende a ser incorporada nos processos, fazendo com o que foi feito de bom seja repetido, enquanto o que não agregava, ou gerava desperdício, fosse descontinuado.

Muita gente associa processo a burocracia. Não gosto muito de polemizar, mas vou ter que dizer que essas pessoas …

Brilho nos olhos

No último post, eu sugeri que há uma relação entre a qualidade do software e o alinhamento dos colaboradores em relação aos valores da empresa.

Só para contextualizar quem começou por esse post e pulou o último:

O funcionário que concorda com os valores da empresa e acredita neles vai trabalhar mais motivado/feliz/interessado/engajado que outro colega que não está tão sintonizado assim nesses mesmos valores.
As pessoas formam o principal pilar para o sucesso, seguidas pelos processos e ferramentas, necessariamente nessa ordem.
Ora, isso não é garantia da qualidade, certo? Trata-se apenas de uma condição mais favorável para conseguir o nível de qualidade esperado.

Bem, quero continuar nessa linha e mencionar que a questão motivacional influencia brutalmente nos resultados. No entanto, motivação não vem apenas de um alinhamento com a missão, a visão e os valores. Há outros fatores que aumentam o engajamento da pessoa e potencializa seus resultados.

O principal deles é o que muitos chamam …

Um breve olhar do que já foi escrito

Já faz algum tempo, eu tive a oportunidade de escrever um artigo relacionado à proposta desse blog, cujo objetivo é discutir como melhorar a qualidade do software produzido pela nossa comunidade. O texto, de título Definição de papéis no processo de Engenharia de Software, foi publicado na Engenharia de Software Magazine, edição 53. O conteúdo, disponível para assinantes MVP, pode ser encontrado nesse link.

Bem, gostaria de enfatizar que ainda acredito nos três pilares, citados em ordem decrescente de importância: as pessoas, os processos e as ferramentas.

Sim, as pessoas são os elementos mais importantes do sucesso de sua empreitada no mundo do software. E hoje decidi falar um pouco sobre como essas pessoas se tornam a peça chave do sucesso, começando por como trazer um talento para time. Aqui tem uma tonelada de clichês e, inevitavelmente, vou acabar citando um ou outro, nesse ou em algum post futuro, quando complementar o assunto.

Espero que minha primeira dica não seja tão batida:…

Sobre esse blog

Sobre o blog Olá pessoal! Sejam todos bem vindos!

Meu nome é Murilo Saggion Beriam e esse é o meu blog sobre qualidade de software.

O foco aqui é abordar boas práticas no desenvolvimento de software, de modo a construir um produto ou serviço de qualidade. Isso inclui a discussão de todos os aspectos envolvidos, com destaque para pessoas, processos e ferramentas, que eu considero os três grandes pilares para o sucesso.

É importante comentar que a abordagem empregada tem apelo mais prático, embora eu acredite que o conteúdo aqui discutido possa ser usado também em contextos acadêmicos e de cunho científico.

Seu comentário é bem vindo para contribuir, desenvolver e, claro, corrigir.


Sobre mim Bacharel em ciência da computação pela UFSCar, especialista em TI aplicada à gestão estratégica de negócios pela FGV, na área de desenvolvimento de software desde 1999.

Arquiteto de software, atualmente com ênfase em solução em nuvem para gestão de RH.

Mais de oito anos de experiência como professo…