Bitlady, by @anfindeis

SAFe - um Framework ágil

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 principais elementos trabalhados pelo framework SAFe, incluindo os conceitos de time, programa e portfólio, que serão detalhados a seguir.

Big Picture SAFe

Partindo do menor nível, temos o conceito de time dentro da metodologia. Esse fluxograma pode ser observado na parte debaixo da figura. Os times são formados por um número médio de sete a dez pessoas, incluindo desenvolvedores, testadores, scrum master (SM) e product owner (PO). O formato de trabalho, dentro dos times, é similar ao conceito de scrum, por meio de sprints. São realizadas entregas em curtos períodos que, somando com as entregas dos demais times, formam um incremento de programa, que agrega valor para o cliente. Além disso, o framework se baseia na utilização das metodologias ágeis Kanban, Scrum e XP para a realização de sprints de desenvolvimento.

O conceito de programa é justamente esse conjunto de vários times trabalhando para realizar as entregas para o cliente. Essa entrega maior é chamada, dentro da metodologia do SAFe, de trem (Agile Release Train), e é composta por 5 ou 6 sprints dos times. Na figura da Big Picture SAFe, essa etapa pode ser observada no fluxograma central. Os papéis que compõe esse processo são o RTE, Product Management, System Architect e Business Owners. Esses atores fazem o controle do backlog de programa, definindo prioridades e encaminhando as demandas para cada time, a nível de Feature. As entregas realizadas pelos times ocorrem por meio da cerimônia de Sprint Demo – apresentação dos itens desenvolvidos a serem aprovados pelo PO.

Já o nível de portfólio é composto por membros que devem ter a visão estratégica da organização. Eles são responsáveis por definir prioridades com o cliente, alocar as demandas no backlog dos times, a nível de Épico (iteração maior), organizar entregas, encaixar as necessidades dos clientes nas demandas para o desenvolvimento, etc.

Referências

Scaled Agile Framework – SAFe. Disponível em: <http://www.scaledagileframework.com/>. Acesso em: 16 de maio de 2017.

Evento gratuito de Testes - QA Ninja Conference 2ª edição

Olá Pessoal

Quero compartilhar com vocês um evento de testes que vai acontecer entre os dias 24 a 28 de abril. É a 2ª edição do QA Ninja Conference, a primeira edição eu participei assistindo em outubro de 2016 e foi uma troca de experiências muito bacana. O evento é gratuito e totalmente online. Os assuntos abordados são bem interessantes, acho que vale a pena conferir. 😁

Seguem algumas das palestras que achei interessante (e pretendo ver):

24/04: Fala sério, mulheres na TI?
25/04: Testes em 2027: Para onde QA está indo?
25/04: Como trabalhar com QA em times de desenvolvimento ágil
25/04: Práticas do Agile Testing
27/04: Você já fez dev box testing hoje?
27/04: A importância de testes estáticos na entrega final do produto

Aproveitem, pois é gratuito e online. Ano passado teve várias conversas, entre uma palestra e outra, com pessoas que trabalham com testes fora do nosso Brasil. Muito bacana pra ver as tendências de fora.

Espero que gostem e até mais, 😃

Por que algumas pessoas não acreditam no ágil?

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 testadores e documentadores. É aí que começam a vir os problemas de commit, pois mais de um desenvolvedor alterou o mesmo fonte, na mesma linha, e após o merge o sistema simplesmente para; não compila mais.

Gente, sobre o ponto do commit, o caso é uma questão de Gestão de Configuração e em qualquer (absolutamente qualquer) processo de desenvolvimento que se faça (incluindo-se GoHorse) é necessário uma ferramenta de gerenciamento de fonte e um processo de mudança que permita que mais de um desenvolvedor submeta suas implementações.

Além disso, o ágil diz que todos são responsáveis pelo projeto enquanto equipe na mesma sprint. Não existe essa de "danem-se os testadores e documentadores", pois todos são responsáveis se algo falhar. O desenvolvedor não pode só pensar no mundinho de desenvolvimento. Não existe GoHorse no ágil de jeito algum.

Quanto ao tempo, as pequenas entregas da sprint, são entregas de valor e não qualquer coisa. Para isso é feito todo um detalhamento sobre o que, como e a prioridade das entregas (Sprint Planning). As reuniões diárias também estão aí para que todos saibam o que cada membro da equipe está fazendo e o que ele vai fazer.

O fato é que no modelo cascata ninguém sabe ao certo o que o colega ao lado está fazendo, salvo o gerente de projetos que quando está muito ocupado manda um e-mail todo dia pela manhã perguntando em quantos por cento está a entrega. Eu não acredito no funcionamento de um projeto no modelo cascata, com projetos engessados, complexos, e com estimativas e prazos de entrega tão reais quanto gnomos.

Ao meu ver, esse argumento de que "Ágil no desenvolvimento não funciona", é só uma desculpa de pessoas acomodadas que não querem mudança, pois as tiram da zona de conforto.

Até mais, :D

Papel do Scrum Master no ágil

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 problema é um impedimento que a equipe não pode resolver sozinha, o Scrum Master deve tomar para si a responsabilidade de resolver. Logo, o Scrum Master é responsável por maximizar os resultados do time através do Scrum.

Líder servidor

Um líder servidor nunca perguntaria a um membro da equipe…

"Então, o que você vai fazer por mim hoje?"

Em vez disso, um líder servidor perguntaria…

"Então, o que posso fazer hoje para te ajudar e sermos mais eficazes?"

Autoridade no processo

O Scrum Master é autoridade do processo, deve dominar o processo do Scrum como ninguém.

O Scrum Master tem o dever de garantir que todos da equipe Scrum conheçam os valores, princípios e práticas, juntamente com as abordagens específicas da equipe Scrum. O Scrum Master continuamente ajuda a equipe Scrum a melhorar o processo para maximizar o valor do negócio entregue.

Escudo contra interferências

O Scrum Master protege a equipe de desenvolvimento de interferências externas para que eles possam manter o foco na entrega de valor a cada sprint.

A interferência pode vir de inúmeras de fontes, desde gestores que querem mudar os membros da equipe no meio de uma sprint até a problemas provenientes de outras equipes.

Não importa qual a fonte da interferência, o Scrum Master atua como um interceptor para que a equipe possa se concentrar na entrega de valor.

Removedor de impedimentos

O Scrum Master também assume a responsabilidade de remover qualquer obstáculo que possa inibir a produtividade da equipe (quando os próprios membros da equipe não podem removê-los).

Agente de mudanças

O Scrum Master tem papel fundamental em transmitir o conhecimento sobre o Scrum e sobre as boas práticas associadas aos métodos ágeis, não somente em suas equipes, mas em todos os níveis da organização.

Perfil esperado de um Scrum Master

Conhecimento - Precisar dominar os conceitos do SCRUM. Não necessariamente necessita ser um especialista, a nível técnico, nem a nível de negócio, porém são conhecimentos que podem ajudar.
Questionador - Sempre buscando fazer o time encontrar as respostas para suas próprias perguntas.
Paciente - Busca fortalecer e amadurecer o time, quanto aos conceitos do Scrum, devendo então ter paciência para apoiar o time nesse processo.
Colaborativo - Deve ser colaborativo com o time e P.O., além de incentivar esse tipo de prática dentro da equipe.
Protetor - Devendo proteger a equipe de interferências externar e o processo.
Transparente - Em suas ações e em sua comunicação com os membros da equipe, garantindo o alinhamento das informações.

Você concorda? Deixe sua opinião também!

Até mais. :D

O papél do Product Owner na metodologia ágil

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 atua como um gestor do produto, garantindo que a solução correta é desenvolvida.

Do outro lado, o Product Owner deve se comunicar com o time scrum para ajudar na ordem em que o produto será construído. O Product Owner também deve garantir que os critérios para aceitação do produto estão especificados e que os testes que verificam esses critérios foram executados para determinar que o produto (ou release) possa ser considerado como pronto ao final do Sprint.

Principais responsabilidades

Participação no planejamento

O Product Owner é um participante-chave nas atividades de planejamento de Produto, Release e Sprints:

Durante o planejamento do produto o Product Owner trabalha com todas as partes interessadas da empresa (diretoria, demais departamentos, etc.) para conseguir visualizar o produto ideal.
Durante o planejamento da release o Product Owner trabalha com as partes interessadas e a equipe Scrum para definir o conteúdo do próximo lançamento.
Durante o planejamento da Sprint , o Product Owner trabalha com a equipe de desenvolvimento para definir um objetivo para o Sprint.

Grooming do Product Backlog

É o Product Owner quem supervisiona toda a preparação e refinamento (também chamado de Gromming) do product backlog, o que inclui: criar, atualizar, estimar e PRIORIZAR os itens.

Não é o Product Owner quem realiza todo o trabalho de grooming sozinho e ele, também, não estima os itens sozinho (a equipe deve fornecer os insumos para isso). O P.O. deve sempre buscar o time para alinhamento sobre questões técnicas.

O Product Owner é, no entanto, o principal responsável para que a atividade de Grooming seja feita em prol de um fluxo de entregas que gere valor ao projeto.

Definir os critérios de aceitação e verificar se foram atendidos

O Product Owner é responsável por definir os critérios de aceitação para cada item do Product Backlog (o Scrum Master é quem o ajuda com isso).

Os critérios de aceitação devem ser criados antes do planejamento da Sprint. A equipe precisa do entendimento completo sobre o item para poder incluí-lo no backlog da Sprint.

O Product Owner é responsável por confirmar se os critérios foram satisfatoriamente atendidos. É interessante que ele possa fazê-lo durante o decorrer da Sprint, para descobrir eventuais erros antes da revisão da Sprint.

Colaborar com a equipe de desenvolvimento

O Product Owner deve colaborar frequentemente com a Equipe de Desenvolvimento de uma forma muito direta e estreita, se possível diariamente!

Essa é uma das grandes diferenças para os métodos tradicionais. O envolvimento constante do P.O. com a equipe garante o maior entendimento, alinhamento e resposta a mudanças.

Colaborar com o resto da empresa

O Product Owner deve trabalhar em estreita colaboração com toda a comunidade de partes interessadas para recolher necessidades e sintetizar uma visão coerente para orientar o desenvolvimento do produto.

Partes interessadas internas podem incluir área de marketing, comercial, serviços, etc.. As partes interessadas externas podem incluir clientes, usuários, parceiros, órgãos reguladores, entre outros.

Características/ habilidades pessoais esperadas

Você concorda? Deixe sua opinião também!

Até mais. :D

Os 10 mandamentos de um Agile Tester

Uma das palestras vistas no encontro de testadores em Blumenau (que eu comentei AQUI) faagile 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ática tradicional. E como fica o testador tradicional???

Agile Testing é mais do que isso, é uma forma de utilizar os valores ágeis para auxiliar o testador a ajudar seu time a entregar um maior valor de negócio para o projeto a cada iteração. Logo, não basta escrever um teste automatizado em um projeto ágil para falar que no projeto se faz Agile Testing e que a pessoa é um Agile Tester, alguns princípios devem ser seguidos para reforçar os valores da agilidade.

No livro são discutidos um conjunto de 10 mandamentos do Agile Tester, que irei apresentar abaixo:

1- Forneça Feedback Contínuo

Como a ideia é utilizar esses conceitos em projetos ágeis, o conceito de feedback contínuo não é nenhuma novidade. Uma das principais funções do testador é apoiar o Product Owner e o Cliente à escrever os requisitos de cada user story, na forma de exemplos e testes.

2- Entregue valor para o cliente

Desenvolvimento ágil é entregar valor em ciclos curtos para o cliente. Nesse caso, o testador deve ficar atento às entregas, se estão exatamente de acordo com o que o cliente priorizou recentemente. Agile Testers sempre estão focados no projeto como um todo. As funcionalidades mais importantes de cada release devem estar prontas para serem entregues, mesmo que com isso, outras funcionalidades devam ficam em segundo plano.

3- Buscar a comunicação olho no olho

Nenhum time funciona bem sem uma boa comunicação. Como hoje em dia existem times distribuídos, em diferentes continentes, trabalhando no mesmo projeto, o Agile Tester deve buscar uma forma única para facilitar a comunicação com todos da equipe. Uma ótima prática é a daily meeting: uma reunião rápida, no meio do setor, em pé, onde cada pessoa deve responder a 3 perguntas:

O que fez ontem depois da daily meeting?
O que vai fazer hoje até a próxima daily?
O que está te impedindo de continuar e chegar nos objetivos?

Essa reunião não deve durar mais que 15 minutos. Problemas impeditivos devem ser resolvidos após esta reunião. E gente, isso funciona! :D

4- Tenha coragem

Coragem é um valor importante em projetos ágeis, práticas como testes automatizados e integração contínua permitem ao time praticar esse valor. O time deve ter coragem de realizar mudanças, mas, sem uma suite de testes de regressão automatizados, essa mudança pode ser muito insegura. O Agile Tester deve ter coragem para encontrar os erros de outros e ajudá-los a não cometerem o mesmo erro. Deve ter coragem de pedir ajuda, mesmo quando quem pode ajudá-lo for uma pessoa de difícil acesso.

5- Mantenha a simplicidade

Agile Testers e seus times não devem apenas produzir o sofware mais simples possível que atenda aos requisitos do cliente, mas também devem encontrar a forma mais simples de medir se o software atende a esses requisitos. Logo, medições são importantes, mas não devem ser uma barreira para a condução do projeto.

6- Pratique a melhoria contínua

O Agile Tester sempre deve estar em busca de novas ferramentas, técnicas, habilidades ou práticas que auxiliem em seu trabalho de garantir que os desejos do cliente serão atendidos da forma mais simples possível.

7- Responda à mudanças

Apesar de esse ser um dos valores mais importantes para times ágeis, é um dos mais difíceis conceitos para Agile Testers. Pois com a estabilidade, o testador pode dizer que, após ele testar algo, aquilo está pronto. Entretanto, a adaptação a mudança é necessária, logo, a utilização de ferramentas automatizadas para testes pode auxiliar um Agile Tester a responder a mudanças com maior rapidez e segurança.

8- Seja auto-organizado

O Agile Tester é parte do time auto-organizado do projeto. Logo, ele deve buscar apoio de todos do time para atingir seus objetivos.

9- Foque nas pessoas

Projetos de sucesso são aqueles onde boas pessoas conseguem fazer seu melhor trabalho. Como o testador encontra erros, ele deve fazê-lo sempre respeitando a todos da equipe, nunca focando na pessoa que cometeu algum erro, mas sim no erro que foi cometido, para evitar algum mal estar entre os membros da equipe e ajudar a todos a não cometerem os mesmos erros.

10- Aproveite

Trabalhe em um time onde se sinta confortável, ninguém consegue realizar um bom trabalho em um ambiente ruim.

Finalizando, pode-se perceber que o Agile Tester deve estar alinhado com os princípios e valores ágeis, todos os 10 mandamentos são baseados neles. E você, se considera um Agile Tester? Já pratica esses "mandamentos"?