Mais um ano se encerrou, fizemos uma cerimônia de Retrospectiva, seguindo o roteiro da “Sprint Retrospective“.
Nossos projetos podem durar mais de 6 meses, fazemos inicialmente um planejamento de números de sprints que poderão acontecer dentro do semestre, para planejamento financeiro e acompanhamento de acuracidade.
Um projeto pode conter mais que 8 sprints, dependendo da sua complexidade e da re-estimativa no decorrer do mesmo. Porém para efeito contábil, fazemos uma pausa no final do semestre com o número de sprints que ocorreram.
No final do último sprint do projeto, fizemos a cerimônia de Retrospectiva do período que durou 8 sprints.
Eventos Significantes
Colocamos os “post-it” dos 6 meses do decorrer do projeto e após os 5 minutos de escrita individual nos post-its começamos a escutar o que cada um tinha a dizer sobre os marcos do semestre. Bastante interessante, pois tinha desde eventos desagradáveis como acidentes, furtos (que marcam de certa forma) até eventos como entregas, lazer, conquistas.
Nesse momento, todos nós temos a oportunidade de “ver” os colegas como pessoas que têm seus anseios, suas prioridades e suas considerações sobre o que foi importante ou não. A gente pode saber o que o colega acha importante e pode também mostrar o que achamos importante e signifcativo para o projeto.
O que foi bem?
Nesse momento, após o timebox de 5 minutos, é bom receber as mensagens de membros da equipe sobre o que eles consideraram sucesso no projeto, fruto de alinhamento feito por eles no decorrer do projeto, através da integração e análises críticas que aconteceram no final de cada sprint e que como resultado pôde melhorar algo no processo.
A lista do que foi bem foi signifcativa, portanto houve resultado visualizado pela equipe durante o semestre e o ano que passou.
O que poderia melhorar (equipe x organização)?
Considerações finais sobre pontos fracos da equipe e pontos relevantes que poderiam influenciar no trabalho deles, se resolvido pela organização (externo ao time).
Uma coisa interessante no time é que eles colocaram muito mais itens a melhorar deles do que da organização. Isso não significa que a organização está perfeita não! Porque em todos as empresas sempre há algo a melhorar, mas o que pude notar é o nível de maturidade da equipe em amenizar a influência de problemas organizacionais e focar na melhoria do processo, do conhecimento, do entrosamento, do framework, dos trabalhos do PO e outras coisas.
Todo mês nossa equipe faz uma reunião à parte para acompanhar a evolução dos ítens levantados na retrospectiva. Precisamos tomar cuidado para que a retrospectiva, seja do sprint ou do projeto, não caia na descrença. Por isso é muito importante o Scrum Master tentar resolver o que consegue e escalar para níveis acima o que pode ser melhorado.
Não se consegue resolver tudo, por isso em função do ranking de prioridades, se aplicarmos a regra de pareto pra tentar resolver os problemas conseguiremos atender às exigências da equipe, melhorando assim os trabalhos e tendo mais produtividade no desenvolvimento do produto.
Work-centered Analysis
Se observarmos o gráfico acima de WCA (Work-centered Analysis) é o fundamento da reunião de análise crítica do processo ou Retrospectiva. Identificamos um problema, atribuimos uma classe (pessoas/equipe ou organização), pensamos na relação entre as partes para que haja uma possível solução para esse referido problema.
Muitas vezes sabemos que há problemas com soluções a longo prazo, nem por isso devemos ignorá-lo. Ao contrário, deve sempre ser relatado para ficar registrado desde o início, desde que ele atrapalhe de certa forma ou venha a atrapalhar o desempenho da equipe.
Não deixe de fazer no final de todos os sprints uma reunião de retrospectiva do projeto. É muito importante pra saber realmente as “lessons-learned”.
Os 3 pilares de sucesso de um produto
21 Dec
Carlos Santos Engenharia, Engenharia de Produção, Indústria
Qualquer produto para ter sucesso no mercado depende do esforço empregado por várias áreas da empresa, desde atividades mais simples, que agregam menos valor até atividades com maior grau de responsabilidade e risco.
Gostaria de enfatizar neste artigo três pontos que acho de extrema importância para o sucesso de um produto no mercado:
- Projeto
- Material
- Processo.
Projeto
Qualquer produto, seja de consumo eletrônico, software, eletrodoméstico, precisa de um bom projeto. A equipe de projeto idealiza todas as etapas de construção do produto passando por “análise”, “design”, “implementação ou execução” e “testes”. Todas as possíveis falhas devem ser pensadas a fim de evitar retrabalho ou até mesmo um “recall” na etapa pós-vendas.
Material
Muitas empresas falham por ter um bom projeto mas escolhem matéria-prima de baixa qualidade para compor o produto. Se em busca de maior lucro a empresa não tiver um bom “procurement” focado na qualidade de materiais, será em vão todo o trabalho de “engenharia”, pois com certeza teremos problemas na produção ou até mesmo no mercado.
Processo
Um boa empresa, preza por ter um bom processo fabril, com equipamentos de qualidade, equipe bem treinada e com bom conhecimento nos processos e métodos de fabricação do produto. Uma empresa fraca em seu processo fabril, certamente deixará passar ao consumidor produtos com falhas, pois é normal encontrarmos falhas durante a etapa de fabricação do produto. Quem investe em máquinas e esquece das pessoas que manejam com as mesmas, cai na mesma falha que não investir numa boa planta fabril.
Esses três pilares funcionam em conjunto para que seja possível o sucesso de um produto no mercado. Se for bem projetado, mas utilizar materiais de baixa qualidade, com certeza teremos baixa qualidade no mercado. Se for bem projetado, tiver boa matéria-prima porém um processo falho, também resultará em problemas junto ao consumidor. Essa tríade: projeto, material e processo funciona como três lâmpadas em série, todas elas precisam funcionar para que permaneçam acesas, se uma delas falhar, causará falha geral no mercado.
Os 3 Poderes da Indústria
09 Nov
Carlos Santos Engenharia, Engenharia de Produção, Indústria, Projetos
Para quem trabalha em indústria o é muito interessante a analogia que será feita a seguir.
Os Três Poderes da Indústria
Primeiro vamos começar com uma indústria que possui seus departamentos “chaves” comparados aos três poderes do Estado. Tal qual no Brasil temos o Executivo, Legislativo e Judiciário podemos atribuir as mesmas responsabilidades desses poderes a áreas de uma indústria.
Legislativo - esse poder na indústria é representado pela Engenharia. A Engenharia, seja de desenvolvimento, de produtos, de processo, de fábrica ou industrial (quaisquer desses tipos) é responsável por definir padrões, especificações o que podemos comparar à criação das “leis”. Baseado nessas “leis” que a fábrica segue as regras para poder produzir seus produtos. Ela elabora os pedrões e especificações.
Executivo - esse poder na indústria é representado pela Produção. A Produção executa a fabricação dos produtos de acordo com as regras definidas pela Engenharia. Quando algo não está bem especificado pela Engenharia, então começam acontecer os problemas, defeitos, rejeitos, que irão influenciar no resultado da qualidade do produto. Essas “leis” da Engenharia que são executadas pela Produção podem estar relacionadas tanto ao produto quanto ao processo.
Judiciário - esse poder na indústria é representado pela Qualidade. A área de Qualidade julga o bom processo, bom produto e sua permanência de qualidade no mercado, ou seja, confiabilidade. Essa área deve ser independente hierarquicamente da Produção ou da Engenharia para ter autonomia em bloquear saída de produtos para o mercado que não estejam de acordo com as “leis” (normas) do processo ou “leis” (especificações) técnicas elaboradas pela Engenharia.
Existem outras áreas importantes na indústria, porém esses três poderes mencionados anteriormente, se forem bem “empoderados” pelos donos das indústrias e bem representados por profissionais que “briguem” por essas responsabilidades de forma independente, farão toda a diferença no sucesso de uma empresa.
Você concorda com a analogia aos três poderes? Por isso que existe tanta “briga” saudável numa fábrica…
Nos últimos anos observei a transição de entendimento sobre o Scrum Master (SM) e ao mesmo tempo preconceito com esse papel.
No início todos queriam ser SM porque era novidade, o nome é bonito e talvez fosse alguma coisa melhor que Gerente de Projetos (GP), depois banalizou o SM e achavam que era um papel burocrático ou fazedor de documento e convocador de reuniões. Todos então queriam ser um Product Owner (PO)!
As pessoas da área de projetos, por ignorância ou por vaidade, se preocupam muito com títulos, mesmo que seja em papéis ou certificados e esquecem de fazer o básico: bom trabalho para ter reconhecimento e sucesso.
Mas o que se espera de um Scrum Master?
Para mim, que já atuei como GP, SM e PO está bem claro o papel de cada um. No Scrum não existe GP ou Líder de Projetos (LP)! Só existem SM, PO e Scrum Team (ST).
O Scrum veio pra dividir o papel do GP em duas partes: gerente de pessoas e gerente de produto.
Pela minha experiência, mesmo que tivesse um projeto com uma equipe de 5 pessoas, 1 Scrum Master e 1 Product Owner bem definido, mesmo que esses 2 líderes custassem caro valeria a pena. O Gerente de Projetos tem que ser um iluminado que advinha tudo, define o escopo, requisitos, documentação, cuida das pessoas, orçamento, treinamento, impedimentos, simplesmente tudo! Ele não consegue na maioria das vezes fazer tudo isso e ainda mais se sobrecarregando com projetos que rodam em tempos fixos com entregas marcadas pra determinadas datas. Mas o objetivo desse artigo não é falar sobre o GP. Queria falar especificamente sobre o que espero do Scrum Master.
Hoje sai procurando uma pessoa pelos corredores que tivesse o seguinte perfil: maturidade, experiência, respeito, comprometimento, atitude, liderança e contei nos dedos de uma mão algumas pessoas que poderiam me ajudar na equipe que temos. Essa pessoa teria que conquistar o respeito e confiança da equipe, resolver os problemas levantados diariamente, se preocupar com questões como: viagens de trabalho, aquisições de material de consumo, controle de banco de horas ou hora-extra, verificação de necessidade de aquisição de livros ou assinaturas, disparo de compra de equipamentos ou programas de computador (quando necessário), disparo de solicitações de treinamentos (identificados para o projeto), conduzir reuniões, ajudar os colegas, interagir com o Product Owner, defender o time e também dar uma dura quando for preciso.Quem é esse cara? Muitos responderiam: “é o gerente de projetos” ou outros “é o gerente de linha”. Errado! Esse cara é o Scrum Master!
Os preconceituosos acham que o Scrum Master só resolve impedimento em post-it, marca reunião e chama pro Daily meeting quando a turma esquece do horário, mas não é apenas isso! Aliás não é exatamente isso!
O Scrum Master é um líder de pessoas que mantém o processo funcionando perfeitamente de acordo com as regras do framework. Para um programa ele atua com esse lado do gerente de projetos e/ou do gerente de linha.
O outro lado técnico, de negociação e outros atributos que um gerente de projetos possui, é assumido pelo Product Owner, que também é um líder, com iniciativa, articulado, boa comunicação escrita e verbal, jogo de cintura, honesto, justo, focado no negócio e produto.
Não é difícil ter todos esses atributos em uma pessoa só e ainda ter que entregar produto no tempo certo com bom, custo, qualidade e satisfação do cliente?
Então por que as pessoas querem ser apenas gerente de projetos, rodar um Scrumbutt e ainda achar que Scrum Master é um babysitter do time? Será que tem algo errado? Será que tem Scrum Master? Será que tem Mindset?
Podemos encontrar vários livros de educação financeira e todos eles são unânimes que precisamos multiplicar nossos ganhos através de bons investimentos e prazos.
Quando a gente começa a trabalhar jovem e alguém fala:
- “você já pensou em fazer um plano de providência?” ou
- “você já pensou alguma vez como será sua vida financeira ao se aposentar?” ou
- “você guarda algum dinheiro para o futuro?”.
Respostas imediatas:
- “não está na época de me preocupar com isso, ainda sou muito novo” ou
- “esse negócio de aposentadoria é pra velho!” ou
- “tenho é que curtir a vida e depois a vida me leva…”
Mas se formos um pouco mais críticos com relação à essas perguntas podemos buscar a mensagem transmitida como: curtir a vida, porém se preparando pra curtir ela melhor quando ficarmos mais maduros.
Dos 20 aos 30 a vida é muita balada, muita resistência pra beber, dançar, noitadas, etc.
Dos 30 aos 40 a gente começa a diminuir a velocidade e procurar alguma coisa. E também começa a ganhar um pouco mais de dinheiro.
Dos 40 aos 50 a gente pensa: “puxa, por que eu não tinha essa cabeça naquela época dos 30 anos?!”
Nossa vida útil começa lá pelos 20 a 25 anos. Aproveitamos bastante e quando chegamos na meia-idade ainda podemos perceber que nos falta mais uns 20 anos de vida útil caso nos cuidemos bem! Já vi muita gente que chega inteiro (lúcido, boa saúde) aos 60 anos e diz e agora? Vou depender dos meus filhos? Da aposentadoria?
No Brasil quando a gente se aposenta próximo dos 65 anos consegue no máximo R$3.000 por mês! Alguns poucos anos antes disso e cai pela metade esse salário de aposentadoria..
Levantei uma tabela de quanto uma pessoa precisa poupar mensalmente a uma determinada taxa de juros mensais durante um tempo para poder chegar no seu 1 milhão de dinheiro.
Para que serve chegar nesse 1 milhão?
- Para ter uma renda passiva ente R$5.000 a R$10.000 por mês ou
- para multiplicar mais ainda esse valor e investir em negócios, ou
- para aproveitar o resto de vida útil que lhe resta..
- Existem várias respostas de acordo com a necessidade de cada um.
- Só não é interessante pedir dinheiro dos filhos ou netos para comprar um remédio ou tomar um café!
| Juros (am) | 10 anos | 15 anos | 20 anos | 25 anos | 30 anos | 35 anos | 40 anos |
| 0.30% | 6,914.76 | 4,185.48 | 2,842.59 | 2,053.87 | 1,541.83 | 1,187.49 | 931.32 |
| 0.35% | 6,696.40 | 3,983.56 | 2,656.41 | 1,882.83 | 1,385.32 | 1,044.85 | 801.82 |
| 0.40% | 6,483.13 | 3,788.99 | 2,479.66 | 1,723.08 | 1,241.69 | 916.38 | 687.51 |
| 0.45% | 6,274.91 | 3,601.66 | 2,312.11 | 1,574.22 | 1,110.31 | 801.21 | 587.19 |
| 0.50% | 6,071.69 | 3,421.46 | 2,153.54 | 1,435.83 | 990.55 | 698.41 | 499.64 |
| 0.55% | 5,873.44 | 3,248.28 | 2,003.70 | 1,307.50 | 881.74 | 607.04 | 423.62 |
| 0.60% | 5,680.11 | 3,081.98 | 1,862.32 | 1,188.75 | 783.18 | 526.16 | 357.96 |
| 0.65% | 5,491.64 | 2,922.42 | 1,729.12 | 1,079.13 | 694.19 | 454.85 | 301.51 |
| 0.70% | 5,307.99 | 2,769.48 | 1,603.82 | 978.15 | 614.08 | 392.22 | 253.20 |
| 0.75% | 5,129.11 | 2,622.99 | 1,486.11 | 885.32 | 542.16 | 337.40 | 212.02 |
| 0.80% | 4,954.93 | 2,482.81 | 1,375.70 | 800.18 | 477.78 | 289.58 | 177.08 |
| 0.85% | 4,785.40 | 2,348.77 | 1,272.28 | 722.23 | 420.29 | 248.00 | 147.52 |
| 0.90% | 4,620.45 | 2,220.71 | 1,175.54 | 651.02 | 369.10 | 211.96 | 122.61 |
| 0.95% | 4,460.02 | 2,098.47 | 1,085.17 | 586.08 | 323.61 | 180.81 | 101.68 |
| 1.00% | 4,304.05 | 1,981.86 | 1,000.85 | 526.97 | 283.29 | 153.96 | 84.16 |
| 1.05% | 4,152.47 | 1,870.73 | 922.29 | 473.26 | 247.63 | 130.87 | 69.52 |
| 1.10% | 4,005.21 | 1,764.89 | 849.18 | 424.54 | 216.16 | 111.06 | 57.33 |
| 1.15% | 3,862.20 | 1,664.18 | 781.23 | 380.42 | 188.43 | 94.11 | 47.20 |
Vamos analisar juntos:
- Quem aplica na poupança (0.5% ao mês) precisa juntar durante 30 anos todo mês a quantia de R$990,55 para conseguir chegar a 1 milhão!
- Se o cára abre os olhos com 40 anos de idade, precisará juntar R$2.153,54 por mês pra completar 1 milhão. Porém observe que a caderneta de poupança te dá somente isso!
Essa mesma pessoa que consegue boas taxas (exemplo 0.90% ao mês)
- Ao invés de aplicar R$990,55 durante 30 anos, precisaria juntar mensalmente R$369,10!
- Ao invés de aplicar R$2.153,54 durante 20 anos, precisaria juntar mensalmente R$1.175,54!
- Uma pessoa pra juntar dinheiro durante 30 anos teria que começar a investir no mais tardar aos 30 anos de idade.
- Uma pessoa pra juntar dinheiro durante 20 anos teria que começar a investir no mais tardar aos 40 anos de idade.
Ou seja, nunca é tarde, porém o tempo é cruel!
Uma pessoa de 50 anos terá que se sacrificar muito mais! E ainda tem um agravante: a curva de salários ao longo de nossa vida. No Brasil, começa pequena entre os 20 e 30 anos, aumenta entre os 30 a 50 anos e depois tende a diminuir quando chega próximo dos 60 anos. É a senóide salarial…
Tá na hora de correr!!! Procurar economizar, juntar dinheiro, conseguir boas taxas e depois desfrutar… Você já pensou nisso?
Ou seja apesar do investimento previsto na lei ser mais abrangente o que sobra para investir, na prática, é o Nordeste.
A divisão das obrigações de investimentos é assim (usando como exemplo o monitor em São Paulo):
- Total 4% (percentual específico para monitor LCD para SP)
- Interno: 2,16%
- Externo: 1,84%
E o investimento externo se quebra no seguinte:
- Em qualquer lugar: 0,8%
- No Nordeste: 0,64% (0,19% em Instituições oficiais // 0,45 % em instituições não oficiais)
- FNDCT (“fundão”): 0,4%
- TOTAL : 1,84%
Prazo para gastar a verba:
Pela lei tem que gastar dentro do ano.
Existe uma tolerância que o gasto do ano pode ser feito até março do ano seguinte.
Por exemplo, o que foi gasto até março de 2009 pode ser considerado (se quiser) como gasto de 2008.
Mas existe jurisprudência de negociar verbas anteriores acumuladas, porém isso tem que ser negociado com a Suframa, ou seja, cada caso é específico para ser tratado de acordo com a lei interpretada pela representação do MCT e através da Suframa.
Se a empresa resolver montar um Instituto de Pesquisa & Desenvolvimento, ela pode de imediato dispensar alguma verba ( já de P&D) para Consultoria, abertura de instituto, aluguel de uma planta em Manaus, instalações prediais, compra de móveis e equipamentos, etc ? (antes de legalmente estar funcionando?)
É bom lembrar que a prestação de contas para a Suframa é feita através do relatório anual de P&D, e sempre a posteriori.
Ou seja, vamos dizer que a empresa fez todo esse investimento em 2009. Essa “prestação de contas” só vai ser feita no ano seguinte, normalmente até abril de 2010. No relatório anual, que é sempre relatado em termos de “projetos de P&D” isso pode ser lançado como projeto “Implantação do Instituto de Pesquisas”.
Em outras palavras: ninguém precisa pedir autorização prévia da Suframa para fazer o investimento, em compensação só depois da Suframa analisar o relatório é que ela vai dizer se glosa ou aceita o investimento.
A premissa básica para fazer qualquer investimento em P&D em Manaus, utilizando verbas de P&D de bens de informática geradas localmente, é estar aprovado no CAPDA, e esse processo leva alguns meses.
O Instituto de Pesquisa é uma outra empresa com CNPJ diferente e “sem fins lucrativos” (não é LTDA).
Essas perguntas e respostas que resolvi postar é para ajudar a quem tem dúvidas na hora de implantar ou de saber como manter regulamentado um Instituto legalmente perante o governo. Não é para banalizar e qualquer um sair montando um centro de P&D, pois requer alto investimento, é uma decisão muito séria e comprometimento com a sociedade e com o governo.
Encontrei no blog do Jeff Sutherland e resolvi traduzir pra contribuir com as pessoas que queiram saber mais acerca desse importante checklist.
Em 2005, Bas Vodde (CST) estava fazendo coaching em equipes na Nokia Networks na Finlândia e então desenvolveu o primeiro Teste Nokia focado nas práticas Ágeis. Ele tinha centenas de times e queria uma forma simples de determinar se cada time estava fazendo o básico.
O teste Nokia é parecido com uma verificação rotineira de manutenção do seu carro. Como verificar se seu pneu possui ar, seu tanque tem gasolina, válvulas estão boas, etc. Deve executar antes de “rodar” Scrum com seu time.
Não é o segredo da alta performance, porém é a primeira linha da receita para a alta performance.
Em 2007, Jeff Sutherland otimizou o Teste Nokia para Certificação Scrum e em 2008 desenvolveu um sistema de pontuação para o Teste Nokia. Em 2009 um quesito foi adicionado ao teste Nokia.
Cada pessoa do time pega uma folha de papel e pontua cada questão com nota de 1 a 10.
TESTE NOKIA:
1. Iterações
a) Não há iterações
b) Iterações maiores que 6 semanas
c) Iterações com durações variáveis e menor que 6 semanas
d) Iterações fixas com duração de 6 semanas
e) Iterações fixas com duração de 5 semanas
f) Iterações fixas com duração de 4 semanas ou menos
2. Testando dentro do Sprint
a) Nenhum membro de QA (Garantia da Qualidade) dedicado
b) Unit Tests
c) Features testados
d) Features testados assim que finalizados
e) Software passa sob testes de aceitação
f) Software é entregue
3. Especificação Ágil
a) Não há requisitos
b) Grandes documentos de requisitos
c) User Stories pobres
d) Bons requisitos
e) Boas User Stories
f) Somente o suficiente, especificações na hora necessária
g) Boas user stories amarradas com as especificações à medida que for preciso
4. Product Owner
a) Não tem Product Owner (PO)
b) PO que não entende Scrum
c) PO que atrapalha ou interrompe o time
d) PO não envolvido com o time
e) PO com Product Backlog claro estimado pelo time antes da reunião de Sprint Planning (PRONTO)
f) PO com roadmap de lançamento com datas baseado na velocidade do time
g) PO que motiva o time
5. Product Backlog
a) Não há Product Backlog (PB)
b) Múltiplos Product Backlogs
c) Product Backlog único
d) PB claramente especificado e priorizado por ROI antes do Sprint Planning (PRONTO)
e) Product Owner possui um release burndown com data(s) de lançamento(s) baseada(s) na velocidade
f) Product Owner consegue medir o ROI com base no faturamento real, custo por pontos por estórias ou outras métricas.
6. Estimativas
a) Product Backlog não está estimado
b) Estimativa não foi feita pelo time
c) Estimativa não foi feita com Planning Poker
d) Estimativa feita com Planning Poker pelo time
e) Erro de estimativa menor que 10%
7. Gráfico do Sprint Burndown
a) Não há burndown chart
b) Burndown chart não é atualizado pelo time
c) Burndown chart em horas/dias não considerando trabalho em progresso (burndown de tarefas parciais)
d) Burndown chart somente desce quando a tarefa é concluída (padrão TrackDone)
e) Burndown chart somente desce quando a estória é concluída
f) O time sabe sua velocidade
g) O release plan do Product Owner for baseado em velocidade conhecida.
8. Interrompimento (atrapalhamento, distúrbio) do Time
a) Gerente ou Líder de Projetos interrompe o trabalho do time
b) Product Owner interrompe o trabalho do time
c) Gerentes, Líderes de Projetos ou Líderes Técnicos dizem ao time o que fazer
d) Existe um Líder de Projetos e papéis do Scrum
e) Ninguém interrompe ou atrapalha o time e só existem papéis do Scrum
9. Time
a) Tarefas atribuídas para cada membro durante o Sprint Planning
b) Membros do time não possuem nenhum overlap em suas áreas de especialidade
c) Não há liderança emergente - um ou mias membros da equipe designados como com autorizade direcionada
d) O time não possui a competência necessária
e) O time se compromete coletivamente com o objetivo do sprint e backlog
f) Os membros do time lutam coletivamente contra os impedimentos durante o sprint
g) O time está num estado de hiperprodutividade
Resultado da pontuação:
- Questão 1: a=0, b=1, c=2, d=3, e=4, f=10
- Questão 2: a=0, b=1, c=5, d=7, e=8, f=10
- Questão 3: a=0, b=1, c=4, d=5, e=7, f=8, g=10
- Questão 4: a=0, b=1, c=2, d=2, e=5, f=8, g=10
- Questão 5: a=0, b=1, c=3, d=5, e=7, f=10
- Questão 6: a=0, b=1, c=5, d=8, e=10
- Questão 7: a=0, b=1, c=2, d=4, e=5, f=3, g=2
- Questão 8: a=0, b=1, c=3, d=5, e=10
- Questão 9: a=0, b=0, c=1, d=2, e=7, f=9, g=10
- Ao iniciar o treinamento CSM (Certified Scrum Master) a pontuação gira em torno de 4.0.
- No final das aulas de CSM, as pessoas acreditam que podem aumentar a nota para nota 6.0 ao final de um mês.
Se puder, deixe um feedback de como foi o seu resultado e bom trabalho!
Esse grupo é oficialmente reconhecido pela Scrum Alliance e parabenizo, pois começou muito bem!
O primeiro grupo de Scrum do Brasil, de São Paulo não teve tanta gente no primeiro encontro. Existem oficialmente grupos em São Paulo, Recife e Manaus.
Na abertura o Heitor Roriz informou que 48 pessoas já se inscreveram no grupo.
Para participar do grupo, basta enviar um email para o Grupo Scrum Amazonia (scrum-amazonia@yahoogroups.com).
Houve sorteio de Planning Pokers do INdT, Planning Pokers da FPF e de livros de Scrum.
A próxima edição do encontro Scrum Amazonia acontecerá em Lima no Peru, afinal a Amazônia é maior em área do que a Europa e não podemos esquecer que existe a parte internacional da mesma!
O Marco Mafra do INdT, fez a primeira palestra que mostrava o histórico do Scrum no Instituto, desde o primeiro insight até o nível de maturidade atingido atualmente. Comentou sobre a fase de investigação, treinamento de pessoas, definição de processo de desenvolvimento de projetos utilizando o framework, certificação ISO9001 e mostrou números estatísticos de utilização do Scrum no Instituto. Mais de 50% já aderiu ao framework!
A segunda palestra foi a minha contribuição. Nessa palestra foi mostrado na prática como está funcionando o processo de programa e projeto baseado em Scrum. Também foi explicado resumidamente a relação entre as camadas: de projeto, do framework e registros para certificação ISO9001. Foram mostradas cada uma das cerimônias como ocorrem e enfatizado que o TrueScrum são: pessoas, post-its e cerimônias.
Na terceira palestra o Paolo Ramos da Divus fez uma ótima apresentação mostrando como o Scrum está chegando em empresas do governo. Explicou sobre a necessidade dos gerentes, desenvolvedores trabalharem de forma mais efetiva, planejar melhor e fazer um acompanhamento do backlog para que realmente entregue os projetos em tempo. Foi relatado rapidamente um estudo de caso da AFEAM, porém o importante foi deixar a mensagem do interesse dos órgãos públicos adotarem o Scrum, tais como TRT, Prodam, etc.
Na quarta palestra o Alexandre Cruz da Fundação Paulo Feitoza (FPF) relatou um histórico de como o Scrum começou a ser praticado na Fundação, dificuldades, mudança de mindset até confirmar que eles estão empenhados em obter o sucesso de seus projetos utilizando o referido framework. Estão fazendo um grande projeto de sistema para hospitais do governo municipal e estadual utilizando o Scrum!
Fiquei surpreso positivamente em saber como o Scrum está bem evoluido na FPF, visto que começaram conosco no INdT há aproximadamente um ano atrás.. Sucesso!
Para mais detalhes das palestras visite o site do Scrum Amazônia ou entre no Grupo!
O contrato de sprint é algo novo que estou trabalhando e implementando no momento.
Fiz algumas pesquisas de como implementar um contrato de sprint que na realidade é um contrato com escopo variável.
Conversei com alguns especialistas em contratos como Artem Marchenko e Peter Stevens e redigi melhor essa proposta Ágil é claro. Tudo depende do “mindset” da empresa parceira. Tem que estar apta a rodar o projeto em Scrum… A seguir vou relatar um pouco da experiência com esse tipo de contrato.
Competição de Estimativas:
Em primeiro lugar o Product Owner precisa criar o Product Backlog para a primeira estimativa. Chamamos o candidato o prestador de serviços com seus desenvolvedores e fazemos uma Reunião de Estimativa do backlog. Essa reunião é uma excelente oportunidade para sentir segurança no domínio do assunto por parte dos desenvolvedores. Eles estimarão as user stories de acordo com a visão de complexidade que eles têm sobre o assunto. Você, como contratante, observa as discussões, questionamentos, etc. Depois que terminar essa reunião o PO tem um backlog estimado por uma equipe de desenvolvedores que sabem o que queremos deles e eles sabem o que terão pela frente. Podemos chamar outra empresa e fazer a mesma dinâmica. Teremos o segundo, terceiro, backlog estimados.
Velocidade do Sprint:
Ah, um pequeno detalhe: após a estimativa do backlog, perguntamos ao time quanto eles puxariam para o primeiro sprint (sem ver a pontuação)? Essa resposta será a referência inicial para calcular a velocidade deles.
Depois temos uma estimativa de número de sprints a ser executado. Pontos totais dividido pelo número de pontos puxados para o primeiro sprint.
Exemplo: total estimado do backlog 500 pontos. Estimado para puxar pro primeiro sprint 50 pontos, teremos numa primeira estimativa o trabalho medido para 10 sprints. Vamos supor que desde o início nós calculamos sprints de 10 dias úteis, então esse trabalho será realizado em 100 dias úteis, ou seja, 5 meses (sem muitos cálculos, considerando 1 mês =20 dias úteis).
Custo do Sprint:
Pergunto depois ao responsável da empresa pra me informar quanto custa um Sprint de N dias para um trabalho estimado a ser concluído em 10 sprints?
Ele vai fazer todos os cálculos de overhead, lucro, uso, etc. e vai dizer. Pode até fazer o cálculo da forma tradicional, mas chegará a um número. Exemplo: Sprint custa R$30.000. Faço a seguinte conta: R$30.000 x 10 sprints = R$300.000 será o custo estimado do projeto.
Make or Buy?
Faço os cálculos internamente para decidir se vale a pena fazer o trabalho externamente. Isso depende de uma série de fatores como recursos disponíveis, competências, tempo, carga de trabalho, etc.
Como eu comparo os preços? Tenho um indicador interno de histórico de projetos executados chamado de Man Month Rate (MMR) ou Custo Homem Mês que nada mais é todos os custos exceto investimentos e subcontratados dividido pelo número de efetivos e dividido pelo número de meses.
Exemplo: meu último projeto teve um custo operacional de R$1.000.000 realizado por 10 pessoas em 10 meses. Cálculo: R$1.000.000 / 10 pessoas / 10 meses = R$10.000 é o valor do meu MMR.
Agora, com posse desse dado, sabendo que minha equipe tem condições técnicas de realizar o projeto faço o seguinte cálculo: lembra dos 5 meses calculados anteriormente? Então agora internamente calculo R$10.000 * 10 pessoas * 5meses = R$500.000 o valor estimado pra fazer internamente. Quanto o fornecedor me cobrou? R$300.000. Esse valor está bom, é mais barato fazer fora (Buy).
Estabilização da Execução:
Agora após decidir quem executará o projeto, vamos pra a execução do contrato.
Será estimado inicialmente para finalizar daqui a 5 meses (com base em 10 sprints), pode acabar antes do tempo ou esticar um pouco mais, porém isso é o que tenho no momento.
Sprint1 e Sprint2 serão pagos ao fornecedor sem aplicar penalidades ou bônus. Valores fixos. Para fins de entrosamento, medir velocidade, resolver questões de infra, etc.
Penalidade Insucesso:
A partir do terceiro sprint, começo a aplicar as regras de bônus ou penalidade. No Sprint Planning o PO determina o objetivo esperado do sprint. No Sprint Review, ele confirma de esse objetivo (meta) foi atingido. Caso não tenha sido atingido, o pagamento desse sprint será debitado de um percentual penalidade, pagando apenas os custos do mesmo. Exemplo: penalidade de 20%, custo do sprint R$30.000, pagarei R$24.000 (R$30.000 – R$6.000)
Penalidade/Bônus Progresso:
Caso o objetivo do sprint tenha sido atingido, ainda falta mais uma coisa antes de definir o pagamento do sprint. Qual o percentual de entrega em pontos?
Estabeleci algumas métricas internas para pontuação (delivery). Por exemplo, abaixo de 80% de entregas aplica-se uma penalidade de 10%. Acima de 100% de entrega, aplica-se uma bonificação de 10%. Entre 80% e 100% dos pontos, paga-se o valor cobrado pelo sprint.
Em números: vamos supor que no sprint planning o time puxou 100 pontos e entregou 79 pontos (com objetivo atingido). Nesse caso receberão R$30.000 – R$3.000 = R$27.000.
Caso eles tenham feito entre 80 e 100 pontos, receberão os R$30.000 que cobraram.
Caso tenham feito 101 pontos ou 200 ou mais pontos, receberão R$30.000 + R$3.000 = R$33.000.
Cancelamento Fracasso:
Quando rodamos a partir de terceiro sprint, podemos avaliar o atingimento das metas. Caso sucessivos sprints não atinjam as metas, tem algo errado que deve ser revisto. Ou performance da equipe, gerenciamento do backlog, impedimentos, etc. Pode-se decidir então cancelar o projeto antes que o prejuízo aumente por fracasso.
Cancelamento Sucesso:
O projeto também pode ser cancelado por motivo de sucesso.
Caso no meio do projeto, lá pelo sprint 5, o ROI tenha sido atingido, ou seja, o cliente já está satisfeito com o que tem no momento, pode-se negociar com o fornecedor-parceiro o término adiantado com sucesso mediante uma bonificação sobre os sprints faltantes. Exemplo: faltam 5 sprints de R$30.000 cada, paga-se 20% sobre os 5 sprints que equivale a R$6.000 x 5 = R$30.000 de bônus por cancelamento com sucesso.
Pode ocorrer do fornecedor-parceiro não querer finalizar e receber tal bônus por não ter como alocar as pessoas em outro projeto, nesse caso podemos continuar executando o projeto, que tem escopo dinâmico (product backlog), na base do money for nothing and change for free. Sendo que a partir desse ponto de execução as funcionalidades não agregam mais tanto valor ao produto.
Os percentuais e valores colocados aqui são meramente para exemplificar a dinâmica desse modelo de contrato. Cada empresa pode adotar os percentuais adequados à sua operação, algumas mais conservadoras e outras mais arrojadas.
Espero ter contribuído com essa modalidade de contrato que estou confiante que trará bons resultados pra ambos. É verdadeiramente uma relação ganha-ganha.
Search
Calendar
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
| « Jan | ||||||
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | ||||||
Archives
Recent Comments
Categories
Syndication
Recent Posts
Carlos
Para não esquecer/perder meu acervo de assuntos, tenho o costume de publicar para compartilhar e exercitar minha mente.
Powered by Blog.com
