SAFe – FAQ #1

Com esse post, daremos início a uma série com FAQs (Frequently Asked Questions) sobre o SAFe (Scaled Agile Framework). As perguntas dessa série nasceram no grupo SAFeBrazil.  Os participantes do grupo já sugeriram várias questões, mas pesquei apenas algumas delas para começar a série de posts. Veja abaixo essas quatro perguntas e suas respectivas respostas. Se você deseja sugerir mais perguntas, entre no grupo e contribua com as suas dúvidas e questionamentos.

01) Como começar a implantação do SAFe?

Existem alguns caminhos possíveis para se começar uma adoção ágil. O SAFe trabalha com uma forma de tangibilizar os benefícios de Agile à todo o pensamento estratégico da organização. O SAFe busca criar um ambiente seguro para romper as  barreiras organizacionais e para gerar os ganhos em escala.  Isso acontece através de uma forte sensibilização da abordagem ágil às necessidades e anseios das pessoas que estão no topo das grandes corporações.

Observe que isso não significa que é obrigatório que essas pessoas (normalmente executivos, diretores, C-levels) se tornem agilistas da noite para o dia. Na verdade, trata-se de buscar uma forma em que a abordagem Ágil fale a mesma língua desse topo das organizações.

Para falar essa mesma língua é necessário entender e alinhar todos os potenciais ganhos, relacionados à métodos ágeis, à questões como redução de custo, menor custo de delay, aumento de qualidade, engajamento de colaboradores, redução de time-to-market ou, por um melhor aproveitamento das janelas de mercado.

Então, um dos possíveis primeiros passos é exatamente buscar esse alinhamento político sobre as expectativas da adoção de Agile e principalmente, criar uma integração efetiva do ciclo de desenvolvimento de software com esses anseios estratégicos e econômicos da organização (e vice-versa).

02) Como começar a aprender SAFe efetivamente?

O SAFe traz uma compilação de diversas abordagens já existentes, como por exemplo: pensamento Lean, os princípios do Product Development Flow, Scrum, XP e outras coisas.

Dessa forma, muito provavelmente você já conhece algum desses ingredientes.  E se esse for seu caso, você já começou a aprender SAFe. Contudo, o SAFe, através de uma boa combinação dos ingredientes citados acima, introduz uma completa estrutura metodológica de cerimônias e papéis para garantir uma sincronização e coordenação entre diferentes frentes de desenvolvimento de um mesmo produto/objetivo de negócio.  Então, além da própria experimentação diária que você pode fazer no front de batalha da adoção ágil, você pode participar dos treinamentos licenciados/certificados pela Scaled Agile Academy (instituição por trás do SAFe).  A Adaptworks, mais uma vez está sendo pioneira no Brasil e está ofertando em primeira mão os treinamentos para certificação em SAFe. Esses treinamentos são um excelente ponto de partida para que você se instrumente de ferramentas para rodar Agile em grandes corporações.

03) Pergunta que não quer calar… Qual é a relação de SAFe com o Scrum, um substitui o outro?

Scrum e SAFe muito mais cooperam do que competem nesse caso.  Como falei na resposta anterior, o SAFe é uma forte espinha dorsal que, através da combinação de Lean/Kanban/Scrum/XP, integra o pensamento estratégico organizacional ao dia-a-dia de trabalho do time.  Dessa forma, o SAFe tem um Scrum dentro de si.  Mas observe que isso é diferente de ser um Scrum estendido.

Dentro dos níveis de Portfolio, Programa e Time, o SAFe baseia o nível de Time fortemente em Scrum. Então no SAFe há papéis como Product Owner, ScrumMaster e Time. Além disso, existem as cerimônias de Planning, Daily, Review (Sprint Demo no SAFe) e Retrospective.  E principalmente,  um dos alicerces de todo o trabalho com o Scrum está fortemente presente: O reconhecimento do fenômeno da auto-organização. E por o SAFe ser um framework para gestão do trabalho em escala, ele também se baseia nas reuniões de Scrum-of-Scrums para uma das reuniões de sincronização e alinhamento do trabalho de diferentes times.

Então em resumo, o SAFe reconhece a eficiência que o Scrum introduz no dia-a-dia de trabalho de um time de desenvolvimento de produto, contudo, também reconhece que o Scrum sozinho é insuficiente para responder às perguntas organizacionais de grandes empresas. Por isso, o SAFe introduz outros elementos para ajudar uma empresa ter ganhos em escala com métodos ágeis.
Dessa forma, o SAFe ajudará a estruturar uma forma de resolver a necessidade de escalar e integrar a autoridade de conteúdo nos produtos, também introduzirá meios para sincronizar o resultado do trabalho de cada time, bem como, criar um cultura de priorização e planejamento ágil baseados em critérios econômicos.

04) Qual é o conceito de Time para o SAFe?

O conceito de time é algo universal e o SAFe não muda ou tem seu próprio conceito de time.  Então vamos assumir que um time é grupo de pessoas, que trabalham numa mesma direção, em prol de um mesmo objetivo e, que tem os resultados computados mutuamente.

A principal diferença que SAFe possui, é que existe um nível inteiro no framework dedicado ao trabalho dos times. Assim, o SAFe reconhece que haverão vários times trabalhando para um mesmo objetivo de entrega estratégica.  Esse trabalho precisará de um alto grau de colaboração, comunicação e comprometimento desses times.  Para isso, o SAFe evidencia  que é necessário  ter um estilo de liderança (em todos os níveis do framework) compatível com o processo  motivacional de times criativos.

O SAFe também trabalha fortemente com o conceito de Agile Teams ( ou Scrum Teams, caso prefira), nesse caso, teremos um time composto por pessoas com skill técnico de desenvolvimento,  uma pessoa no papel de ScrumMaster e outra pessoa no papel de Product Owner.  Mas também, o SAFe reconhece que existem, em diferentes níveis da organização, outros times. E esses times precisam ser considerados e integrados ao trabalho em escala de métodos ágeis. Dentre esses times que já existem na organização, podemos citar por exemplo, uma espécie de time de sistema (que na verdade pode ter outros nomes em sua empresa). Esse time de sistema normalmente cuida de questões como integração do produto com outros partes legadas do sistema, ou então questões relacionados à infraestrutura, produção, incidentes,  processo de deploy, testes integrados,   integridade e reuso arquitetural e outras coisas. Entenda, o SAFe é um framework fortemente baseado em integração.  Isso significa dizer que além dos típicos times ágeis, também precisaremos integrar, nos momentos  e assuntos certos, com o trabalho de outros times (até mesmo não ágeis) de sua organização.  Se você tem alguma experiência em grande empresa, saberá que isso é uma questão crítica para todo o trabalho com métodos ágeis.

Mas voltando ao nível de time (no framework), outro ponto importante, principalmente para a visão em escala, é que o trabalho nesse nível  é guiado por instâncias diferentes (mais integradas) de um artefato chamado Team Backlog.  Um Team Backlog é uma coleção de coisas que um time precisa fazer para avançar um incremento do produto/solução em desenvolvimento. Como teremos vários times trabalhando, então teremos vários Teams Backlogs. O conteúdo de um Team Backlog é uma derivação de um Program Backlog (que está no nível de programa). Um Program Backlog é uma lista única de Features (em alto nível) que comporão uma release gerada pelo ART (ver sobre esse assunto no artigo SAFe – Uma visão inicial de como escalar Agile)

Até a próxima pessoal!

Bom, por enquanto é só pessoal. Acredito que essas perguntas iniciais ajudem nossa comunidade a entender um pouco mais sobre como escalar uma adoção ágil através do SAFe.  Até a próxima rodada de perguntas e respostas sobre esse assunto.

Nenhum comentário »

Categorias deste post

FAQ, SAFe

Modelo de Tuckman – How to Build Great Teams – Parte II

Manoel Pimentel continua o papo com Rafael Nascimento sobre a construção de excelentes times, desta vez o foco da conversa é o famoso Modelo de Tuckman, um dos muitos modelos que abordam o assunto.

Conheça os passos do modelo e quais os desafios de se construir um time focado na excelência.

“How to Build Great Teams” é um treinamento ministrado por Rafael Nascimento e Manoel Pimentel – http://www.adaptworks.com.br/TreinamentoDetalhes/team-growing/

Até breve com mais sobre construção de excelentes times e outros assuntos!

Nenhum comentário »

Categorias deste post

Agile, How to Build Great Teams, Videocasts

How to Build Great Teams – Parte I

Manoel Pimentel bate um papo com Rafael Nascimento sobre os fundamentos do treinamento “How to Build Great Teams”.
Para quem se destina o treinamento? Quais os desafios em construir uma equipe forte? Descubra neste episódio do Videocast Adaptworks.

Este é apenas o primeiro da série de 04 vídeos sobre o assunto.
Uma série que promete aprendizado com diversão!

Nenhum comentário »

Categorias deste post

Agile, Videocasts

QUnit para Javascript com Filosofia Aplicada: – ”O conhecimento é sempre uma tradução, seguida de uma reconstrução”. – Parte I

Em os Sete Saberes, Edgar Morin nos conta que “conhecimento” e “conhecimento pertinente” são dois aspectos para os quais devemos nos atentar, devido à complexidade educacional do mundo atual. Mundo esse que intitulamos de era digital ou era do conhecimento.

Considero o princípio da complexidade, premissa, para qualquer estudo de softwares ou das disciplinas interligadas. As ‘boas práticas’, já fundamentadas e experimentadas em estudos anteriores, me servem de guia para meus estudos, porém entendo que práticas podem, naturalmente, emergir, em contextos complexos. E o modelo educacional, discutido, por Morin  atende perfeitamente como modelo de aprendizagem e desenvolvimento de competências ao ambiente dinâmico imposto tecnológica e financeiramente aos profissionais de áreas digitais e afins.

Em Sete Saberes lemos que “conhecimento nunca é um reflexo ou espelho da realidade. O conhecimento é sempre uma tradução, seguida de uma reconstrução”.

Como desenvolvedora, há alguns meses uma curiosidade investigativa sobre testes de unidade em frontends e a tentativa de provar suas vantagens e desvantagens, tem me feito dedicar alguns momentos ao estudo ao framework Qunit aplicado para JavaScript.

E gradualmente uma cadeia de valor sobre o assunto vem acontecendo. Gosto do modelo cadeia de valor do conhecimento, sintetizado, na figura a seguir. Este gráfico reflete como venho adquirindo competência sobre o assunto: testes de unidade em QUnit.

cadeiadevalor

Figura 1 . Cadeia de valor do conhecimento (Fonte: ROWLEY (2007)

E consigo visualizar o ciclo desta cadeia de valor, fundamentada mais uma vez por Edgar Morin e sua teoria. Em uma sequência lógica: dados obtidos do framework de testes, propriamente dito, no site do qunitjs.com e escritos em código Javascript, somados a informações de tutoriais, vídeo-aulas e ideias de testes transformam-se através da prática em conhecimento. No decorrer do tempo esse conhecimento, aplicado e validado, poderá ser reconhecido como uma nova competência adquirida. Aqui identificamos a tradução seguida de uma reconstrução.

Voltando a Grécia antiga, lembramos a visão racionalista de Platão, que afirma que o conhecimento é “uma crença verdadeira justificada”.

E Morin quando nos diz que podemos e devemos aprender por disciplinas, aprendizado por partes, reafirma Platão pois nos diz que temos a capacidade de contextualização do conhecimento, “e é essa capacidade que deve ser estimulada e desenvolvida pelo ensino, a de ligar as partes ao todo e o todo às partes. Pascal dizia, já no século XVII: “Não se pode conhecer as partes sem conhecer o todo, nem conhecer o todo sem conhecer as partes””. E esse conhecimento contextualizado é o segundo aspecto tratado por Morin como “conhecimento pertinente”.

Na prática diária conseguimos criar programas complexos quando o dividimos em unidades menores, compreensíveis, e depois juntamos essas unidades sem que o contexto perca seu objetivo inicial. O teste de unidades – que tanto falamos e executamos – é o teste dessas partes menores. Mas se você ainda não escreveu testes de unidades para o seu código, talvez rever seus conceitos lhe ajude na construção de conhecimento. Esses testes lhe ajudam a pensar sobre seu código de uma forma organizada, minimizam o risco e o esforço ao mudar o código e incentivam o design modular – que tem seus próprios benefícios.

Vamos iniciar uma nova ‘cadeia de valor de conhecimento’, coletando e gerando dados de testes de unidade, com QUnit, para um código simples em JavaScript.

O que é o Qunit?

QUnit é um poderoso framework de testes de unidade JavaScript e muito fácil de usar. Pode ser utilizado em projetos jQuery, jQuery UI e jQuery Mobile, e é capaz de testar qualquer código JavaScript genérico, incluindo a si mesmo!

QUnit pode ser utilizada para testar código JavaScript puro ou mesmo o comportamento do DOM. Por  exemplo, os plugins do JQuery são testados com QUnit, e não somente os códigos de lógica e classes.

Como qualquer ferramenta de teste, o QUnit é perfeito para teste de regressão, afinal, uma vez que um bug é encontrado, você pode criar um teste para validar a existência dele, e após corrigi-lo, verificar a correção, rodando novamente o teste toda vez que você trabalhar no código.

Você não precisa instalar nada de especial para rodar o QUnit, é necessário apenas referenciar o script do Qunit e rodar seus testes no Browser.  O download do script é encontrado no site qunitjs.com, ou pode ser usando diretamente do repositório Git.

Vamos ao primeiro exemplo!

Usaremos uma página HTML simples para testar o nosso “Oi mundo”. Essa página HTML será nossa centralizadora da suíte de testes que estamos iniciando.

Para usar QUnit você só precisa incluir dois arquivos na sua página HTML. QUnit consiste do qunit.js e qunit.css e, também, iremos do quadro “tests runner”, que desenharemos e utilizararemos estilos para a página de suíte de teste exibir os resultados dos testes.

Esta HTML será nossa QUnit “test runner”.

HTML01

Figura 2. HTML pata Qunit Test Runner

Deixaremos o script de teste, que chamamos de testsoimundo.js fora da página HTML.

Manter seu código de teste e suporte à arquivos fisicamente e logicamente separado do código que você está realmente tentando escrever, ou testando unitariamente é importante, e a esses códigos de teste de unidade chamaremos de Suíte de Testes, ou ST. Crie uma pasta separada para abrigar todo o seu código de teste e bibliotecas de suporte, sua ST. Nesta pasta teremos: a Biblioteca QUnit, quaisquer outras bibliotecas específicas para a ST, sua página HTML “test runner” e os arquivos JavaScript que contêm o código de teste. Mas, obviamente, que bibliotecas que são usadas pelo ST e já se encontram em qualquer outro repositório não precisam ser copiadas, podem ser referenciados nas suas localizações originais. Como fizemos com a biblioteca Qunit em nossa HTML “test runner”.

HTML02

Figura 3. Código de teste

Quando a pagina HTML é executada em qualquer browser os testes são executados dinamicamente e exibidos na própria página, por isso a nomenclatura HTML “test runner”.

 

testrunner

Figura 4. Test Runner – visualização

 

O cabeçalho do pacote de teste exibe o título da página e uma barra verde quando todos os testes passaram (ou uma barra vermelha quando pelo menos um teste que falhou), abaixo do cabeçalho vemos algumas caixas de seleção para filtrar os resultados dos testes e uma barra azul com a versão, que foi solicitada pelo navigator.userAgent (útil para screenshots dos resultados dos testes em diferentes navegadores ) .

Das caixas de seleção: “Hide passed tests” é útil quando muitos testes foram executados e apenas alguns falharam. Selecionando esse filtro todos os testes bem sucedidos serão ocultados tornando mais fácil a concentração nos testes que falharam.

Selecionando “Check for Globals ” o QUnit fará uma lista de todas as propriedades no objeto janela, antes e depois de cada teste , para que diferenças sejam verificadas. Isso ajuda a certificar-se de que seu código de teste e código em teste não exportam, acidentalmente, todas as propriedades globais.

Selecionando “No try-catch ” o QUnit irá executar o teste fora de um bloco try-catch . Quando o teste lança uma exceção , o testrunner vai morrer, incapaz de continuar a execução, mas você terá uma exceção “nativa”, o que pode ajudar tremendamente a depuração em navegadores antigos.

Abaixo do cabeçalho é um resumo que mostra o tempo total de execução de todos os testes, bem como o número total de verificações de sucessos e falhas.

O conteúdo real da página são os resultados do teste. Cada entrada na lista numerada começa com o nome do teste seguindo-se, entre parêntesis, o número de falhas, sucessos, o total de verificações. O link “ReRun” é para que qualquer teste possa ser executado individualmente.

Mas até aqui foi fácil!

Até este momento, revisando nossa cadeia de valor, informações básicas foram transmitidas. E o conhecimento ainda é raso para adquirir competência nesse assunto aprofundemos um tanto mais!

Edgar Morin nos dá, como terceiro aspecto, a Identidade Humana. Sim, nós somos geradores e consumidores de conhecimento que flui do ser humano para o ser humano em sua maior intensidade.

“Eu acredito possível a convergência entre todas as ciências e a identidade humana. Um certo número de agrupamentos disciplinares vai favorecer esta convergência. É necessário reconhecer que na segunda metade do século XX, houve uma revolução científica, reagrupando as disciplinas em ciências pluridisciplinares.” (Edgar Morin em Os 7 Saberes).

Porque, nos dias de hoje, testar código na sua origem não é diferencial e sim uma questão de higiene básica de TI?

Evoluímos em nosso conhecimento sobre produtos digitais e amadurecemos na disciplina gerenciamento de produtos, construímos e mantemos software em funcionamento por anos a fio. Falamos muito em manutenção de código legado. Sendo assim, construir código com teste nos garante eficiência em sua manutenibilidade, seja esta planejada ou não. Ter código com cobertura de testes proporciona segurança e rapidez em alterações emergentes de adequação ao mercado. Testes deixa um produto digital mais competitivo.

Em um próximo post nossa preocupação será testar o frontend de aplicações. Testaremos as interações que outro ser humano terá com o software.

Até breve!

Nenhum comentário »

Categorias deste post

Agile, Técnico, Time de desenvolvimento

SAFe – Escalando o Product Development Flow

Como mencionei no artigo anterior,  o SAFe – Scaled Agile Framework, é baseado em princípios Lean, em Scrum, em práticas XP (Extreme Programming) e, em uma considerável experiência de campo de uma ampla comunidade mundial. Ao aprofundarmos essas bases, vamos encontrar um elemento chamado de The SAFe House of Lean  (ver figura abaixo), que é uma variação do famoso House of Lean.  No The SAFe House of Lean, veremos os pilares e valores Lean.    E também veremos que o SAFe é fortemente orientado aos princípios do Product Development Flow (Fluxo do Desenvolvimento de Produto). Esses princípios foram muito bem sintetizados  por Don Reinertsen no livro Principles of Product Development Flow. Nesse nosso post, vamos ter uma visão inicial sobre  esse núcleo do SAFe.

SAFe-House-Of-Lean

Os princípios do Fluxo de Desenvolvimento de Produto são baseados em 08 temas. São eles:

1 –  Take an economic view (Adote uma visão econômica)

Apoie suas decisões sobre o portfolio de produtos e sobre toda a cadeia de desenvolvimento em critérios econômicos.  Adotar critérios econômicos não é algo trivial, pois envolve variáveis como Lead Time,  Custos e Despesas do Desenvolvimento, Geração Valor e também Risco.  O próprio Don Reinertsen reforça que se você tiver que quantificar uma única coisa, quantifique o Custo do Delay (CoD – Cost of Delay). Ou em outra palavras: Qual o custo ou prejuízo de sua organização demorar ou atrasar determinado produto ao mercado?

2 –  Actively manage queues  (Gestão ativa das filas)

Desenvolver, em diferentes níveis organizacionais, uma gestão inteligente sobre as filas de demandas é algo crucial para o sucesso de um portfolio de produtos.  Para isso, para cultivar uma forma inteligente de gerir as filas, é importante entender questões como o efeito que a Lei de Litle  exerce nas demandas, os efeitos de um processamento rápido sobre o tempo de espera e principalmente e ter o controle do tempo de espera através da gestão do tamanho das filas.

3 –  Understand and exploit variability (Entenda e explore a variabilidade)

Admite-se que não é possível gerar valor sem adicionar variabilidade no sistema de trabalho. Isso faz com que assumir riscos seja a base central para criação de valor. Dessa forma,  o SAFe reforça a necessidade de fazer Spikes. O termo spike é uma prática muito forte na XP (Extreme Programming) e ajuda a explorar variabilidade desejada e também ajuda evitar a variabilidade não desejada. Podemos dizer que encontrar esse equilíbrio entre variabilidade desejada e não desejada, é a essência de toda a busca ágil.

4 –  Reduce batch sizes  (Reduza o tamanho dos lotes)

Partindo do princípio econômico que grandes lotes de trabalho aumentam a variabilidade,  retarda o feedback e faz com  que o cycletime (tempo de ciclo) do processo seja igualmente grande, trabalhar com lotes menores, ajuda a reduzir o cycletime,  promove feedback mais rápido e, diminui a variabilidade e o risco do desenvolvimento. Lotes menores também otimizam a forma, o tempo e o custo de handoff (transporte entre etapas) dentro do sistema de geração de valor.

5 –  Apply WIP constraints  (Aplique restrições WIP – Work-in-process)

Gerenciar o WIP é parte central do Kanban. Na verdade, limitar o WIP é uma forma de aplicação do conceito Lean chamado de  Heijunka,  que em uma tradução livre, significa algo mais ou menos como: “Nivelar a carga de trabalho”.  O SAFe, por ser fortemente baseado em Lean, também estimula uma aplicação de Kanban em nível de Portfolio. Dessa forma, reconhece-se que restringir a capacidade de trabalho através uma política de WIP, aumenta a capacidade de entrega e torna o sistema mais fluído e, curiosamente, um pouco mais previsível.

6 –  Control flow under uncertainty: cadence and synchronization (Controle do fluxo sob a incerteza: Cadência e Sincronização)

Cadência torna os eventos imprevisíveis em eventos previsíveis. Já sincronização, estimula que múltiplos eventos aconteçam no mesmo momento. Entender essas diferenças básicas é importante para combiná-las de maneira efetiva em ambiente de escala. Para controlar o fluxo, mesmo sob a incerta, o SAFe  faz a distribuição dessa combinação nos níveis de  Portfolio, Programa e Time.  Essa distribuição  faz com que a organização tenha sensíveis ganhos de planejamento e aprendizado sobre os desvios gerados ao longo do caminho.

7 –  Get feedback as fast as possible (Obtenha feedback o mais rápido possível)

Aumentar a feedbackabilidade, não é algo novo para comunidade ágil. E para o SAFe, isso é o mantra vital a ser propagado em todos os níveis organizacionais. Isso é importante pois loops de feedback locais são inerentemente mais rápidos que os loops de feedbacks globais. Contudo, os loops globais se beneficiam do aprendizado obtido nos locais.  Esse efeito faz com o que a organização gerencie melhor o risco, corrija o rumo dos investimentos e cultive de maneira assertiva a inovação em toda a sua cadeia.

8 –  Decentralize control  –  (Descentralize o controle e as decisões)

A descentralização do controle e das decisões é o elemento crítico para cultivar times auto-organizados e, principalmente, criar um ambiente com maior fluidez na hora de responder às variações dos mercados, dos produtos e do próprio trabalho criativo. O SAFe reconhece que esse é um assunto crítico para que uma empresa possa de fato obter benefícios ágeis para o seu negócio. Dessa forma, as ideias do SAFe estimulam um pragmático reconhecimento de quais decisões, de efeito local, podem e precisam ser tomadas de maneira distribuída e quais as decisões, de efeito global, que ainda precisam ser mantidas de forma centralizada na organização.

 

Bom, essa foi a síntese sobre como o SAFe incorpora os  Princípios do Product Development Flow,  que é uma importante base para se conseguir escalar uma adoção ágil. Como mencionei,  esses princípios estão distribuídos por todos os detalhes do Scaled Agile Framework e norteiam todo o ciclo de desenvolvimento de produtos, desde o nível de portfolio, até o nível do dia-a-dia do time.  Obviamente, que o SAFe empacota esses princípios para que os mesmos sejam vividos de maneira plena, desde pessoas com papéis de C-level,  até todos os envolvidos desde da etapa da identificação de uma oportunidade de negócio, até a implementação da solução para aquela oportunidade. Caso queria mais informações sobre o SAFe, você pode fazer parte do grupo SAFeBrazil (grupo de discussões no facebook) e acompanhar discussões ou contribuir com novas dúvidas sobre o assunto. Até o próximo artigo!

1 Comentário »

Categorias deste post

Agile, Lean, Portfólio, SAFe