O conceito de Design Simples para o XP está associado a quatro atributos relacionados à qualidade do software: (a) Testabilidade- À medida que o sistema é desenvolvido são criados testes de unidade e de aceitação, podendo ser executados a qualquer momento em esquema de regressão com o objetivo de detectar eventuais defeitos inseridos no software durante a evolução do produto. (b) Inteligibilidade – Está relacionada à facilidade que os membros da equipe conseguem acessar e entender trechos e rotinas de código. (c) Facilidade de compreensão- está associado à capacidade do conhecimento sobre o software ser rapidamente apreendido por novos membros da equipe. (d) Facilidade em explicar as rotinas e componentes – está associado à facilidade em demonstrar como os vários componentes que compõem o software trabalham em conjunto. Complexidade desnecessária deve ser retirada através da execução de re-fatorações de código, tantas quanto forem necessárias (WELLS, 2009).
Bourque et al (2002) ao examinar resultados de conferências sobre Engenharia de Software (IEEE, SEBOOK, ISESS) com o objetivo de elencar princípios fundamentais em SE relacionou uma lista de 65 candidatos incluindo entre eles a necessidade de minimizar as iterações entre os componentes, investir na compreensão do problema, projetar as rotinas pensando na possibilidade de reuso, associados ao conceito de Design Simples.
167
APÊNDICE B – Características de Agilidade
Neste apêndice são apresentadas as características de agilidade recuperadas a partir da execução de protocolo de quasi-revisão sistemática e posteriormente avaliadas quanta a pertinência e relevância a partir da execução de um survey (Abrantes, 2012).
Característica Descrição
Adaptabilidade Habilidade e capacidade de adaptar rapidamente o processo para atender e reagir a mudanças de última hora nos requisitos e/ou mudanças de ambiente, bem como atender e reagir a riscos ou situações não previstas.
Auto-organização As equipes definem as melhores maneiras de se trabalhar; elas são autônomas e podem se auto organizar de acordo para completar os itens de trabalho.
Convergência Atacar os riscos pro ativamente faz com que o sistema se torne mais perto da realidade procurada a cada iteração. Na medida em que esta ação progride, o sistema é entregue em incrementos. Tudo que estiver ao alcance dos
envolvidos no desenvolvimento do software é feito para garantir o sucesso de modo mais rápido.
Emergência Os processos, princípios e estruturas de trabalho são reconhecidos durante o processo de execução, não sendo definidos a priori; é permitido e aceito que tecnologias e requisitos emerjam durante o ciclo de vida do produto.
Equipes Locais Para algumas metodologias isto significa equipes localizadas nas mesmas salas ou em salas adjacentes; isto funciona para equipes de 4 a 8 pessoas. Todas as metodologias são sensíveis à localização das equipes e estão fortemente baseadas em canais de comunicação ricos e rápidos, apoiando a redução de documentação a ser elaborada e mantida.
Equipes pequenas Equipes pequenas, e pequeno número de equipes por projeto, são necessários para promover um ambiente colaborativo e requer menos planejamento para coordenar as atividades dos membros das equipes.
Incorporação de Realimentação (feedback)
As equipes devem ser capazes de receber e procurar continuamente por feedback de modo mais frequente e com mais rapidez.
Leanness Esta característica está relacionada com a eliminação de perdas e com a habilidade de realizar mais trabalho com menos esforço; é uma característica de processos ágeis que requer o mínimo necessário de atividades para mitigar riscos e alcançar metas; todas as atividades que não são necessárias devem ser removidas do processo de desenvolvimento.
Modularidade Esta característica permite que um processo seja particionado em componentes chamados de atividades, tornando viável adicioná-los ou removê-los de um processo
168 quando necessário.
Orientação a Pessoas
Privilegiar pessoas em detrimento de processos e tecnologias; desenvolvedores são fortalecidos e encorajados a aumentar sua produtividade, qualidade e desempenho; comunicação e cooperação são fundamentais e necessárias; reuniões em pé e workshops de reflexão dão às pessoas a chance de expor suas preocupações.
Reflexão e Introspecção
Acontecem reuniões no final de cada subprojeto ou iteração, nas quais cada membro da equipe pode discutir o que está sendo bem feito e o que precisa ser melhorado.
Ser Colaborativo Esta é uma atitude por parte dos membros da equipe de desenvolvimento, dentre os quais a comunicação é encorajada para disseminar informação e apoiar integração rápida de incrementos de software.
Ser Cooperativo Interação aberta e proximidade entre todos os stakeholders (especialmente entre clientes e desenvolvedores); o cliente deve ser um elemento ativo no processo de desenvolvimento e deve prover realimentação (feedback) de modo regular e frequente.
Ser Incremental Não tentar construir o sistema todo de uma só vez; o sistema deve ser particionado em incrementos (pequenas releases com novas funcionalidades) desenvolvidos em ciclos rápidos e paralelos; quando o incremento estiver completo e testado, ele é integrado ao sistema.
Ser Iterativo Usar vários ciclos curtos guiados por features do produto, nos quais certo conjunto de atividades é completado em poucas semanas; estes ciclos são repetidos muitas vezes pra refinar as entregas.
Testes Constantes Para prevenir a degradação da qualidade por causa de programas de releases curtos, um alto grau de ênfase é colocado no teste do produto ao longo de seu ciclo de vida; testes de integração devem ser automatizados com builds diárias bem como a execução de testes de regressão para garantir que todas as funcionalidades operem adequadamente.
Time Boxing É o estabelecimento de limite ou fatias de tempo para cada iteração programada. Grandes esforços de desenvolvimento são divididos em múltiplas entregas desenvolvidas de modo incremental e concorrente, de maneira previsível.
Transparência O método ou processo ágil deve ser fácil de aprender e de ser modificado, além de estar adequadamente documentado.
169
APÊNDICE C – Atividades do Processo de
Teste Padrão
Neste apêndice são relacionadas as atividades que constituem o processo proposto por Dias e que será utilizado como processo de teste de padrão no estudo proposto (Dias Neto, 2006).