O que buscar em uma plataforma ALM Agile ?


Application Lifecycle Management
(ALM) é o processo de gestão de todas as fases do ciclo de desenvolvimento de software a partir de requisitos iniciais até o lançamento de uma release. Plataformas de ALM são end-to-end de soluções integradas para a gestão destes processos de uma empresa, bem como, a perspectiva técnica.
Agile é uma metodologia de desenvolvimento de software interativo que vem crescendo rapidamente entre os desenvolvedores e está moldando o mercado de ALM, com desenvolvedores corporativos cada vez mais preocupados em migrar das metodologias tradicionais de desenvolvimento de software para uma abordagem mais ágil. Ágil e ALM, dois segmentos de mercado distintos, estão agora começando a se consolidar. Como resultado, temos agora o que chamamos de plataformas ALM Agile.

 

Estamos treinados a entender plataformas ALM que dividam em grandes ciclos o desenvolvimento do software, como: planejamento, gestão, construção, teste e elaboração de relatórios.

Precisaremos adquirir conhecimento prévio sobre metodologias e frameworks ágeis, para então realizar a avaliação segura de uma ferramenta que trabalhe em harmonia com as metodologias ágeis aderentes a realidade do time e tamanho de empresa, quando pensamos em escala. Essa avaliação levará em conta alguns dos principais passos envolvidos no ciclo de desenvolvimento e entrega de software em produção:
alm

1)
Integrar valores ágeis, processos e princípios para a plataforma de ALM;
2) Gerenciar o ciclo de vida do aplicativo como um Fluxo de Valor Único;
3) Alinhar o negócio com a TI mantendo foco no “entregável”;
4) Suportar a diversidade de ambientes de desenvolvimento;
5) Ser horizontal no gerenciamento de times e flexível;
6) Proporcionar transparência e rastreabilidade;
7) Suporte End-to-End – visibilidade estratégica.
Sabemos que valorizar indivíduos e interação entre eles mais que processos e ferramentas é ser ágil, então quando avaliar uma ferramenta estiver em pauta, esta avaliação deve ser baseada em critérios claros de consolidação entre os conceitos de ALM e os conceitos ágeis. E essa ferramenta deve proporcionar imagens claras, precisas ou imediata de um estado de produto ou fluxo de valor em desenvolvimento.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

Quem é o Agile Tester?

A definição

agile-tester-artigo1Segunda Lisa Crispin e Janet Gregory em seu livro Agile Testing: A Pratical Guide for Testers and Agile Team [1] o que define o Agile Tester é:

Definimos o Testador Ágil neste sentido: um profissional que encara as mudanças, colabora bem com pessoas técnicas e de negócio e entende o conceito de usar os testes para documentar os requisitos e guiar o desenvolvimento.

Testadores Ágeis tendem a ter bons conhecimentos técnicos, e sabem como colaborar com outros membros do time para automatizar testes e também são experientes em executar testes exploratórios.

Eles estão dispostos a aprender o que os clientes fazem para que eles possam entender melhor os requisitos.

Eu, propositalmente, dividi em três partes para ficar mais visível tudo o que um Agile Tester é e o que ele pode fazer!

Mas a primeira resposta a pergunta “Quem é o Agile Tester?” é: qualquer pessoa do time!

Porque qualquer pessoa pode pegar uma tarefa de teste para executar. Qualquer pessoa pode pensar como um usuário no momento de um planejamento. Qualquer pessoa pode executar um teste exploratório.

Para alguém do time possuir estes skills, primeiramente, ele precisa ter o MindSet do Teste Ágil.

O MindSet do Teste Ágil

agile-tester-artigo2O time, ao invés de entregar o melhor produto, deve entregar o melhor valor de negócio para o cliente através de um produto, certo?

A grande maioria dos times focam em entregar o melhor produto, mas nem sempre o melhor produto traz o melhor resultado de negócio.

É aqui que o MindSet entra: trocar informações constantes e colaborar com o cliente* a fim de ajuda-lo a expressar de forma adequada os requisitos.

O restante dos pontos é a viabilização disso (tarefas). O MindSet é único: colaboração com o cliente para que ele mesmo entenda o que está pedindo.

Alguns itens que podem ser adicionados ao MindSet são:

  • Criatividade
  • Estar aberto a novas ideias
  • Disposição para assumir qualquer tarefa
  • Foco no cliente
  • Visão constante na Big Picture (no todo)

* a palavra “cliente” pode ser interpretada como o cliente real ou o product owner (dono do produto)

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Técnico, Testes, Time de desenvolvimento

12 Dicas para uma Sprint Retrospective Meeting efetiva (Parte I)

A Sprint Retrospective é a oportunidade para todo o Scrum Team (Product Owner, ScrumMaster, e Development Team) para se inspecionar e criar um plano de ação para as melhorias para a próxima Sprint.

1.      Excelente ScrumMaster = Excelente Retrospectiva

Tudo o que você precisa é de um excelente ScrumMaster

certified-scrum-masterExistem milhares de técnicas de retrospectiva publicadas em livros e em blogs que quando BEM aplicadas alcançam resultados maravilhosos. A questão principal é saber como e quando aplicar uma determinada técnica ou fluxo ao invés de outra.

Eu sou muito fã da técnica StarFish e recomendo para os ScrumMasters iniciantes e experientes a utilização desta técnica. Pois já tive momentos bons assim como já vi colegas tendo resultados empolgantes com essa técnica.

Mas confesso que nem sempre tenho sucesso ao aplicar essa técnica e que o sucesso veio com a pratica. Pois a questão principal não era saber apenas a técnica e sim saber como facilitar uma retrospectiva.

Alguns colegas dizem que musculatura de retrospectiva só se ganha com o tempo, a pratica e a vontade de melhorar a facilitação. E assim se tornaram melhores facilitadores e suas Sprint Retrospectives se tornaram cada vez melhores assim como os seus Scrum Teams.

E finalmente o Certified Scrum Trainer Alan Cyment vai alem ao dizer que tudo que o Scrum precisa é de um excelente ScrumMaster para começar a fazer Sprint Retrospectives. Por isso espero que as próximas dicas te ajudem a se tornar um excelente ScrumMaster.

2.      Faça a Sprint Retrospective em um momento auspicioso

Uma Sprint não precisa terminar as Sextas

Existe uma tendência de se iniciar Sprints as segundas e terminar as sextas, todavia isto pode não funcionar.

E qual o problema de se fazer a Sprint Retrospective as Sextas?

O seu Development Team pode estar cansado de uma semana intensa de trabalho e participar apenas fisicamente da reunião e terá problemas para manter a presença mental na reunião.

Dependendo do horário da Sprint Review e da Sprint Retrospective alguns times ficam compelidos a fazer trabalhos complexos como implantação e testes exploratórios em um dia em que o foco pode estar no final de semana. Isso se não for encontrado um bug e o resultado da Sprint não for como o esperado.

E dependendo do que é falado na Sprint Retrospective muitos finais de semanas podem ser estragados, ou ainda, algumas situações podem ficar piores…

E finalmente, Estudos mostram que a sexta-feira tem uma ligação forte com os conceitos de “Liberdade” e “Partir”. De certa forma, sexta-feira é o dia que tipicamente as pessoas estão mais focadas em no fim de semana do que em qualquer outro tema. Basta lembrar quantas vezes na sexta-feira o assunto do seu Scrum Team é o final se semana.

Sprint Retrospectives na Sexta-Feira funciona em muitos Scrum Teams, todavia isso pode não ocorrer no seu ambiente de trabalho.

3.      O corpo fala

Escute as palavras e veja o real significado

o-corpo-falaInfelizmente ainda não é possível saber o que outra pessoa está pensando. Dessa forma entender as reais intenções de uma pessoa é algo que beira o impossível.

Podemos ter um melhor entendimento das reais intenções das pessoas por meio das expressões corporais. Por exemplo:

Braços cruzados podem significar desde uma postura defensiva ou de insegurança até uma postura de hostilidade. Uma posição relaxada com braços e pernas ligeiramente abertas demonstra autoconfiança e segurança. Já uma postura recolhida significa tédio.

Movimentos de cabeça de um lado para o outro significam negação, já movimentos de cabeça para cima e para baixo consentimento. Uma postura erguida demonstra segurança, valor e importância no que você está fazendo. E mãos na cintura significam desafio, agressividade.

Alguns sinais corporais podem trazer impressões incorretas, todavia desconsiderar essas informações valiosas em uma facilitação pode levar a resultados desastrosos.

Em outras palavras, comece a ler o Best Seller “O Corpo Fala – A Linguagem Silenciosa da Comunicação Não-verbal” do Pierre Weil e do Roland Tompakow.

4.      Presença obrigatória do Product Owner

A participação do Product Owner é essencial na Sprint Retrospective

O Product Owner é obrigado a participar da Sprint Retrospective. E acredite isto está escrito no Scrum Guide. A primeira frase do Scrum Guide sobre a Sprint Retrospective é a seguinte:

“A Sprint Retrospective é uma oportunidade para que o Scrum Team inspecionar a si próprio e criar um plano de melhorias para ser aplicado na próxima Sprint.”

Tendo em vista que o Scrum Team é compreendido pelos três papeis do Scrum incluindo o próprio Product Owner. A presença do Product Owner é obrigatória, seu Scrum Team gostando ou não.

A questão principal é que existe a responsabilidade do ScrumMaster em garantir a segurança psicologia de todos os envolvidos durante a Sprint Retrospective.

Por exemplo, com frequência o Development Team não se sente à vontade em frente ao Product Owner, por questões que vão desde arrogância, hierarquia, desconfiança, dentre outras. Nestes casos Peter Hundermark recomenda que, temporariamente, o Product Owner não participe das Sprint Retrospectives e o ScrumMaster trabalhe em paralelo estas questões objetivando a segurança psicológica da reunião.

Vale lembrar que o Scrum demanda muito trabalho do Product Owner e estes precisam ser capazes de colaborar com a melhoria continua dos processos dentro do Scrum. Como exemplo de processos em que o Product Owner é essencial tem-se a priorização e a preparação dos itens do Product Backlog e o relacionamento com os Stakeholders.

5.      Não buscar culpados

Diga não à caça às bruxas!

apontando-erradoUm dos maiores receios ao se entrar em uma Sprint Retrospective é o de que a reunião se torne uma sessão de caça às bruxas, onde a única coisa que importa é buscar culpados.

Claramente tal atitude não contribuirá para a evolução do time ou para um melhor desempenho coletivo. Com esse raciocínio Norman Keath define a primeira diretiva de uma boa Sprint Retrospective como:

“Independentemente do que descobrirmos, nós entendemos e realmente acreditamos que todos fizeram o melhor que podiam, dado o que eles sabiam no momento, as suas competências e capacidades, os recursos disponíveis, bem como a situação na mão. ”

Dessa forma a chave para uma Sprint Retrospective bem-sucedida e construtiva é garantir que todos os participantes estejam de acordo com essa diretiva. E assim teremos um tão sonhado evento de aprendizagem coletiva que irá dar bons resultados no longo prazo.

6.      Checar e Atuar

Sempre há algo a melhorar no processo

O mais importante de uma Sprint Retrospective é o comprometimento dos envolvidos com as melhorias do processo de desenvolvimento de software.

No Scrum temos diversos ciclos de PDCA (Plan-Do-Check-Act) sendo executados com diferentes objetivos. Na Sprint Retrospective é feito o Checagem do processo e a criação de um plano de ação para melhorias.

Jean Tabaka menciona que sair de uma Sprint Retrospective sem um plano de ação é uma das maiores falhas possíveis, mas de nada adianta criar um plano de ação e este não for foco de atuação durante a próxima iteração.

Existem estratégias como um backlog de melhorias, expor o plano de ação em local visível, e pedir para todos os envolvidos escrever o plano de ação auxiliam na implementação das melhorias. O ScrumMaster deve guiar a melhoria dos processos, todavia deve haver o comprometimento de todos os membros do Scrum Team com a melhoria continua de processos.

Jeff Sutherland finaliza neste vídeo com a seguinte definição de Sprint Retrospective:

“ A Sprint Retrospective é desenhada para corrigir o problema mais importante. E quando isso ocorre, o Development Team acelera e começa a ir mais rápido, assim como a qualidade também aumenta. Dessa forma a Sprint Retrospective é crítica para o aumento da performance do Development Team.”.

___________________________________________________________________________________________________________________

Gostou? Aqui você encontra as outras 6 dias para tornar a sua Sprint Retrospective ainda mais eficiente.

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

2 Comentários »

Categorias deste post

Daily Meeting, Scrum, Sprint, Sprint

Personas Ágeis para User Stories

Descrição completa

Por que personas são relevantes em contextos ágeis?

Em projetos ágeis “personas” devem ser vistas como uma ferramenta fantástica nas mãos de um time.
A equipe do Product Owner (composta pelo P.O., especialista em experiência do usuário, analista de negócios…) pode, facilmente, utilizar de “personas” para alinhar suas expectativas com o time funcional (arquitetos, desenvolvedores, testes…) proporcionando uma visão compartilhada e realista do produto em desenvolvimento. E usar personas pré-definidas como atores de user stories farão com que os requisitos descritos tenham mais credibilidade e mais envolvimento, aproximando-os ainda mais da realidade.

Detalhando:

personas-ageis-para-user-storiesPersonas é uma ferramenta de usabilidade que utiliza pessoas fictícias para representar usuários. Utilizamos personas em projetos centrados no usuário (For Them By Us), definindo os objetivos e desejos dos reais usuários, orientando decisões como: a interface, a navegação, os recursos e demais elementos do projeto de design.

Usar personas é recomendado quando não há nenhuma documentação sobre quem é o usuário do seu produto ou se quer especializar a UI (user interface) do produto para o seu público alvo, com base em pesquisas entrevistas, etc. Mas quando estamos em um projeto onde o usuário final não é humano, por exemplo um sistema system-to-system, uma API, etc. onde nenhum que irá interagir com o sistema é humano acho que não faz muito sentido usar personas.

personas-ageis-para-user-stories_2E como explica Martin Fowler, User Stories focam nos objetivos
do usuário e como o sistema alcança esses objetivos. User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão

Alguns perguntarão o motivo desta proposta estar em “Design” – lembrando que design é a idealização, criação, desenvolvimento, configuração, concepção, elaboração e especificação de objetos que serão produzidos. O projeto de design necessita de uma análise informacional, a partir de um ponto de vista. Detectar corretamente as “personas-usuárias” e relacioná-las ao objetivo do projeto (user stories) é essencial para um bom planejamento, de modo que as ações sejam tomadas de forma correta – assim, segue esta proposta, pois para quem é designer, quem é o usuário, e quem é o público final, representa o primeiro passo.

Sugestão de dinâmica para aprendizado de Personas

Mecânica do Workshop

1) O grupo de participantes será dividido em 5 times, através de uma dinâmica simples, baseada na diversidade de informações sobre os próprios participantes (onde moram, onde trabalham, cargo exercido, idade, sexo, etc.) fazendo-os mixarem-se em times que prevaleça a diversidade. (time-box 5 minutos)

2) Um sistema web “fictício” em desenvolvimento será mostrado: loja online de feijoadas delivery. E algumas informações sobre cozinheiros, fornecedores de ingredientes e clientes desta loja online de feijoadas delivery serão apresentados: em slides e cartões de papel e entregues aos times.
A facilitadora se nomeará Product Owner principal do produto: loja online de feijoadas delivery. (time-box 5 minutos)

3) Uma introdução sobre personas “driven-design-personas” será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 15 minutos)

4) Serão solicitados a criação de mais 2 personas por time, a partir das informações apresentadas previamente. (time-box 10 minutos)

5) Uma introdução sobre user stories, baseadas nos 3Ws e 3Cs será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 10 minutos)

6) Serão solicitados a criação de mais 3 user stories por time, a partir das informações apresentadas previamente para as 2 personas criadas pelo próprio time. (time-box 15 minutos)
– Durante o processo de criação, de personas e US pelos times, a facilitadora irá circular pelos participantes esclarecendo dúvidas e pontuando conceitos dados.

7) Os times apresentarão suas personas e user stories para os demais participantes, com pequenas intervenções da facilitadora para garantir time-box e ressaltar conceitos vistos. (time-box 15 minutos)

8) Encerramento e dúvidas. (time-box 5 minutos)

Benefícios

Uma grande vantagem de se utilizar personas é que se pode facilmente interligá-las com user stories, em substituição do “ator”. Isto faz com que suas personas e user stories tenham mais credibilidade e mais envolvimento, aproximando ainda mais da realidade.

E a melhor forma de aprender sobre personas e interliga-las com user stories de um produto, é escrevendo ambas. Hand´s on.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

Product Backlog Building

Scrum é um framework para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente com iterações de 1 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

Como chegar ao Backlog?

Como construir algo que tenha valor?

Como encontrar a real necessidade do cliente?

Como definir o que é prioridade para o cliente no primeiro momento?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

A dinâmica do PBB consiste em vivenciar na prática a construção do Product Backlog utilizando o Backlog Canvas como ferramenta. Essa dinâmica leva todos os envolvidos do negócio a uma experiência prática de elaboração e definição de um Product Backlog efetivo totalmente consistente e alinhado com os valores de negócio do cliente.

Principais benefícios:

  1. Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
  2. Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
  3. Buscar uma maneira de descrever a experiência do usuário com o produto.
  4. Facilitar a descoberta e escrita de User Stories.

 

 

PBB é representado por um canvas chamado de Backlog Canvas que tem um fluxo bem simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância nesse processo de construção.

Veja abaixo o fluxo de construção do Backlog:

IDENTIFICAÇÃO: A primeira etapa é identificar o produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas buscam de forma colaborativa a mesma compreensão do estado atual, pontuando os problemas que desejam que sejam resolvidos. É importante conhecer o problema antes de criar a solução.

EXPECTATIVAS: Nesta etapa é importante identificar o Estado Desejado, alinhando suas expectativas aos problemas do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.


PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio, seus problemas e dores, necessidades e objetivos.

 


ÁREAS DE NEGÓCIO:
A partir desse momento, identificado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS e os principais objetivos de negócio das partes interessadas de cada área.

 

 

 

 

 

 

 

 

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa” da parte interessada relacionada a essa atividade de negócio.

overview-product-backlog-building-atividade-de-negocio

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representá-las por User Stories ou modelo ARO (<AÇÃO><RESULTADO><OBJETO>). Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

 

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

*As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreensão e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

 

Como resultado teremos um Product Backlog totalmente alinhado com o valor de negócio do cliente.

O Scrum não fala como podemos representar cada item no Backlog, podemos escrever de várias forma, inclusive de forma textual. A User Story é a forma mais usadas hoje pelos times ágeis para representar um item no Backlog. História de Usuário é uma breve descrição do que é necessário para o cliente ter no produto, que pode representar uma necessidade do usuário ou uma descrição de uma funcionalidade.

A estrutura de uma História de Usuário basicamente responde 3 perguntas: QUEM? O QUE? POR QUÊ?

 

O PBB nos ajuda na escrita das User Stories. Como podemos notar no PBB temos o “QUEM?” que é a Parte Interessada, o “O QUE?” que nesse caso são as funcionalidades já representadas em modelo ARO e por último, o “POR QUÊ?” que está no objetivo e benefício que a parte interessada destacou na atividade de negócio.  A figura abaixo exemplifica de uma forma bem simples como fica fácil escrever as User Story com ajuda do Product Backlog Building.

 

Como podemos perceber o grande poder do PBB é a facilitação e a colaboração que provoca com todos os envolvidos na construção de um Backlog, sempre levando todos a  um entendimento compartilhado do contexto de negócio e a descoberta de itens do Backlog totalmente alinhado com o valor de negócio do cliente.

Pronto! todas as funcionalidades descobertas representarão os itens do Backlog. Agora é só priorizar o Backlog usando quaisquer técnica de priorização e começar entrar…

Baixe aqui o seu Backlog Canvas e comece a construir seu Product Backlog:

Vídeo: Product Backlog Building com Fábio Aguiar | Test-Drive

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

3 Comentários »

Categorias deste post

Agile, Scrum

A origem do Agile Testing

Origem

Se você já leu algo referente a Agile Testing vai lembrar logo do livro Agile Testing, que foi lançado em 2009, e associar que a origem do termo veio das duas autoras Janet Gregory e Lisa Crispin, certo? Errado!

Em 2002 Bret Pettichord já falava sobre Agile Testing [1] associando ele também com princípios de Context Driven Testing [2]. Na sequência, em 2003 Brian Marick criou o Quadrante de Teste Ágil para distinguir dentro de um processo ágil os testes baseados em negócio e em tecnologia, e os de suporte ao time dos de crítica ao produto.

A Elisabeth Hendrickson em 2008 também já falava sobre Agile Testing na sua palestra Agile Testing, Nine Principles and Six Concrete Practices for Testing on Agile Teams [3].

Lisa Crisprin, em 2002, trabalhou em um time que aplicavam as práticas de XP – Extreme Programming e já começava a criar algumas técnicas de como um testador poderia trabalhar em um time XP. Logo após o primeiro livro formal sobre o assunto foi lançado: Testing Extreme Programmimg [4]. Anos depois ela e a Janet Gregory lançaram o livro Agile Testing que é um compilado das experiências das autoras no processo de transição do Teste Tradicional para o Teste Ágil e como o testador pode ajudar a equipe.
Hoje este livro é a principal referência sobre Agile Testing.

Teste Tradicional x Agile Testing

A imagem abaixo já vai ilustrar uma similaridade e a diferença da adoção de cada abordagem:

origem-agile-testing

origem-agile-testing_2

No projeto por fases podemos ver nitidamente que há uma fase de testes, mas esta depois do desenvolvimento ter sido concluído. A ideia do tamanho das caixas nos passa uma falsa impressão que realmente teremos tempo para testar, mas o que acontece em diversos projetos (até hoje) é a fase de testes ser diminuída e termos uma nova caixa antes da Entrega: o “Teste->Bug->Correção->Reteste” que toma muito mais tempo do que qualquer planejamento inicial de testes.

No Agile os testadores trabalham em cada Interação junto ao time e testam a funcionalidade mesmo quando ela está em desenvolvimento. A funcionalidade/requisito/regra (User Story + Critérios de Aceite) só estarão realmente entregues depois de testado (que são pontos do DoD – Definition o of Done).

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

Como validar PDUs do PMI em treinamentos da Adaptworks?

Para renovar a certificação PMP (Project Manager Professional) do PMI (Project Management Institute), o profissional precisa coletar um total de 60 PDUs (Professional Development Unit).

Se você particiou das turmas de:

• Certified ScrumMaster
• Certified Scrum Product Owner
• Certified SAFe Agilist
• Certified SAFe Product Manager – Product Owner
• Certified SAFe Scrum Master

• Certified SAFe Advanced Scrum Master
• Management 3.0
• Certified Agile Professional

na Adaptworks, você pode solicitar a quantidade equivalente de horas de treinamento em PDUs.

Isso mesmo, todos os treinamentos acima podem lhe adicionar preciosos PDUs!

Se você estiver em busca de PDUs e fez um destes treinamentos conosco, segue os passos para solicitação dos PDUs:

1) Acesse o site do CCRS e faça login.

2) Clique em Report PDUs na barra de navegação a direita para iniciar o processo.

3) Clique em Course Training

4) Em Provider digite o nome da Adaptworks.
Provider: Adaptworks Treinamentos

5) Em Activity digite o nome do treinamento que você cursou.
Provider: NOME_DO_TREINAMENTO

6) Em description digite a descrição do treinamento que você encontra no site da Adaptworks.
Drescription: DESCRIÇÃO

pdu-adapt-pmi-cap-csm-cspo-artigo7) Preencha a data de inicio do seu treinamento.
Date started: DATA_INICIO

8) Preencha a data de fim do seu treinamento.
Date started: DATA _FIM

9) Preencha o endereço do nosso website.
URL: adapt.works

10) Preencha o nome do nosso contato comercial.
Contact Person: Marcio Santos

11) Preencha o telefone para contato na Adaptworks.
Contact Phone: (11) 2507-3563

12) Preencha o endereço de contato da Adaptworks.
Contact Email: contato@adaptworks.com.br

13) Clique em próximo

14) Em PDUs claimed, distribua o número de horas do treinamento entre Tecnhical, Leadership e Strategic. Recomenda-se 10 para Tecnhical, 3 para Leadership e 3 para Strategic. Totalizando 16 PDUS.

15) Clique em “I agree the claim is accurate” e pressione “Submit”.

16) Terminado, agora é só esperar a resposta do PMI.

Este fluxo é uma tradução livre das instruções do próprio site do PMI

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Certified Agile Professional, Management 3.0, PDU, SAFe, Scrum

Você deve ler o Scrum Guide com frequência!

O Scrum é um framework de desenvolvimento descrito em um guia de dezesseis páginas e como praticante você deveria lê-lo com frequência.

Isso mesmo, o Scrum é um framework com um texto curto, direto e simples. Um bom significado para Simples é “o que é elementar, não apresentando qualquer embaraço para sua compreensão.” Ou seja, no Scrum Guide temos apenas o que é elementar para o desenvolvimento de produtos com o objetivo principal de ser um guia de fácil compreensão.

ScrumButAo mesmo tempo, colocar em prática como descrito no guia não é uma tarefa fácil. Qualquer praticante sabe que praticar Scrum é fácil na teoria todavia a prática do dia a dia é muito mais dolorosa. É muito fácil e cômodo cometer desvios e começar a executar o famoso ScrumBut.

Você executa ScrumBut quando você diz coisas como: “eu prático Scrum mas não faço reunião diária”, “eu uso Scrum mas minha área de negócio não sabe e eu não tenho PO”, “eu pratico Scrum mas tenho sprint só de documentação”.

Aparentemente, não parece haver problema ao se executar um Scrum pela metade, ou faltando uma perna, porém o Scrum é baseado em teorias complexas, como executar ciclos diários de PDCA (Planejar, Desenvolver, Checar e Agir).

A reunião diária é o momento do Scrum que obriga o time a executar um ciclo de planejamento, execução, checagem e ação todos os dias. Ou seja, não fazer a reunião diária implica em não fazer o ciclo diário de PDCA e no longo prazo alguém vai pagar essa conta.

Em cada um dos ScrumButs exemplificados passa-se por cima de alguma teoria que embasa o Scrum.

O Scrum é um framework simples mas emergiu a partir de um time de desenvolvimento que estava cansado da forma antiga de trabalhar e que estudou muito para elaborar o framework. Os criadores do Scrum estudaram teorias de relacionamento interpessoal, teorias de produtividade de times e indivíduos, teorias de linhas de produção enxuta.

Ou seja, criaram um framework simples e que é embasado por teorias complexas.

leitura-scrum-guideAo ler o framework com frequência você tem menos chance de corroer um pedaço dele por desconhecimento e terá, assim, um conhecimento do que é Scrum de forma mais concreta.

Outra coisa importante é saber o que faz parte e o que não faz parte do Scrum.

O Scrum é um framework enxuto e no qual o praticante pode preenche-lo com os recheios que fazem sentido para um projeto específico. Muito do que se comenta sobre Scrum em blogs e livros dizem respeito aos recheios e não ao core do Scrum. Por exemplo:

  • User Story não faz parte do Framework do Scrum mas você pode usar;
  • O quadro de kanban não faz parte do Scrum mas quase todo mundo usa;
  • A reunião diária não precisa ser em pé em frente ao quadro mas é mais produtiva se realizada desta maneira.

Poderia ficar enumerando vários outros benefícios, o que ficaria cansativo…

Mas para finalizar:

O Scrum Guide é a base do framework mais utilizado em projetos ágeis hoje em dia e demora menos de 30 minutos, inicie a leitura agora! :)

Referências

ScrumGuide

Scrum, A arte de fazer o dobro do trabalho na metade do tempo. Jeff Sutherland

VersionOne. State of Agile Survey 2011.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Scrum

Usabilidade não é “User Experience” (UX) – Mas é Ágil

Usabilidade não é a experiência do usuário, ela ajuda a melhorar, e muito, essa experiência. A maior parte das pessoas ainda confunde UX com Usabilidade. É comum vermos gerentes de projeto, designers, arquitetos, todos substituindo o termo usabilidade unicamente por UX, dizendo equivocadamente “A ´UX´ do site está pronta?”

Apesar de parecer complexo, UX se resume em uma única frase: UX É CONCEITO.
E este conceito está em total harmonia com os conceitos ágeis.

Entendendo:

Temos experiência de usuário em contextos diversos.

Por exemplo, quais sensações e percepções um cliente de fast-food tem ao adquirir e saborear sua refeição? Este cliente é o usuário desse sistema. E quais são as sensações e percepções deste mesmo cliente ao se alimentar em um restaurante gourmet, com refeições à la carte?

Serão experiências diferentes e que não significam melhores ou piores, mas diferentes para o tipo de necessidade do momento.

Os designers direcionam a experiência do usuário. Eles podem gerar fluxos de página, wireframes e, claro, um mapa do site, adicionar testes de usabilidade e revisões. No entanto, UX designers terão uma abordagem diferente, eles levam em conta o proposto pelo design, mas também vão considerar os objetivos emocionais de seu usuário final. Seu foco pode ser mais em torno de modelos de interação, ao invés de estrutura e layout.

A partir do entendimento do que não é UX, entenderemos melhor o conjunto de “usabilidade e UX” no contexto ágil.

ux

Emprestando a hierarquia de necessidades de Maslow, que nos diz que o software deve ser funcional, o software deve ser fácil de usar – ressaltando a importância de Jakob Neilsen – onde o software precisa ser prazeroso, usando os conceitos de Emotional Design de Donald Norman – pioneiro na usabilidade – conceituaremos “UX preocupado com o design e usabilidade” e por fim com o engajamento emocional dos usuários, através da discussão prática sobre:

--

  1. Curva de Aprendizado,
  2. Curva de Satisfação,
  3.  Atendimento de uma necessidade do usuário,
  4. Feedback do usuário.

A seguir temos 10 dicas de como integrar o conceito UX às metodologias ágeis.

  1. Direcionar e incorporar: praticantes de UX devem fazer parte do time do cliente ou Product Owner;
  2. Realizar práticas de pesquisa, modelo, e design antecipado – mas apenas o mínimo necessário;
  3. Divulgar e aplicar o conceito de “Personas”;
  4. Utilizar de um fluxo de desenvolvimento paralelo avançado com acompanhamento do avanço através de feedbacks;
  5. Ganhar tempo de design com histórias complexas de arquitetura;
  6. Cultivar um grupo de usuários para validação contínua;
  7. Aproveitar o tempo do usuário para diversas atividades como inception ágil ou grooming;
  8. Utilizar protótipos de baixa fidelidade;
  9. Tratar os protótipos como especificação;
  10. Tornar-se um facilitador de design.

UX não é usabilidade – mas é ágil: define conceitos, discute a forma de trabalho ágil em uma disciplina – design – vista como arte. E sabemos, arte dificilmente pode ser definida com time-boxes. Com dicas práticas e experiência, no complexo ambiente do software, a apresentação e a discussão em torno do assunto ajuda a clarificar e evoluir a disciplina que tanto cresce neste ambiente. E aqui falamos de adaptabilidade e aprendizado contínuo, agilidade em sua essência.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

DICAS PARA UMA DAILY SCRUM MEETING REALMENTE EFICIENTE (PARTE II)

Você sabe realmente o que é uma Daily Scrum Meeting? Então lá vai uma explicação clara e direta:

“A cada dia do Sprint a equipe faz uma reunião diária, chamada Daily Scrum. Ela tem como objetivo disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho a ser realizado no dia que se inicia. Os Daily Scrums normalmente são realizadas no mesmo lugar, na mesma hora do dia. Idealmente são realizados na parte da manhã, para ajudar a estabelecer as prioridades do novo dia de trabalho.”

Analisando todo o ambiente da Daily Scrum, criamos algumas dicas que facilitarão o processo. Já falamos sobre algumas delas neste post e aqui vão as demais:

7.    Faça off-line

Por favor, desliguem os dispositivos eletrônicos e telefones celulares

celularO Development Team deve estar com foco total na Daily Scrum, dessa forma o uso de telefones celulares e computadores deve ser evitado.

Os celulares são fonte de distração o tempo todo, pesquisas cientificas tem mostrado que a simples interrupção causada pelo aviso sonoro faz com que a pessoa desfoque e passe a pensar no que está ocorrendo no mundo digital. Essa falta de foco pode significar desde um detalhe que irá passar desapercebido até uma repetição do que uma das pessoas falou.

Os computadores devem ser evitados nessa reunião para que os membros do Development Team não se sintam compelidos a corrigir bugs, auxiliar o colega com dificuldade ou abrir o Facebook. De forma geral, a ausência de computadores irá ajudar os membros do Development Team a controlar a ansiedade de resolução imediata de problemas.

O Development Team deve entender que a Daily Scrum é uma reunião de planejamento diário para auto-organização com objetivo na completitude da Meta da Sprint.

 

8.    Utilize um Token

Todos falam, na sua vez, e todos escutam

Introduzir um mecanismo de ordenação como um token ajuda a fazer com que todos falem e todos escutem.

Nesta técnica apenas a pessoa que tiver com o token na mão pode falar e as outras devem prestar atenção em quem estiver falando. Desta forma até os mais introspectivos falam e são ouvidos pelos extrovertidos.

Jogar o Token de forma imprevisível introduz um pouco de diversão para o ritual da Daily Meeting. Todavia ficar jogando um token pode ser algo negativo, pois pode ser visto como pouco profissional e criar uma percepção negativa desnecessária da Daily Scrum.

A forma mais simples e que ao mesmo tempo é muito eficaz é utilizar uma caneta como token e passar a caneta no sentido horário.

 

9.    Em pé

Faça a reunião em pé para assegurar que ela seja curta.

standupmeetTodas as pessoas se incomodam ao ficar em pé e este incômodo faz com que todos queiram que a reunião acabe o mais rápido possível. Ao ficar em pé, pessoas que gostam de falar se tornam mais objetivas e evitam contar história, discutir ou justificar problemas em demasia.

Do ponto de vista fisiológico, ao ficar em pé a área do pulmão que possui maior absorção de oxigênio fica disponível e por consequência as pessoas ficam com maior capacidade de raciocínio por estar com o cérebro mais oxigenado.

Existe o mito de que a Daily Scrum precisa ser feita em pé em frente. É importante ressaltar que não existe menção a isso no Scrum Guide, todavia é uma das práticas do framework eXtreme Programming que muitos Scrum Teams utilizam.

 

10.    Multiplique os facilitadores

Ensine facilitação e como ser facilitado

multiplique

ScrumMaster deve ensinar ao Development Team como se manter na timebox e ao mesmo tempo como conduzir a reunião. Utilizando palavras do próprio Scrum Guide “O ScrumMaster assegura que o Development Team tenha a reunião, mas o Development Team é responsável por conduzir a Daily Scrum. O ScrumMaster ensina o Development Team a manter a Daily Scrum dentro do timebox de 15 minutos. ”

O ScrumMaster deve ensinar aos membros do Development Team a conduzir a Daily Scrum e uma das técnicas que pode ser utilizada é alternar o facilitador da Daily Scrum.

Essa delegação de facilitação não deve ser confundida por “delargação” da facilitação pois o ScrumMaster em última instancia é o responsável pela boa execução da Daily Scrum.

Dessa forma o ScrumMaster deve ensinar o Development Team a conduzir e ser conduzido nesta reunião. O que no longo prazo irá facilitar a vida de todos os envolvidos.

 

11.    Mesmo horário todos os dias

A repetição gera o hábito, o hábito gera a excelência

agendaTer o habito de fazer a Daily Scrum no mesmo horário todos os dias nem sempre é fácil por motivos como horário flexível e ausência de membros do Development Team.

O Scrum Guide não diz qual o melhor horário para a realização da Daily Scrum, ele só fala que deve ser feita no mesmo horário e local para reduzir a complexidade. Os Scrum Team geralmente fazem a Daily Scrum no início e no fim do dia, todavia nada impede de fazerem a Daily Scrum as 11 horas ou as 16 horas.

A definição do horário deve ser baseada no horário em que mais pessoas estão aptas e dispostas a fazer a reunião. Isso evitará faltas e pessoas desmotivadas na reunião.

Uma das formas de destruir a Daily Scrum é realizar a reunião no primeiro horário do trabalho em um ambiente em que poucas pessoas chegam pontualmente no trabalho. É obvio que a reunião será tida como infernal em pouco tempo.

Em times dispersos geograficamente com fusos horários diferentes, definir um horário pode ser ainda mais difícil, pois nem sempre irá haver um horário que agrade a todos. Em última instancia definir um horário rotativo pode se tornar uma opção.

Em relação a ausência de membros do Development Team, uma prática que faz sentido é definir um quórum mínimo de participantes e caso esse quórum não seja atingido a reunião não é realizada e uma ação é tomada.

 

12.    Foco na Meta da Sprint

O foco do Development Team é atingir a meta da Sprint?

A Daily Scrum tem como foco a autorganização do Development Team para atingir a meta da Sprint.

Houve uma clarificação disto na última versão do Scrum Guide na qual as próprias perguntas a serem respondidas mudaram:

  • O que eu fiz ontem que ajudou o Development Team a atender a meta da Sprint?
  • O que eu farei hoje para ajudar o Development Team a atender a meta da Sprint?
  • Eu vejo algum obstáculo que impeça a mim ou Development Team no atendimento da meta da Sprint?

metaO foco das respostas é sempre em relação a atender a meta da Sprint e nunca em um plano previamente feito, isso na prática quer dizer que nesta reunião ocorrem os ajustes no plano para atender a meta da Sprint.

O segundo item importante é o foco no Development Team como um todo e não na meta individual de cada um dos seus membros. Isso clarifica a importância de trabalhar como um time e não individualmente.

Vale destacar que essa “mudança” do foco individual para o Development Team foi feita na última versão do Scrum Guide. O foco sempre foi o Development Team como um todo, todavia isso não estava claro nas ultimas versões.

Uma das maiores reclamações de membros do Development Team é a impressão de que a Daily Scrum era uma perda de tempo tendo em vista que achavam estar fazendo apenas Status Report para os outros membros. Com essa “mudança” fica claro que o Development Team como um todo deve se ajudar a atender a Meta da Sprint.

___________________________________________________________________________________________________________________

Gostou das dicas? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin

Nenhum comentário »

Categorias deste post

Daily Meeting, Scrum