FCamara Techday 2014

Obs.: Apenas para colaboradores FCamara

[]s

Abu

O lado negro da força por Thiago Torricelly

Bom dia amigos,

Segue o link de post do amigo Thiago Torricelly.

http://www.torricelly.com.br/2014/02/o-lado-negro-da-forca.html

Eu sempre estou no whatsapp respondendo a perguntas realizadas. Já virou até mesmo um modelo de negocio este tipo de suporte.

Torricelly pega uma parte destes bate papos e monta um post falando sobre Scrum e algumas lições aprendidas.

O melhor de tudo é a facilidade como Torricelly brinca com o texto e o filme "Star Wars"

Este post é muito forte no modelo de pensar e agir do Mestre Torricelly. Em suas palavras hoje, aprendi muitas lições.

Parabéns Torricelly e que a "força esteja sempre com você"

Abraços,

Abu

Adoção de Scrum em larga escala e um modelo de desenvolvimento e gestão ágil de projetos

Link da palestra do Patrão (Rogério Bauer)

http://www.infoq.com/br/presentations/adocao-scrum-larga-escola


[]s


Abu

Skills Necessários para Implementação do Produto

Como funciona:

1) Colocar os nomes dos integrantes da equipe

2) Colocar os títulos de perfil técnico necessário para entregar o produto

3) Para cada Profissional X Perfil Técnico colocar a informação "Expert", "Ajuda", "Não"

4) A cada sprint pedir para a equipe fazer o plano de trabalho que permita as pessoas transitarem de conhecimento igual a "Não" para "Ajuda". De "Ajuda" para "Expert".

5) Visualização de riscos... Se um perfil técnico não possui mais de uma pessoa com o conhecimento "Expert" é um risco. No mínimo para cada coluna de perfil técnica temos que ter um "Expert" e "Ajuda"

Em gestão de projetos essa é a área de RH, onde devemos fazer o estudo de capacitação da equipe.

O segredo é termos o maior numero possível de pessoas ajudando a fazer de tudo, isso aumento a capacidade de produção da equipe.

Lembrando o nosso propósito como equipe é entregar o produto e não trabalhar em nossas atividades primarias contratadas.

Abraços,

Abu

Mitigação de Riscos em Ágil

Bom dia pessoal,


Segue um conjunto de pensamentos de como podemos mitigar os riscos em projetos ágeis.

A relação de riscos foi tirado do vídeo - http://www.youtube.com/watch?v=7lhnYbmovb4

Vamos a proposta....

Riscos

1) Business: Estamos construindo a coisa certa?

(Abu / Mitigação): Desenvolvimento direcionado a "Goal"
(Abu / Mitigação): Histórias X "Goal"
(Abu / Mitigação): KPI de redução de escopo por Sprint (Mike Cohn - 20%)
(Abu / Mitigação): Histórias com BV
(Abu / Mitigação): Gráfico de entrega de valor

2) Social: Essas pessoas conseguem desenvolver?

(Abu / Mitigação): Retrospectiva com "Action Points"

3) Técnico: Vai funcional na plataforma que queremos? Vai ser possível escalar?

(Abu / Mitigação): Plano e execução de testes o mais cedo possível
(Abu / Mitigação): Backlog gerando DDD (domain driven design)

4) Cost + Schedule: Vamos conseguir completar em um tempo e custo razoável?

(Abu / Mitigação): EVA (analise de valor agregado)
(Abu / Mitigação): Acompanhamento de velocidade, pontos entregues, pontos a fazer, etc
(Abu / Mitigação): Projeção de capacidade de entrega (Mike Cohn)

5) Redução de incertezas (Inception)

(Abu / Mitigação): Release Backlog
(Abu / Mitigação): Release Planning
(Abu / Mitigação): Release Backlog Estimado
(Abu / Mitigação): Grooming
(Abu / Mitigação): Framework do Scrum (Sprints)
(Abu / Mitigação): Feedback do PO


Exemplo de EVA

Projeção de capacidade de entrega (Mike Cohn)

DDD (domain driven design)

Desenvolvimento direcionado a "Goal"

Histórias com BV (Foco gerar gráfico de entrega de valor)

Abraços,


Abu

Backlog ou Product Backlog

Product Backlog é a relação de requisitos do produto a ser desenvolvido. Neste momento eu estou tomando como premissa que já foi realizado os trabalhos de criação do Backlog.

Um backlog deve ser organizado com os desejos do cliente de maior prioridade na parte de cima e os desejos do cliente de menor prioridade a baixo.

O backlog deve ter cada desejo estimado conforme o seu esforço, existem técnicas de Pontos de História, Dias Ideais, ou qualquer técnica de estimativa que a equipe ou empresa tenha desejo de utilizar.

 

Figura 1: Backlog organizado do mais importante a cima e menor importante a baixo, bem como o tamanho de esforço para fazer cada item do backlog

Uma técnica de medir a qualidade do backlog é a DEEP, que determina que um backlog possua um detalhamento apropriado dos desejos pelo Product Owner, que este detalhamento permita uma estimativa pela equipe, que exista a consciência de todos que o backlog não é estático e com isso pode ser mudado no decorrer do projeto e que ela seja priorizado para entregar valor de negocio ao nosso cliente.

Figura 2: Backlog DEEP

Figura 3: Exemplo de Backlog

O backlog não tem necessidade de ter todos os seus desejos especificados para o inicio do desenvolvimento. Um trabalho de especificar todos os desejos para depois iniciar o desenvolvimento de software vai promover um tempo muito grande, o que pode gerar desperdício pelas mudanças de desejo ou mudanças de interpretação dos desejos.

Figura 4: Backlog e Sprints

Devemos ter um detalhamento dos desejos apenas referente a sprint que vai ser desenvolvida ou algumas sprints a mais. Conforme o desenvolvimento vai sendo realizado, mais detalhamento dos desejos são realizados em paralelo, mantendo a distancia de tempo entre o detalhamento do desejo do cliente e a entrada para a equipe de desenvolvimento sempre curta.

Figura 5: Desenvolvimento do Time e Detalhamento dos Desejos em Paralelo

 

 

Figura 6: Não detalhe todos os desejos do projeto, apenas os que vão ser desenvolvidos

Nem sempre todas as pessoas conseguem ter uma visão do backlog organizado em uma planilha. Para isso podemos utilizar o conceito de FBS (Feature Breakdown Structure), onde podemos mostrar graficamente os desejos nos seus tamanhos e decomposições.

Figura 7: FBS

Conclusão

Ter um backlog vivo onde desejos podem entrar ou sair a qualquer momento, mesmo nos últimos momentos do projeto, não é fácil de ser aceito para quem esta iniciando em metodologias ágeis. Também não é fácil quebrar o paradigma de especificar, isso é, entender todos os desejos do cliente, deixando o detalhamento próximo da etapa de desenvolvimento de software.

Esses paradigmas são difíceis de ser quebrados, mas eles são possíveis pela mudança cultural que é a entrada do Product Owner no projeto. Devemos lembrar que ele é o responsável pela definição de desejos que permita o projeto ser bem sucedido ou não com relação ao seu retorno de investimento (ROI).

Cabe a responsabilidade dele, Product Owner, junto com a equipe ter a visão de grandeza do que é possível ser feito ou não de desejos conforme o tempo que o projeto possui.

O Product Owner é o único que pode autorizar o desenvolvimento de um desejo e ter a sua presença no projeto de maneira comprometida é um dos segredos de sucesso das técnicas ágeis.

Abraços,

Abu

Este post faz parte do material "Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"

Alinhamento: Como podemos sincronizar o trabalho de uma empresa?

Como podemos sincronizar o trabalho de uma empresa?

Uma maneira muito simples, com uma agenda de trabalho que tenha este foco. Lembrando... não são todas as pessoas que possuem em seu modelo de trabalho uma visão planejada. Para essas pessoas nos temos que ajudar a adquirir este habito.

Post do amigo Fabio Sanches - http://fllsanches.blogspot.com.br/2014/02/alinhamento-de-projetos.html

Algo simples mas que traz um "baita" impacto no dia a dia das empresas.

Parabéns Fabio.

Requisitos: Tudo é Requisitos

Tudo é Requisitos

Por Nelson Abu Samra Rahal Junior

Linha de Raciocínio

1 – Do presidente ao desenvolvedor

A língua comum entre todas de uma empresa que possui seus produtos baseados em software são os REQUISITOS.

2 – Glossários

Roadmap, Histórias, Épicos, Temas e outros nomes representam a mesma essência, um REQUISITO.

3 – Tamanhos

Cada glossário nada mais é que uma forma de representar o tamanho de um REQUISITO.

4 – Qualidade

A qualidade da informação que entra em uma equipe de desenvolvimento de software traz impacto direto a produtividade da Equipe.

5 – Imagem para Reflexão

Abraços a todos,

Abu

Este post faz parte do material "Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"

Kanban para Visão, Planejamento e Execução de Roadmap's

Boa tarde pessoal,


Segue algumas fotos de como estou planejando organizar e acompanhar alguns itens de Roadmap.

Um produto pode ter varias iniciativas de melhorias (ideias) e cada ideia autorizada a sua implementação deve ser gerenciada como um projeto.

Organização por quadrantes Q1, Q2, Q3 e Q4 (Trimestres)





Exemplo de Q1

Perguntas a serem tratadas no modelo a ser desenvolvido

Visão do protótipo

Material que deu origem ao protótipo. É uns dos melhores livros de ágil que tive a oportunidade de ler.

Exemplo de estrutura de requisitos. Do planejamento estratégico de uma empresa até tarefas

O texto não é de leitura divertida, mas tenho certeza que vc's vão gostar do que esta sendo proposto. Principalmente seus gestores :)

Abraços a todos,

Abu

Adotando o nosso DNA Ágil

Bom dia pessoal,

Hoje um grande amigo e mestre ágil lembrou-me do nosso propósito na empresa que estamos e desejo compartilhar com vocês.

Nosso bate papo iniciou com essas palavras:

(Mestre Ágil) Abu qual o nosso foco?

(Abu) Adotarmos o modelo ágil na empresa

(Mestre Ágil) Implantar ou adotar?

(Abu) Adotar, não se implanta ágil, se adota ágil

(Mestre Ágil) Para que desejamos ser mais ágeis?

(Abu) Para entregarmos mais valor, obtermos mais resultados

(Mestre Ágil) Nos queremos ser FDD, Scrum, XP?

(Abu) Não, queremos apenas sermos mais ágeis, essas técnicas nos ajudam ser mais ágeis

(Mestre Ágil) Nosso foco não é implantar Scrum?

(Abu) Não, nosso foco é ser mais ágil para gerar mais valor aos nossos clientes, Scrum é apenas uma forma de sermos mais ágeis

(Mestre Ágil) Abu então qual o nosso foco?

(Abu) Termos nossa identidade, nosso DNA ágil, nosso modo de jogar o jogo, que permita sermos cada vez mais ágil

O mestre ágil de hoje foi o meu amigo Rogerio Bauer,

Abraços,

Abu

Nosso Foco é ser mais Ágil

Por Nelson Abu Samra Rahal Junior

Linha de Raciocínio

1 – Pilares do Processo Empírico do Scrum

Transparência

Inspeção

Adaptação

2 – Princípios Ágeis

1 - Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor.

2 - Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas.

3 - Entregar software funcionando com freqüencia, na escala de semanas até meses, com preferência aos períodos mais curtos.

4 - Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.

5 - Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

6 - O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.

7 - Software funcional é a medida primária de progresso.

8 - Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

9 - Contínua atenção à excelência técnica e bom design, aumenta a agilidade.

10 - Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.

11 - As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.

12 - Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo.

3 – Processos e Atividades devem ser Dirigidas por Princípios

“Princípios sem práticas são conchas vazias. Práticas sem princípios tendem a ser implementadas pelo hábito, sem o mínimo julgamento. Os princípios guiam as práticas. As práticas representam os princípios" - Jim Highsmith

4 – Jornada

“Scrum é um dos meios de sermos mais ágeis” – frase constantemente utilizada pelo amigo Thyago Rebelato.

Use os pilares do Scrum para poder alcançar os princípios ágeis.

5 – Conclusão

Todas as nossas decisões devem ser direcionadas pelos princípios.

Em todos os debates, conflitos, problemas, etc, qual a nossa ação? Ela esta aderente ao princípios que desejamos?

“Se não sabemos onde desejamos chegar, qualquer caminho serve” - Lewis Carroll em Alice no País das Maravilhas.

Abraços a todos,

Abu

Este post faz parte do material "Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"

Cartão de História + BDD

Cartão de Histórias

Por Nelson Abu Samra Rahal Junior

Linha de Raciocínio

1 – Especificação

Montar uma especificação que esteja na língua do desenvolvedor de software

2 – Automação

Texto direcionado para automação de testes

3 – Desenvolvimento Lean

Desenvolvedor não cria funcionalidades, ele desenvolve apenas as funcionalidades que foram acordadas com o Product Owner - “Fazer menos para fazer mais”

4 – História de Usuários

Tem o objetivo de promover um dialogo, isto é, conversa. Todas as conversas expressão algum tipo de funcionalidade, seja de regra de negocio, comportamento de software, requisito não funcional, etc.

5 – Cartão de História

São 3C's

- Cartão

- Conversa

- Confirmação

Que podemos representar pela História, Conversa que gera os Critérios de Aceite e a confirmação de como essas conversas (Critérios de Aceite) estão corretos.

6 – O Desenvolvedor de Software

Mostre este material a equipe de desenvolvimento, se eles expressarem desejo a este tipo de especificação, não tem negociação, faça.

Exemplo 01 – Funcionalidade de Status

História: Como usuário de rede social desejo postar um novo status, para que meus amigos possam ver

Critérios de Aceite:

1 – Entrar com o pensamento

2 – Publicar o pensamento

3 – Todos os amigos visualizarem meu pensamento

BDD

Critério de Aceite - 1

Cenário 1 – Entrar com o pensamento

Dado que eu chame o site https://www.facebook.com/

Quando o site é apresentado

Então eu devo visualizar a opção de Status

Cenário 1 – Digitar o pensamento

Dado que eu esteja no site https://www.facebook.com/

Quando eu clico na caixa de texto de Status

Então eu devo visualizar uma caixa de texto com a informação “No que você esta pensando?”

E o botão “Publicar”

E a opção de “Amigos”

E a opção “Marcar pessoas em sua publicação”

E a opção “Adicionar um local a sua publicação”

E a opção “Selecione um arquivo para enviar”

E a opção “Diga o que você esta pensando”

Critério de Aceite - 2

Cenário 1 – Publicar o Pensamento

Dado que eu entre no status com a informação “Bom dia”

Quando pressiono Publicar

Então eu devo visualizar “Bom dia” no meu “Feed de Noticias”

Cenário 2 – Publicar o Pensamento Vazio

Dado que eu entre no status com a informação “”

Quando pressiono Publicar

Então nada deve ser publicado no meu “Feed de Noticias”

Critério de Aceite - 3

Cenário 1 – Todos os amigos visualizarem meu pensamento

Dado que eu estejá no site https://www.facebook.com/

E Logado

E sou amigo de Nelson Abu Samra Rahal Junior

E que Nelson Abu Samra Rahal Junior entre no status com a informação “Bom dia”

Quando Nelson Abu Samra Rahal Junior pressiono Publicar

Então eu devo visualizar “Bom dia” no meu “Feed de Noticias”

Cenário 2 – Todos os amigos NÃO visualizarem meu pensamento vazio

Dado que eu estejá no site https://www.facebook.com/

E Logado

E sou amigo de Nelson Abu Samra Rahal Junior

E que Nelson Abu Samra Rahal Junior entre no status com a informação “”

Quando Nelson Abu Samra Rahal Junior pressiono Publicar

Então nada deve ser publicado no meu “Feed de Noticias” 

Exemplo 02 – Autenticação de Usuários

História: Como um usuário de redes sociais desejo me autenticar no sistema, para que eu possa utilizar

Critérios de Aceite:

1 – Validar o usuário

BDD

Critério de Aceite - 1

Cenário 1 – Dados de usuário errados

Dados que eu entre com e-mail ou telefone igual a “Jose da Silva”

E senha igual a “1234”

Quando pressiono Entrar

Então eu devo ver a mensagem de erro “Dados inválidos”

Cenário 2 – Dados de usuário vazio

Dados que eu entre com e-mail ou telefone igual a “”

E senha igual a “”

Quando pressiono Entrar

Então eu devo ver a mensagem de erro “Dados inválidos”

Cenário 3 – Dados de usuário correto

Dados que eu entre com e-mail ou telefone igual a “abuzitos”

E senha igual a “1234”

Quando pressiono Entrar

Então eu devo ver a tela principal do facebook

Cenário 4 – Dados de usuário parcialmente correto

Dados que eu entre com e-mail ou telefone igual a “abuzitos”

E senha igual a “”

Ou senha igual a “xpto”

Então eu devo ver a mensagem de erro “Dados inválidos”

Então eu devo ver a tela principal do facebook

Exemplo 03 – Busca

Histórias:

a) Como um usuário de redes sociais desejo buscar pessoas, para que eu possa iniciar uma amizade

b) Como um usuário de redes sociais desejo buscar locais, para que eu possa curtir

c) Como um usuário de redes sociais desejo buscar coisas, para que eu possa curtir

 

Critérios de Aceite:

1 – Digitar informação de busca e visualizar resultados

BDD

Critério de Aceite - 1

Cenário 1 – Busca informação vazio

Dado que eu digite em busca “”

Quando pressiono Enter ou Botão de Busca

Então eu devo visualizar a pagina de “Todos os Resultados”

E a mensagem “Por favor introduza uma consulta na caixa acima.”

Cenário 2 – Busca informação existente

Dado que eu digite em busca “Abu Samra Rahal”

Quando termino de digitar

Então eu devo ver as informações “Nelson Abu Samra Rahal Junior”

E “Marjury Abu Samra Rahal”

E “Neilza Andrea Abu Samra Rahal”

Cenário 3 – Busca informação inexistente

Dado que eu digite em busca “xpto1234”

Quando termino de digitar

Então eu devo ver a informação “Ver resultados para XPTO”

E “Exibindo os 0 principais resultados”

Muito obrigado e abraços a todos,

Abu

Este post faz parte do material "Pensamentos Ágeis: Uma Coletânea de ideias de como penso sobre Ágil"

Kanban para a área Comercial por Fábio Sanches

Kanban para a área Comercial.

Post do amigo Fabio Sanches - http://fllsanches.blogspot.com.br/2014/02/kanban-para-equipe-comercial.html

Abraços a todos,

Abu

Roadmap no TFS por Fábio Sanches

Roadmap no TFS

http://fllsanches.blogspot.com.br/2014/02/road-map-no-team-foundation-service.html

Parabéns Fabio Sanches

Abraços a todos,

Abu

E.T.C Entidade de Transição Corporativa por Fábio Sanches

E.T.C Entidade de Transição Corporativa - http://fllsanches.blogspot.com.br/2014/02/entidade-de-transicao-corporativa.html

Mudando a cultura da empresa para ágil. Um post do amigo Fabio Sanches

Abraços,

Abu

Kanban para a área de TI por Fábio Sanches

Kanban para a área de TI. Post do amigo Fábio Sanches, http://fllsanches.blogspot.com.br/2014/02/kanban-de-ti.html?m=1 Abraços, Abu

Desafios da transição de organizações para Agile por Thiago Torricelly

Um belo post do amigo Thiago Torricelly referente aos desafios da transição de organizações para Agile

http://www.torricelly.com.br/2014/02/o-desafio.html