Essa leitura que recomendo, é um negocio sem tamanho, uma historia sem fim! E pior que faz parte do meu universo...
Li empolgada, Dooooooooooida pra mostrar pra minha chefa e gerar uma reunião com todo mundo.
Mas... procrastination. Eles nao me querem pra nada desse tipo por aqui :P
http://www.infoq.com/br/news/2011/05/agile-setor-publico
enjoy!
Showing posts with label agile. Show all posts
Showing posts with label agile. Show all posts
Monday, October 22, 2012
Wednesday, October 03, 2012
Curso KANBAN
Esse curso parece ser show. E pelo que tou vendo nos oturos blogs, essa onda de KANBAN vai pegar!
http://blog.aspercom.com.br/2012/09/11/treinamento-kanban-lku-brasil/
Conteúdo programático:
http://www.aspercom.com.br/ead/mod/resource/view.php?id=328
em Brasilia:
http://www.aspercom.com.br/ead/calendar/view.php?view=day&cal_d=18&cal_m=10&cal_y=2012
Divulgando - curso da GOTO-AGILE!
Curso Lean Kanban oficial pela LKU (Lean Kanban Unvercity).
Investimento
Por que “ Lean Kanban ”?
Os métodos ágeis trouxeram uma grande mudança nos rumos da computação. O Scrum, seu maior ícone, tem liderado essa nova forma de pensar, quebrando diversos paradigmas das décadas passadas. Kanban, surgiu depois dessa grande onda, em 2007, explicitando ainda mais essas quebras de paradigmas. Conceitos como fluxo contínuo, foco, visibilidade e melhoria contínua são reforçados. Acreditamos que o Kanban traz um novo patamar de amadurecimento no mundo ágil.
Divulgando - curso da APERCON
http://blog.aspercom.com.br/2012/09/11/treinamento-kanban-lku-brasil/
Conteúdo programático:
http://www.aspercom.com.br/ead/mod/resource/view.php?id=328
em Brasilia:
http://www.aspercom.com.br/ead/calendar/view.php?view=day&cal_d=18&cal_m=10&cal_y=2012
Divulgando - curso da GOTO-AGILE!
Curso Lean Kanban oficial pela LKU (Lean Kanban Unvercity).
Investimento
- R$ 1.680,00
- Até duas semanas antes R$ 1.480,00
- Ex-Alunos GoToAgile! R$ 1.280,00 (enviar email para contato@gotoagile.com.br)
Por que “ Lean Kanban ”?
Os métodos ágeis trouxeram uma grande mudança nos rumos da computação. O Scrum, seu maior ícone, tem liderado essa nova forma de pensar, quebrando diversos paradigmas das décadas passadas. Kanban, surgiu depois dessa grande onda, em 2007, explicitando ainda mais essas quebras de paradigmas. Conceitos como fluxo contínuo, foco, visibilidade e melhoria contínua são reforçados. Acreditamos que o Kanban traz um novo patamar de amadurecimento no mundo ágil.
Para quem “ Lean Kanban ”?
- Times que já adotam Scrum com sucesso há algum tempo e desejam alavancar novas melhorias;
- Pessoas que tenham dificuldades em adotar Scrum, apesar de abraçar as quebras de paradigmas;
- Cenário de atuação com demandas constantes (onde congelar o backlog por 2 semanas é impossível);
- Pessoas que queiram aplicar conceitos modernos da Administração Lean para o desenvolvimento de software;
Times que buscam alternativas de soluções aos seguintes problemas:
- múltiplos clientes;
- demandas urgentes durante a sprint;
- desenvolvimento de novos produtos juntamente com a manutenção de antigos produtos;
- precisam trabalhar com tempo de entrega ou SLA (Service Level Agreement).
Programa
Parte 1: Value Discovery
- Descoberta de Valor
- Minimização de suposições não-validadas
- O Custo de Retardo (Cost of Delay) aplicado a desenvolvimento de software
- Lean Start-up
- BVI (Businesse Value Increment)
- MVP (Minimum Viable Product)
Parte 2: Visibilidade
- Estabelecendo Modelos Mentais Compartilhados
- Kanban como instrumento de geração de engajamento
- Desenhando Processos
- Criando Visibilidade
- Diversificando o quadro Kanban
- Alavancagem de entendimento sistêmico e melhoria contínua
Parte 3: Limited WIP (limitação do trabalho em andamento)
- Por que limitar WIP?
- Identificação do gargalo
- Mecanismos de coordenação
- Quadro Kanban como o tabuleiro de um jogo
- Teoria das filas
Parte 4: Cadeia de Valor
- Enxergando toda a cadeia de valor
- Escalando Agile e conectando células de trabalho
- Definindo e Mapeando Workflows
- Navegando Upstream e Downstream
Parte 5: Fluxo Contínuo
- Push vs Pull
- “Stopping the line”
- Estabelecendo Cadência
- Desacoplando Cerimônias
- Cadência de Transferência
- Nivelamento e T-Shirt Sizing
Parte 6: Administração de Capacidade e Métricas
- Classificação de demandas
- Balanceamento de demandas
- Classes de Serviço
- Throughput, Lead Time, Cycle Time
- Cumulative Flow Diagrams
- SLA/Due Date Performance
Parte Final: O que é Kanban?
- Origem: O Kanban da Toyota
- Kanban como modelo evolucionário
- Implementando o Kanban
- Porque as pessoas estão adotando Kanban?
- Discussões
Wednesday, December 01, 2010
Aumento de produtividade por ponto de complexidade
Ótimo post (sorry o copy-paste, mas gostaria muito te ter isto guardado aqui!): http://programandosemcafeina.blogspot.com/2010/08/aumento-de-produtividade-por-ponto-de.html
Tenho ouvido ultimamente muitos amigos da área comentando sobre pressão por aumento de produtividade baseada em pontos de complexidade. Isso me deixa bastante preocupado. Embora seja nobre o desejo de aumentar as entregas da área de desenvolvimento, quantificar isso usando os pontos de complexidade das histórias não quer dizer muita coisa.
Contudo antes de simplesmente reclamar contra a pressão, é preciso analisar as possiveis causas de produtividade baixa que possam estimular esse tipo de pressão. Pensando bastante cheguei a três possibilidades, e com elas, possiveis soluções, que seriam mais eficazes do que estimular aumento desse tipo de numero.
1- Não há confiança de que o time esteja trabalhando em seu máximo. Ou seja, o agente gerador de pressão acredita que os integrantes estão fazendo corpo mole ou gastando o dia com amenidades ao invés de se focar na entrega do projeto. A pressão por aumento de pontos de complexidade pode até resolver esse problema temporariamente, mas também pode ser mascarado por integrantes do time que se sentem coagidos a fazer horas extras para cobrir as entregas esperadas. Ou seja, o problema só se resolve mesmo com conversas francas e com uma presença mais ativa do interessado.
2- O time percebendo folga na iteração aproveita para melhorar a qualidade da entrega ainda mais. Esse tipo de preciosismo costuma acontecer com bastante frequência. Muitas vezes o desenvolvedor por ter mais tempo para pensar aproveita para implementar testes e fluxos mais rebuscados evitando bugs que no futuro tomariam o triplo do tempo, e o designer aproveita para criar e rebuscar as interfaces e assim encantar ainda mais o cliente. Neste caso a pressão pelo aumento de entrega de pontos de complexidade apenas estimula a diminuição da qualidade. Ou seja, embora haja um aumento imediato na velocidade, em pouco tempo ela cairá por causa das correções de bugs e dos ajustes visuais.
3- O time é inexperiente ou não conhece a tecnologia adotada. Neste caso pressionar pelo aumento de entrega de pontos de complexidade de nada adianta. De certa forma, com o tempo, naturalmente as entregas serão maiores, ou em muitos casos menores pois o time começará a estimar com menos pontos, demonstrando assim a ineficácia desse numeros para medir produtividade. Para resolver este problema existem diversas opções como, organizar dojos, estimular programação em par, indicar livros e treinamentos, estimular a experimentação com tempo para projetos pessoais.
Todas três possibilidades acima eu vi acontecer de perto nos times em que trabalhei. E quase sempre o problema foi resolvido sem utilizar os pontos de complexidade como parâmetro de medição. E vocês lembram de alguma outra causa de produtividade baixa? Tem idéia de como solucionar? Qual sua opinião sobre o assunto?
Tenho ouvido ultimamente muitos amigos da área comentando sobre pressão por aumento de produtividade baseada em pontos de complexidade. Isso me deixa bastante preocupado. Embora seja nobre o desejo de aumentar as entregas da área de desenvolvimento, quantificar isso usando os pontos de complexidade das histórias não quer dizer muita coisa.
Contudo antes de simplesmente reclamar contra a pressão, é preciso analisar as possiveis causas de produtividade baixa que possam estimular esse tipo de pressão. Pensando bastante cheguei a três possibilidades, e com elas, possiveis soluções, que seriam mais eficazes do que estimular aumento desse tipo de numero.
1- Não há confiança de que o time esteja trabalhando em seu máximo. Ou seja, o agente gerador de pressão acredita que os integrantes estão fazendo corpo mole ou gastando o dia com amenidades ao invés de se focar na entrega do projeto. A pressão por aumento de pontos de complexidade pode até resolver esse problema temporariamente, mas também pode ser mascarado por integrantes do time que se sentem coagidos a fazer horas extras para cobrir as entregas esperadas. Ou seja, o problema só se resolve mesmo com conversas francas e com uma presença mais ativa do interessado.
2- O time percebendo folga na iteração aproveita para melhorar a qualidade da entrega ainda mais. Esse tipo de preciosismo costuma acontecer com bastante frequência. Muitas vezes o desenvolvedor por ter mais tempo para pensar aproveita para implementar testes e fluxos mais rebuscados evitando bugs que no futuro tomariam o triplo do tempo, e o designer aproveita para criar e rebuscar as interfaces e assim encantar ainda mais o cliente. Neste caso a pressão pelo aumento de entrega de pontos de complexidade apenas estimula a diminuição da qualidade. Ou seja, embora haja um aumento imediato na velocidade, em pouco tempo ela cairá por causa das correções de bugs e dos ajustes visuais.
3- O time é inexperiente ou não conhece a tecnologia adotada. Neste caso pressionar pelo aumento de entrega de pontos de complexidade de nada adianta. De certa forma, com o tempo, naturalmente as entregas serão maiores, ou em muitos casos menores pois o time começará a estimar com menos pontos, demonstrando assim a ineficácia desse numeros para medir produtividade. Para resolver este problema existem diversas opções como, organizar dojos, estimular programação em par, indicar livros e treinamentos, estimular a experimentação com tempo para projetos pessoais.
Todas três possibilidades acima eu vi acontecer de perto nos times em que trabalhei. E quase sempre o problema foi resolvido sem utilizar os pontos de complexidade como parâmetro de medição. E vocês lembram de alguma outra causa de produtividade baixa? Tem idéia de como solucionar? Qual sua opinião sobre o assunto?
Wednesday, March 17, 2010
Fwd:Curso Certified ScrumMaster – CSM (Recife) - Estarei lá! =)
Nos dias 18 e 19 de março no Recife Praia Hotel (www.recifepraiahotel.com.br) vai acontecer o Curso Certified ScrumMaster. O curso será ministrado por Michel Goldenberg.
Neste treinamento de dois dias você não somente conhecerá os fundamentos do Scrum, mas terá experiências hands-on usando Scrum. Este treinamento coloca a teoria em ação através de várias atividades práticas que simulam em sala de aula o funcionamento do Scrum.
Durante o treinamento, os participantes irão entender como um simples – mas eficiente – processo como Scrum pode transformar os resultados de uma empresa. Os participantes deste treinamento irão adquirir experiência com as ferramentas utilizadas no Scrum e em atividades ligadas a Product e Sprint Backlogs, Daily Meetings, Sprint Planning Meeting, Review, Retrospectives e Burndown charts. Irão também aprender como aplicar Scrum em diversos tipos de projetos, do single collocated team ao time distribuído em ambiente off-shore.
Essa formação está sendo organizada pela Goto Serviços Tecnológicos. O valor do curso é R$ 1500,00 no early bird (até 3 semanas antes do curso) ou R$ 1900,00, após as 3 semanas. Esses valores podem ser pagos por boleto bancário em até 3 vezes ou por depósito bancário ou cheque à vista.
Para saber mais sobre o processo de certificação de Scrum, por favor, consulte http://www.scrumalliance.org/scrum_certification
Detalhes
Data: 18 e 19 de março (08h00 – 18h00)
Carga Horária: 16 horas
Local: Recife Praia Hotel – Av. Boa Viagem, N° 9, Pina, Recife – PE
Valor: R$ 1500,00 no early bird
Valor: R$ 1900,00 após o early bird
Oferecemos: Almoço e coffee break
Idioma: Português
Instrutor: Michel Goldenberg
Contato:
Alexsandro Marques – alexoliveira.marques@gmail.com
Fernanda – fernanda.goto@gmail.com
Sobre o Instrutor:
Michel Goldenberg é co-fundador do Grupo de usuário Scrum de Montreal, um dos maiores grupos de usuários Scrum do Canadá. Michel vem divulgando o Framework Scrum na comunidade de Montreal e pelo mundo através de palestras e treinamentos. Além disso, Michel presta consultoria e é Agile Coach em grandes empresas no Canadá.
Com mais de dez anos em TI e cinco anos trabalhando em projetos Scrum, Michel Goldenberg foi percebendo aos poucos os motivos que atrapalhavam a aceitação de Scrum dentro das empresas, e concluiu que o motivo principal era os erros de planejamentos.
O que diferencia os consultores é a paixão verdadeira por suas atividades. Michel tem uma paixão especial pelo Agile Estimating and Planning, em criar times unidos e bem balanceados, e maximizar o ROI (Retorno de Investimento) dos projetos nos quais ele trabalha como Coach e aonde vem ajudando muitos times a reerguerem e retomarem projetos considerados de insucesso até sua atuação.
Para maiores informações, consulte:
http://twitter.com/Michel_Golden
http://ca.linkedin.com/in/mgoldenb
http://www.scrumalliance.org/profiles/38596-michel-goldenberg
Atenciosamente,
Alexsandro Marques, CSPO
www.alexsandromarques.wordpress.com
Friday, October 30, 2009
uma dia qualquer de QA no scrum...
Ok, vamos lá analisar a situação de um projeto que auditei:
Cheguei no ambiente do projeto, perguntei em que sprint estavam, e o time não soube responder (vai terminar a #2? Já terminou a #3?).
Teve retrospectiva recentemente de que sprint? Não souberam, responderam que foi da #2. Era da #3!
Oficialmente, pelo wiki e registros feitos pelo gerente, estão com a sprint #3 finalizada (de 21/09 á 02/10)
Ainda tem post-it da sprint #2 no taskboard.
Não tem apontamento de horas.
Gráfico burn-up? Ninguém tocou nele. Sò tá o 'esqueleto'.
Acompanhei um review da equipe, onde problemas muito bobos foram levantados como bugs (internos no caso).
Hoje vi apenas um área do ‘rip’...além de relatos que o projeto não sofre atualização no ambiente de produção a mais de 3 sprints,por ‘medo de bugs’ mais pesados... Equipe relaxada, desenvolvendo sem motivação, perdendo tempo com retrabalho em bugs bobos internos.
E quantos pontos entregues nessa finalizada sprint #3? Ninguém presente sabe responder. "Vê na ata" me falaram;
O time não acompanhou seu próprio desempenho, apontando sempre ‘pergunte ao gerente’... Cadê aquela equipe auto-gerenciável? Que faz as atividades (reuniões, gerar baseline, atas, arruma eventum) mesmo sem scrum-master por perto?
Isso me é preocupante. O Scrum parece que não tá rolando direito...
Resultado: NC´s de tudo que é tipo!
Mas esta bagunça, que se repete em mais de um projeto, tem uma explicação.
Ou vocês acham que só SCRUM salva?
Neste caso, a bronca vem 'lá de cima'.Depois falo mais sobre isso.
Cheguei no ambiente do projeto, perguntei em que sprint estavam, e o time não soube responder (vai terminar a #2? Já terminou a #3?).
Teve retrospectiva recentemente de que sprint? Não souberam, responderam que foi da #2. Era da #3!
Oficialmente, pelo wiki e registros feitos pelo gerente, estão com a sprint #3 finalizada (de 21/09 á 02/10)
Ainda tem post-it da sprint #2 no taskboard.
Não tem apontamento de horas.
Gráfico burn-up? Ninguém tocou nele. Sò tá o 'esqueleto'.
Acompanhei um review da equipe, onde problemas muito bobos foram levantados como bugs (internos no caso).
Hoje vi apenas um área do ‘rip’...além de relatos que o projeto não sofre atualização no ambiente de produção a mais de 3 sprints,por ‘medo de bugs’ mais pesados... Equipe relaxada, desenvolvendo sem motivação, perdendo tempo com retrabalho em bugs bobos internos.
E quantos pontos entregues nessa finalizada sprint #3? Ninguém presente sabe responder. "Vê na ata" me falaram;
O time não acompanhou seu próprio desempenho, apontando sempre ‘pergunte ao gerente’... Cadê aquela equipe auto-gerenciável? Que faz as atividades (reuniões, gerar baseline, atas, arruma eventum) mesmo sem scrum-master por perto?
Isso me é preocupante. O Scrum parece que não tá rolando direito...
Resultado: NC´s de tudo que é tipo!
Mas esta bagunça, que se repete em mais de um projeto, tem uma explicação.
Ou vocês acham que só SCRUM salva?
Neste caso, a bronca vem 'lá de cima'.Depois falo mais sobre isso.
Wednesday, May 20, 2009
Perdi o ScrumGatering 2009?
BUá! Meus colegas foram, marcaram em peso o nome da minha 'empresinha' meio aos pernambucanos que compareceram: dos 11 de PE, uns 6 tinham seus nomes relacionados á PTS, fora a consultoria; Até minha amiga dos tempos de escola (Stéeeh!) foi. Invejinha. Muita. Foi pra quem pôde. :P
A repercussão do evento tá sendo linda, cheia de fotos e fatos:D
Meio a tudo, grudadinho teve evento na Aeso, aulinhas, e muito bururu na empresa.
Fiquei de fora?
Nah, nem tanto. È, digamos que minha cabeça me deu férias. Agora consigo tuuuuudo q eu queria e mais um pouco, sem desembolsar os 200dólares da filiação á 'grande aliança' + passagens: http://www.scrumalliance.org/resources?tag=SG+2009+Brazil.
Economizar é a palavra da vez :s
A repercussão do evento tá sendo linda, cheia de fotos e fatos:D
Meio a tudo, grudadinho teve evento na Aeso, aulinhas, e muito bururu na empresa.
Fiquei de fora?
Nah, nem tanto. È, digamos que minha cabeça me deu férias. Agora consigo tuuuuudo q eu queria e mais um pouco, sem desembolsar os 200dólares da filiação á 'grande aliança' + passagens: http://www.scrumalliance.org/resources?tag=SG+2009+Brazil.
Economizar é a palavra da vez :s
Sunday, April 08, 2007
GTD em palestra
Existe há alguns anos uma comunidade dedicada à estudar a produtividade - o GTD – Getting Things Done.
Um dos caras mais conceituados nesta área é o Merlin Mann, considerado uma espécie de “guru” dessa área de GTD. Ele tem pensamentos bem revolucionários, e ensina dicas e truques que realmente ajudam.
Ele é um dos caras que sugeriu as tão polêmicas reuniões notebook-less (quero ver qual vai ser o trocadilho agora), e não só notebook-less como também blackberry-less, iphone-less, e qualquer-outra-coisa-que-distraia-você-less.
No ano passado, ele (Marlin Menn) fez uma palestra de 1 hora em um evento do Google – o Google Tech Talks, onde ele fala sobre o conceito de INBOX ZERO. Achei muito interessante, e depois de ver a palestra, mudei a forma como eu trabalhava com o meu email – em suma, menos pastas, menos regras malucas de arquivamento manual, e maior utilização do mecanismo de buscas built-in do Outlook. E o ganho que tive foi evidente e valeu muito a pena.
A palestra infelizmente é em inglês sem legendas, então se você não tiver fluência - se lascou pra entender. Peça ajuda (sério!) se não você vai entender tudo errado!
Segue o link para o Vídeo da apresentação: http://video.google.com/videoplay?docid=973149761529535925
E, se alguém se interessa por essa área de produtividade, GTD, etc, vejam o BLOG do Marlin: http://www.43folders.com/, e recomendo começar pela lista popular de posts, para entender primeiro o que é o conceito do GTD e depois conseguir ler o BLOG sem ficar cheio de dúvidas: http://www.43folders.com/meta/popular-post-list
-----
Ah sim, esqueci:
Vocês podem baixar a apresentação a partir do slideshare: http://www.slideshare.net/merlinmann/inbox-zero-actionbased-email
-----
Se alguém ainda ficou com dúvidas, seguem alguns links sobre GTD para tentar informar mais:
http://www.davidco.com/what_is_gtd.php
http://pt.wikipedia.org/wiki/Getting_things_done
Acho a leitura extremamente pertinente e interessante!
Um dos caras mais conceituados nesta área é o Merlin Mann, considerado uma espécie de “guru” dessa área de GTD. Ele tem pensamentos bem revolucionários, e ensina dicas e truques que realmente ajudam.
Ele é um dos caras que sugeriu as tão polêmicas reuniões notebook-less (quero ver qual vai ser o trocadilho agora), e não só notebook-less como também blackberry-less, iphone-less, e qualquer-outra-coisa-que-distraia-você-less.
No ano passado, ele (Marlin Menn) fez uma palestra de 1 hora em um evento do Google – o Google Tech Talks, onde ele fala sobre o conceito de INBOX ZERO. Achei muito interessante, e depois de ver a palestra, mudei a forma como eu trabalhava com o meu email – em suma, menos pastas, menos regras malucas de arquivamento manual, e maior utilização do mecanismo de buscas built-in do Outlook. E o ganho que tive foi evidente e valeu muito a pena.
A palestra infelizmente é em inglês sem legendas, então se você não tiver fluência - se lascou pra entender. Peça ajuda (sério!) se não você vai entender tudo errado!
Segue o link para o Vídeo da apresentação: http://video.google.com/videoplay?docid=973149761529535925
E, se alguém se interessa por essa área de produtividade, GTD, etc, vejam o BLOG do Marlin: http://www.43folders.com/, e recomendo começar pela lista popular de posts, para entender primeiro o que é o conceito do GTD e depois conseguir ler o BLOG sem ficar cheio de dúvidas: http://www.43folders.com/meta/popular-post-list
-----
Ah sim, esqueci:
Vocês podem baixar a apresentação a partir do slideshare: http://www.slideshare.net/merlinmann/inbox-zero-actionbased-email
-----
Se alguém ainda ficou com dúvidas, seguem alguns links sobre GTD para tentar informar mais:
http://www.davidco.com/what_is_gtd.php
http://pt.wikipedia.org/wiki/Getting_things_done
Acho a leitura extremamente pertinente e interessante!
Subscribe to:
Posts (Atom)