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.

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