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.