Bitlady, by @anfindeis

Quando terminamos a implementação de uma feature, no universo ágil, não podemos deixar de falar em critérios de aceite. Critérios de aceitação de uma estória nada mais é que uma lista (tipo um checklist) para verificar se a estória de implementação foi feita de acordo com o que o Product Owner definiu/pediu, atendendo assim os requisitos para a utilização do usuário. Esses critérios surgem de perguntas que a equipe de desenvolvimento faz ao PO no momento em que a estória está sendo descrita, na busca por obter mais detalhes do que deve ser implementado. Garantir que o que foi desenvolvido irá realmente gerar valor para o cliente é um desafio, pois precisamos entender verdadeiramente quais são as suas necessidades. Trabalhar com estórias e com Critérios de Aceite bem definidos garante que possamos chegar no melhor possível a ser entregue com o projeto, gerando qualidade e aceitação daquilo que a equipe de desenvolvimento dedicou seu esforço. Agora, vou deixar abaixo alg...

Hoje de manhã eu estava lendo um artigo no caroli.org , que me fez lembrar que eu já falei aqui no blog do P.O , do Scrum Master , do System Team , mas que eu esqueci de falar do Q.A.. QA vem do inglês, Quality Analyst , e significa analista de qualidade no bom português. Este é um papel muito importante dentro das equipes que trabalham com produtos digitais ágeis. Apesar de existir um outro acrônimo de QA, que em inglês significa Quality Assurance e em português é "Garantia de Qualidade", o papel do QA aqui está mais voltado ao analista de qualidade de testes que à garantia de qualidade propriamente dita. Qual o objetivo de um QA? O QA, assim como o System Team, deve garantir a qualidade do produto. Mas mais do que isso, ele deve garantir que o software que estamos entregando ao cliente é exatamente o que eles querem. Uma análise aprofundada de testes é realizada. A diferença aqui para o System Team, é que o QA está dentro do projeto ágil enquanto o System Team apa...

Quando o modelo de desenvolvimento muda numa empresa, é possível ouvir muitas pessoas dizendo " Isso não vai dar certo " ou então " Sempre funcionou assim, para que mudar? ". A transição de um modelo para outro não é fácil. Saindo de um modelo cascata para o SAFe ( framework ágil, veja outros posts sobre SAFe AQUI ) foi possível observar como o processo de desenvolvimento influencia diretamente na maneira de como os testes são efetuados, e durante esta transição pode-se perceber como a qualidade do teste aumentou com a adoção dos processos ágeis. Isto devido a uma maior participação dos analistas de testes em vários níveis do desenvolvimento, e não apenas na execução como também no planejamento. No processo cascata os testes acontecem apenas ao final de todo o ciclo de desenvolvimento, tornando assim o papel do analista de testes mais reativo. Por outro lado, em um processo ágil o analista de teste se torna mais proativo, pois está diretamente envolvido com...

O System Team por vezes faz jus à expressão " pau para toda obra ". Ja falei bastante sobre o System Team no post anterior AQUI , mas vamos listar aqui algumas de suas atribuições. Depois veremos se não chegamos todos a uma conclusão assim. 😉 Participamos das releases plannings de todas as equipes onde atuamos, auxiliando no refinamento do backlog para definir a os testes das histórias; Criamos novos cenários de testes automatizados; Estendemos os cenários de testes para conjuntos maiores de dados; Organizamos os casos de testes construídos pelos times individualmente em suítes ordenadas; Realizamos teste manual e executamos testes automatizados para novas features e histórias; Eealizamos o teste dos requisitos não funcionais do sistema. Auxiliamos a identificar problemas e gargalos do produto. Pensem comigo, nós do System Team temos que conhecer muito sobre os produtos e sistemas que testamos para poder fazer as atividades acima. O cenário de atuação d...

Trabalho a pouco mais de 5 meses no System Team . Entrei no time no final da primeira release  (iteração)   planejada, participei da segunda release inteira e agora estou na terceira release no time do System Team . Já tive altos e baixos, mas vou tentar explicar tudo sobre esse time neste post. Onde começou o System Team? No framework ágil SAFe , Times Ágeis não são unidades stand-alone . Pelo contrário, eles são uma parte integral do Trem de Release Ágil (ART/TREM), onde eles coletivamente têm responsabilidade por liberar mais valor. Pense na release como um trem, onde cada vagão é uma equipe. Times operam no contexto do trem, contribuindo para sua visão, colaborando com outros times, e participando em cerimonias chave do TREM. Os times e o trem são inseparáveis; o todo é maior que a soma de suas partes. Big Picture SAFe - System Team Afinal, o que é o System Team? Existe um time específico para a execução dos testes de regressão e integração, criado a...

A sigla SAFe significa Scaled Agile Framework, que em tradução livre seria um framework para escalonamento ágil. Ele é um framework de desenvolvimento criado pela IBM para permitir às empresas de grande porte a utilização de práticas ágeis. De acordo com o site do framework, ele serve para abranger toda a organização, operando nos níveis de portfólio, programa e time. Mas por que não colocam o Scrum numa empresa de grande porte, em vez de um framework ágil?  Essa pergunta é fácil de ser respondida. Empresas de grande porte possuem controle, indicadores (para particição de lucros por exemplo), acionistas e , normalmente, certificações ISO. As certificações ISO requerem um processo que todas os colaboradores da empresa conheçam. Só assim a empresa consegue a recertificaçao. Como funciona o SAFe? Retirada do site do framework , a Big Picture do SAFe (abaixo) resume em um fluxograma os processos abrangidos pela metodologia. Nessa figura é possível observar os prin...

Se você trabalha na área de TI, já deve ter vivenciado algum projeto com ágil, ou pelo menos visto alguma iniciativa ágil na sua empresa. Todas as iniciativas, nos mais variados projetos que vi até hoje seguiram as mesmas fases:  Negação -> Resistência  ->   Adaptação/Exploração   - >   Aceitação/Comprometimento . Das 4 fases, a resistência parece ser a fase mais difícil de se passar , especialmente para os desenvolvedores. Eu, como testadora, acredito no ágil sim! Sou feliz de fazer parte de uma equipe que também acredita, mas não foi do dia pra noite que o ágil passou a funcionar na nossa equipe. Foram mais de 2 meses até conseguirmos ajeitar o ágil à nossa equipe. Isso pois ele vem para quebrar paradigmas. O pessoal está muito acostumado e apegado ao modelo de projeto cascata, com toda aquela burocracia, que não consegue ver os benefícios do ágil. A primeira impressão parece ser: Ágil é igual a GoHorse , pequenas entregas de valor, danem-se os...

Continuando a falar sobre os papéis existentes no ágil clássico, hoje falarei sobre o Scrum Master . ​​"Enquanto o Product Owner está focado em construir o produto correto e a equipe de desenvolvimento está focada em produzir corretamente o produto, e o Scrum Master é o cara que ajuda todos a compreender os valores, princípios e práticas do Scrum ."​​ Ele é um Coach ​​​ Deve agir como um mentor, um treinador, para a​​ equipe de desenvolvimento e para o P.O. (ajudando-os a entender e cumprir as suas responsabilidades​). Fazendo uma a analogia com equipes esportivas, é como se o Scrum Master fosse o treinador do time e o Product Owner ​o dono da equipe. Quando surge qualquer problema que a equipe pode, e deve, ser capaz de resolver, a atitude do Scrum Master , como o de qualquer bom treinador, é: "Eu não estou aqui para resolver seus problemas por você; em vez disso, eu estou aqui para ajudá-lo a resolver seus próprios problemas.“​​ Agora, se o ...

Olá Pessoal, Esses tempos participei de uma discussão sobre o papel, características e as responsabilidades de alguns papéis que existem na metodologia ágil. Vou começar falando sobre o Product Owner  ​​​​É um dos os três papéis que constituem a equipe Scrum clássica , (os outros são o Scrum Master e a Equipe de Desenvolvimento).​​​​​​​​  O Product Owner é o ponto central do projeto ágil e é quem exerce a liderança sobre o produto que está sendo desenvolvido. ​​É ele quem diz o que precisa e o que não precisa ser feito em relação ao produto que está sendo desenvolvido.​​ Sempre priorizando os itens a serem desenvolvidos de forma a maximizar o retorno sobre investimento. (R.O.I.). ​​ O Product Owner é quem faz a ponte entre a área de negócios e a Equipe Scrum .​​​ De um lado, o  Product Owner  deve entender as necessidades e prioridades de todos os envolvidos na empresa para agir como seu porta-voz. Neste sentido, ele a...

Uma das palestras vistas no encontro de testadores em Blumenau (que eu comentei AQUI ) fa agile tester (o testador ágil) e como isso estava funcionando dentro de um projeto ágil. O termo agile tester  é utilizado no livro " Agile Testing: A Practical Guide for Testers and Agile Team " para identificar o testador que está alinhado com os princípios e valores ágeis. lava sobre os 10 mandamentos de um Em projetos tradicionais, normalmente há uma gerência (Gerência de Qualidade) e uma equipe (Equipe de Garantia de Qualidade) que são responsáveis por especificar e realizar os testes. A Equipe de Garantia de Qualidade busca encontrar erros, sejam erros de não conformidades com normas técnicas ou não atendimento de requisitos do software. Por outro lado, em projetos ágeis, essa burocracia pode atrapalhar bastante o andamento do projeto. Atualmente, técnicas como o TDD indicam que os testes deve ser escritos e executados pelos próprios programadores, quebrando um pouco a prá...

Olá meu povo testador! Conforme mencionado neste post , uma das palestras que participei num encontro de qualidade promovido pela empresa falou a respeito da definição de pronto. Vou desmistificar um pouco sobre a Definição de Pronto dentro da metodologia ágil. O que é Definição de pronto? Equipes ágeis maduras desenvolvem projetos seguindo alto padrão de qualidade. Tal rigor é imposto por meio da DoD – Definition of Done , ou Definição de Pronto. A DoD é uma discussão entre Time de Desenvolvimento (o que inclui o testador/QA) e Product Owner de que toda a entrega atenderá os padrões de qualidade estabelecidos por eles mesmos . Para que serve o DoD? É uma forma de se buscar a excelência. A discussão aprofunda a compreensão da equipe dos itens do backlog e os requisitos do produto de cada estória da sprint . Quando uma estória está pronta? Vida de Programador - nº1438 Toda mudança é difícil, quando você sai do modelo de desenvolvimento tradicional e vai para...