Indicação para destaques do ano 2015 | Agile Testers
Topic created · 4 Posts · 2601 Visualizações
Se a gente observar as empresas que obtém o melhor resultado hoje, os papéis normalmente são:
Dentro de Software Engineer existem algumas subcategorias mais específicas: Frontend Engineer, Backend Engineer, Software Engineer (dev) e Test Engineer. Uma equipe ágil consegue superar o gap entre área de negócios e TI, tendo o reconhecimento de quais recursos disponíveis serão precisos. Estima-se que somente nos Estados Unidos, projetos de software problemáticos desperdiçam entre 60-70 bilhões de dólares por ano. Falar sobre a estrutura de engenharia, gestão Ágil, metodologias de fluxo de trabalho no desenvolvimento de software e mergulhar em detalhes no que as equipes fazem em base no dia-a-dia tornou-se algo imperativo.
Até mesmo equipes pequenas precisam ter um Test Engineer, a análise de teste está dentro de um dos requisitos e tarefas do Test Engineer, esse especialista irá criar estratégias que serão utilizadas no produto em desenvolvimento, investigação do software, utilizar os atributos qualitativos de funcionalidade, construir e verificar a acurácia dos testes, entre outras funções das quais ajudarão a evitar uma erosão arquitetural. Um time ágil acaba automaticamente melhorando a comunicação (reduzindo o volume) e o desempenho da equipe, realiza uma sessão "feedback" de opiniões uma vez por semana, usa painéis informativos (Jira e Trello), tudo é explicado e podem usar essas informações para elaborar workshops.
Cada um desses profissionais não só conhece sua área de trabalho mas conhecem cada processo, em algumas partes estão mais informados e outras nem tanto, como um time de futebol, todos sabem fazer gol, mas o volante é especialista em cercar e jamais deixar o adversário passar, mas nada o impede de agir como atacante e fazer gol, o zagueiro é especialista em marcar os atacantes, mas pode ter conhecimento em ser um volante e um pouco como atacante. Todos sabem fazer gol, mas cada um é especializado em determinadas funções.
Nesta representação figurativa, vemos o exemplo do Test Engineer, ele conhece todo o processo, sabe bastante de requisitos, implementação e implantação, é expert em teste e analise e pouco conhecimento em projeto e manutenção. Mas o Software Engineer é expert em outros pontos, como os demais colaboradores da equipe, para que todos possam compartilhar conhecimento e colocar os projetos em outro patamar.
As informações das equipes ágeis tornam-se universalmente acessível e útil para todos na empresa e suas subsidiárias, criando o melhor software para clientes e com datas corretas de entrega, mas como? Existe um timeline para que isso ocorra: Ideas – Features – Planned – Worked on – In code review – tested – Canary – Live. A ideia todos participam (kick-off), em feature request testes unitários são importantes porque deixam o projeto consistente, os testes serão sempre uma constante e relatando tudo o que ocorreu. O ciclo de teste de software deve ter seu início nas entrevistas e planejamento das atividades do projeto do cliente, usar uma matriz GUT no início do projeto pode evitar uma série de dores de cabeça e de contingência. O canary (beta) e versão estável para não ocorrerem problemas nos testes, deve existir está separação para controlar melhor a qualidade do produto e reduzir os níveis de retrabalho no futuro.
O planejamento é uma atividade estratégica que interfere nos planos tático e operacional de um projeto. Planejar uma atividade é antever os passos necessários para concretizá-la e garantir o controle de suas variáveis, como: tempo, prazo e custos. Ela também auxilia no levantamento de recursos e ferramentas necessários à realização da atividade. Acabando com o mal da procrastinação.
O desempenho será maximizado, o desperdício acaba reduzindo (mais investimento por causa das falhas), as pessoas tornam-se mais efetivas, responde a mudanças facilmente (mais que seguir um plano), release antecipada para obter feedback do cliente, auto-organização e frequentes introspecção e adaptação do processo de desenvolvimento.
Alguns dos flavours do Ágil
Extreme Programming: metodologia de desenvolvimento de software ágil, frequentes releases, curto ciclos de desenvolvimento, programação em pares, sensível às mudanças nos requisitos dos clientes.
Scrum: metodologia de gerenciamento de projeto ágil, pode ser usado com o sem a metodologia de desenvolvimento de software ágil.
Kanban: sistema japonês para controle de inventário e logística JIT, writeboard, cards.
No final o foco no cliente irá fazer todos seguirem essa ideia porque o processo não será exaustivo. É melhor fazer uma coisa muito, muito bem, do que várias com retrabalho e através da continua iteração sobre problemas difíceis, seremos capazes de resolver questões complexas e proporcionar melhorias contínuas.
- Atua como Analista de Testes voltadas aos Projetos Openstack, RFID e Recycling.
- Escritor contratado pela editora Tate Publishing, USA
http://www.devoxx.com/display/FR12/Behind+the+Scenes+of+Day-To-Day+Software+Development+at+Google
Quando se fala em Kanban dentro de Agile, não estamos falando do sistema japonês de cartões, e sim do método Kanban, criado pelo David Anderson (http://www.amazon.com.br/Kanban-English-David-J-Anderson-ebook/dp/B0057H2M70/ref=sr_1_1?ie=UTF8&qid=1446036163&sr=8-1&keywords=kanban).
No próprio livro, o David escreve a palavra Kanban de duas formas diferentes, pra facilitar o entendimento:
kanban (com K minúsculo) -> sistema japonês (TPS - Toyota Production System) de cartões
Kanban (com K maiúsculo) -> método Kanban, inspirado no TPS.
O ponto forte do Kanban é se adaptar com qualquer processo de desenvolvimento de software, diferente do Scrum, por exemplo.