Arquivos da categoria: Desenvolvimento

Teste durante ciclo de vida do software

AntesMyers_DepoisMyers

O processo de testes deve contar com uma metodologia favorável ao processo de desenvolvimento, dispor de colaboradores qualificados, ambiente e ferramentas adequadas. “A metodologia de testes deve ser o documento básico para organizar a atividade de testar aplicações no contexto da empresa.” (RIOS; MOREIRA, 2006, p. 8).

O processo de teste deve iniciar paralelamente ao processo de desenvolvimento. Podendo verificar os documentos produzidos no inicio do projeto de desenvolvimento. Ainda neste âmbito, Myers (1979, apud Bastos et al. 2007, p. 19) estabeleceu a Regra 10 de Myers, na qual defende que quanto mais tarde for encontrado um erro, tende a ser mais caro a sua correção.

Untitled-1

Referências

RIOS, Emerson; MOREIRA, Trayahú. Teste de software. 2. ed. Rio da Janeiro: Alta
Books, 2006. 232 p.
MYERS, G. J. The art of software testing. 2. ed. Hoboken: Wiley, 2004.
BASTOS, Aderson et al. Base de conhecimento em teste de software. 2. ed. São
Paulo: Martins, 2007. 264 p.

Extreme Programming

xp1

Extreme Programming (XP), idealizado por Kent Beck, é um processo de desenvolvimento de software iterativo e incremental que se encaixa na categoria de metodologias ágeis. Ele busca entregar o máximo de valor para o cliente com o uso de boas práticas. A sua aplicação é recomendada para projetos que possuem requisitos voláteis e pouco claros e para aqueles projetos desenvolvimento de maneira incremental [Teles 2004, p. 21].

A metodologia XP é baseada em 4 valores, como descreve [Teles 2004, p. 22]:

  • Feedback: Durante o andamento do projeto, o cliente aprende novas regras ou requisitos que são realimentados para a equipe de desenvolvimento. Isto permite conduzir o processo para aquilo que irá gerar mais valor.
  • Comunicação: Uma comunicação transparente e efetiva entre o cliente e o time de desenvolvimento permite uma maior eficiência na transmissão de informações.
  • Simplicidade: O desenvolvimento de software deve ser guiado apenas pelas soluções que são suficientes para atender aos desejos do cliente.
  • Coragem: Tanto o cliente quanto a equipe de desenvolvimento devem ser corajosos para aplicar as práticas e valores do XP, acreditando que isso irá trazer benefícios para o seu produto.

Para apoiar estes valores, o XP sugere a aplicação das seguintes práticas [Teles 2004, p. 23-27]:

  • Cliente presente: o cliente deve coordenar o andamento do projeto baseado nos feedbacks recebidos durante o processo de desenvolvimento.
  • Jogo de planejamento: o cliente avalia as funcionalidades a serem desenvolvidas e as prioriza para as próximas iterações ou releases.
  • Stand Up Meeting: reunião diária realizada pela equipe de desenvolvimento para avaliar o andamento da iteração.
  • Programação em Par: prática de desenvolvimento que consiste em dois programadores implementando em um mesmo computador. Isto permite que o desenvolvimento seja mais simples e eficaz, além de contribuir para a revisão de código enquanto é construído.
  • Desenvolvimento guiado pelos testes: os desenvolvedores escrevem testes para suas funcionalidades antes de codificá-las.
  • Refactoring: A equipe de desenvolvimento deve, regularmente, manter a sua base de código flexível para facilitar o refactoring (modificação do código sem alterar o seu comportamento).
  • Código coletivo: todos os desenvolvedores possuem acesso ao código do sistema, sem restrição de acesso.
  • Código padronizado: a equipe deve estabelecer um padrão de codificação e formatação de código.
  • Design simples: o desenvolvimento deve ser voltado para as soluções mais simples e enxutas para atender aos requisitos.
  • Metáfora: significa a utilização de termos de negócio usados pelo cliente, a fim de facilitar a transmissão de ideias complexas de forma simples.
  • Ritmo sustentável: o XP recomenda que a equipe de desenvolvimento trabalha oito horas por dia e evitem fazer horas-extras, visto que isso evita que a equipe perca criatividade e motivação no trabalho.
  • Integração contínua: prática que define que a equipe deve, diversas vezes ao dia, integrar e testar o código produzido com a base de código já existente. Isto permite garantir que o sistema esteja sempre funcionando de forma harmoniosa.
  • Releases curtos: o XP permite gerar um fluxo contínuo de valor para o cliente através de entregas frequentes (a cada iteração).

Estes valores e práticas fazem do XP uma metodologia simples de ser aplicada e ao mesmo tempo pode trazer grandes resultados. Porém, nas palavras de [Teles 2004, p.219], ”a maior dificuldade na venda do XP é exatamente a barreira cultural que precisa ser vencida. XP é diferente e o que é diferente costuma causar medo e ansiedade”. É necessário um grande grau de maturidade (tanto por parte do cliente quanto por parte do time de desenvolvimento) para implantar este processo e se beneficiar de seu uso.

 

Referência

Teles, V. M. (2004). Extreme Programming. Novatec.

Scrum

scrum-glossary-agile-terms

O Scrum é um modelo de processo de desenvolvimento ágil de software fundamentado nas teorias empíricas de controle do processo, ou empirismo. Sua abordagem é iterativa e incremental possibilitando assim aperfeiçoar a previsibilidade e o controle de riscos [Schwaber and Sutherland 2013, p. 4].

Segundo [Cisneiro et al. 2013, p. 4] o nome Scrum é derivado de uma jogada de rúgbi, onde todo o mesmo time avança como apenas uma unidade, trabalhando com os mesmos jogadores e em conjunto, passando sempre a bola pra um e para outro.

Conforme [Schwaber and Sutherland 2013, p. 4], três pilares sustentam qualquer implementação de controle de processos empíricos:

  • Transparência: Garante que aspectos do processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os resultados.
  • Inspeção: Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente para que variações inaceitáveis no processo possam ser detectadas.
  • Adaptação: Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.

Segundo [Schwaber and Sutherland 2013, p. 5] os papéis existentes no Scrum são:

  • ScrumMaster: é o responsável por garantir que o Time Scrum esteja aderindo aos valores do Scrum, às práticas e às regras, ajuda o Time Scrum e a organização a adotarem o Scrum.
  • Product Owner: á a única pessoa responsável pelo gerenciamento do Backlog do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa mantém o Backlog do Produto e garante que ele está visível para todos.
  • Time (equipe de desenvolvimento): Transformam o Backlog do Produto em incrementos de funcionalidades potencialmente entregáveis em cada Sprint. Times também são interdisciplinares: seus membros devem possuir todo o conhecimento necessário para criar um incremento no produto.

[Neto 2013] diz que o objetivo de se ter eventos no Scrum é proporcionar um maior controle sobre o processo adquirindo uma rotina de trabalho e aumentar a transparência ao decorrer do desenvolvimento. Os eventos Scrum são time boxed, ou seja, possuem uma duração máxima definida. Não se pode garantir o sucesso de um projeto com o uso do Scrum deixando de incluir qualquer um dos seus eventos que são:

  • Sprint: Uma Sprint consiste em um espaço de tempo de no máximo quatro semanas.Onde é desenvolvido por o Development Team um produto potencialmente utilizável. O tempo de duração de uma Sprint pode variar entre duas a quatro semanas, essa é uma decisão compartilhada por o Scrum Team. Cada Sprint deve ter um objetivo a ser alcançado pelo Development Team, resultando em um incremento do produto final.
  • Sprint Planning Meeting: O Sprint Planning Meeting é a reunião de planejamento que ocorre antes do início de uma Sprint como resultado de um trabalho colaborativo do Scrum Team.
  • Daily Scrum Meeting: é uma reunião diária geralmente de 15 minutos. O seu objetivo principal é fazer o Development Team refletir a respeito das seguintes questões: “O que foi completado desde a última reunião?”, “O que será feito até a próxima reunião” e ”quais os obstáculos que estão no caminho?”. Essa reunião assegura que o Development Team está seguindo a direção correta em relação ao objetivo da sprint.(SCHWABER, 2011, pg 10).
  • Sprint Review: acontece ao final de cada Sprint e tem como objetivo avaliar o que foi produzido pelo Development Team. É uma reunião com duração de 4 horas para Sprints de um mês.
  • Sprint Retrospective: esta é uma reunião de duração de três horas para uma Sprint de um mês. Tem como objetivo avaliar o desempenho do Development Team, criando melhorias a esse respeito para a próxima Sprint.

[Cisneiro et al. 2013, pg 8] cita que artefatos Scrum são as ferramentas básicas para se trabalhar com este modelo de desenvolvimento. Estes artefatos servem como guias e indicadores durante o processo. São divididos em três:

  • Product Backlog: o Proprietário do Produto prepara uma lista de funcionalidades desenvolvida em conjunto com o cliente, que é organizada por prioridade de entrega. Essa lista chama-se Product Backlog.
  • Sprint Backlog: assim que a equipe de Scrum escolher e definir a lista de requisitos e a prioridade de seus itens do Product Backlog, cada um desses itens agora será dividido em partes menores para o Sprint Backlog. Ou seja, uma lista especificando as necessidades para implementar uma funcionalidade do sistema.
  • Burndown Chart: é um gráfico que mostra a quantidade de trabalho cumulativo restante de um Sprint, dia por dia. Com isto, podemos visualizar facilmente se um trabalho está tendo progresso, completando as tarefas, enquanto vemos que as colunas do gráfico vão caindo em sua altura.

Estes conceitos e artefatos propostos pela metodologia de desenvolvimento Scrum se utilizadas da forma correta em projetos onde a agilidade possa ser empregada irá proporcionar a empresa a possibilidade de produzir softwares que satisfaçam os clientes, com uma boa qualidade e agilidade.

Referências

Cisneiro, H., Jacoba, M. S., and Pereira, S. M. T. (2013). Modelo de desenvolvimento ágil scrum. Disponível em: http://www.devin.com.br/modelo-scrum/. Acesso em: 06 Mai. 2013.

Neto, C. (2013). Conhecendo o scrum. Disponível em: http://www.devmedia.com.br/conhecendo-o-scrum/25744. Acesso em: 29 Abr. 2013.

Schwaber, K. and Sutherland, J. (2013). Guia do scrum, 2011. Disponível em: http: //www.scrum.org/Scrum-Guides. Acesso em 06 Mai. 2013.