You need to hit value, not dates.
Make sure you are building win win contracts.
Etiqueta: agilidade
-
-
Essa conversa aconteceu no Maringá Agile Day 2020, onde tive a oportunidade de conversar sobre descoberta, inovação e aprendizado, a partir desta pergunta. E se der errado?
(mais…) -
Tudo que impede fluxo é ruim. Uma excelente forma de perceber isso é ter uma clareza visual de que o trabalho não está andando.
Se um item demora muito para ser concluído ou se muita coisa fica parada esperando respostas que não chegam nunca, temos problemas. Estes problemas indicam tarefas grandes demais, que podem ainda ser carregadas de incertezas. E talvez um processo de falta de autonomia ou falta de gestão de conhecimento.
Todo fluxo organizado em um kanban pede limites, pede representação da realidade, pede visualização e pede políticas. E as políticas são na minha opinião a parte mais importante. As políticas emergem dos aprendizados. Os aprendizados acontecem com a prática do dia a dia, tentando fazer o trabalho acontecer. Todos problemas se resumem em saber:
(mais…) -
Construir conhecimento é um processo, e não se baseia em um evento ou uma chamada pontual. É preciso desenvolver uma cultura de aprendizado ou até melhor, de aprendizagem, e neste contexto as comunidades de prática podem ser o canal certo para fazer acontecer. Nesta palestra vou apresentar conceitos sobre comunidades de prática, exemplos de comunidades do RS que ajudei e ainda ajudo a desenvolver e como estas práticas podem ser levadas para dentro das organizações em uma espécie de plano de ação.
(mais…) -
Hoje muitas empresas ainda acham o uso de um wiki “informal demais”. Precisam de documentos bem formatados, com responsáveis (culpados) pela edição e parecem pedir por processos rígidos para travar qualquer iniciativa de melhoria.
Tratam de informal aquele conhecimento que é construído de forma emergente representando a realidade. Como se fosse preciso formalizar alguém no papel de professor.
As empresas perdem a chance de desenvolver pessoas criando linhas de aprendizado. Perdem a chance de oportunizar a construção e compartilhamento dentro da organização.
(mais…) -
Mais um episódio disponível, agora falando sobre planejamento e a importância dos pequenos ciclos de entrega.
Atender expectativas dos nossos clientes está muito ligado ao foco em entregas pequenas e frequentes, permitindo a percepção de valor de forma contínua. E também permitindo ajustes do fluxo de trabalho.
-
Em 2001-2002 conheci o JUnit, ferramenta para escrita de testes unitários em Java. Em 2003 entendi mais da importância dela para o desenvolvimento de software. Descobri junto Delphi Unit, PHP Unit e outras várias versões e pude ajudar amigos a conhecem mais de uma cultura de melhoria contínua e de busca por código de qualidade e automatizado.
O que mudou?
-
Ser inovador é algo bem difícil. Pra começar não adianta você se dizer inovador. O mercado precisa perceber isso em você.
Ser disruptivo ou incremental. Eis a questão atual? 🙂
(mais…)
-
Todos times deveriam ter um momento de prática. Um momento para desligar e viver situações diferentes. Treinar programação. Compartilhar pensamentos que não apareceriam no dia a dia de projeto.
Um Dojo é o lugar do caminho, é a casa dos praticantes de artes marciais. Desenvolvimento de Software além de ser uma atividade criativa, é uma arte. E como tal, deve ser estudada, praticada, e melhorada de forma constante.
A troca de experiências que ocorre em uma sessão de treinamento, entre pessoas com mais experiência e iniciantes é algo único, uma oportunidade de aprender e de ensinar. De colaborar e ajudar na formação de melhores desenvolvedores.
É um ambiente de colaboração. Competição não possui lugar. É um ambiente de treinamento, onde práticas do eXtreme Programming como Desenvolvimento Orientado a Testes (TDD), Design Simples, Programação em Pares e Posse Coletiva podem ser compartilhadas. As ideias devem ser provadas com código. E todo novo código precisa aparecer evoluindo dentro do ciclo do TDD (Red-Green-Refactor). Explico: primeiro se faz a criação de um teste falhando um determinado cenário em foco, depois criar o mínimo necessário de código para fazer o teste passar e por fim aplicar técnicas de refatoração para melhorar a estrutura do código fonte, deixando ele mais simples. Ciclos curtos fazendo isto até fazer o que precisa ser feito.
Normalmente para se fazer um dojo se precisa de:
- Um problema a ser resolvido. É normalmente um problema de lógica, onde através de técnicas de design, evolução constante do código através da criação de testes e pequenos passos, este problema vai sendo trabalhado e evoluído. Eventualmente se pode chegar na solução do problema, mas o propósito do Dojo é estudar situações e oportunidades de projetar e resolver um determinado problema.
- Datashow ou forma de compartilhar o que está ocorrendo com os participantes.
- Uma estratégia para tocar o Dojo. Existem algumas, como o (a) Prepared Kata, onde um especialista resolve o problema do início ao fim. O que mais uso, o (b) Randori Kata, possui um timer tocando a cada 5-7 minutos, indicando uma nova rotação a ser feita. Temos apenas um computador sendo usado nesta abordagem, assim como é com o Prepared Kata. A cada rotação o desenvolvedor que ficou na máquina tem a tarefa de passar o conhecimento e situar quem está chegando. Aqui estão as oportunidades perfeitas para parear pessoas com grande diferença de conhecimento. Assim o aprendizado funciona muito melhor. Ainda temos o conceito de (c) Kake Kata, onde pequenos grupos se formam e resolvem o mesmo problena. As rotações ocorrem dentro do grupo e entre grupos. O desafio neste caso comparado com o Randori, é que a cada ciclo, estaremos visualizando código diferente e que não foi tocado anteriormente pelo time. Então o processo de aprendizado tem mais desafios.
- Pessoas. Pelo menos 1 pessoa. Se pode fazer um Prepared Kata e gravar para publicar online. 🙂
- E o tempo? Uma hora pode ser o suficiente para passar a mensagem e fazer o time trabalhar junto. Gosto de usar 60-80mins de tempo de trabalho.
E quer saber qual a parte mais legal? Esta estrutura de pareamento e colaboração pode ser usada para diversas abordagens! Desenvolvimento de um Business Canvas, escrita de requisitos em um dojo de análise de negócios, e por aí vai.
Update Jan/2019, vídeo sobre Coding Dojo. Extras:
- Fotos sobre CodingDojo no Flickr.
- CodingDojo.org com a explicação do que é um CodingDojo (em inglês).
- Diferentes Katas a serem usados nos exercícios.
Dúvida para o seu primeiro Dojo? Pegue um problema simples como o FizzBuzz, escolha uma linguagem, um framework de teste e mande ver!
-
I saw an infographic asking if we are getting into another “dot com” bubble. That infographic was built by Udemy, great job. I agree with that, and I believe we have better tools and techniques today to help companies to play in startup mode.
One of the things we surely need to focus on is the concept “Lean Startup“. Lots of ways to describe can be found. My way, as an eXtreme Programming and Agile practitioner is to think about a real way to help companies to leverage products to a real experience. With real software engineering + marketing and customer development practices.
But… delivering fast is not enough. Actually it never was! We need to understand who is caring about what is delivered. We need to measure not only progress with real software, but measure how are our clients enjoying the experience during the process. So yes, we have to speak to final users, get feedback, understand what are they looking for. They know the next killer feature of your product. True.
So playing with startups and lean startups is about building experiments and testing ideas and learning from those experiences. Really about learning.
Having that in place, we can grow ideas. I like that term. It’s not about building ideas. But actually grow them.
Last week of June/2011 during Agile Brazil 2011 I’ve done a workshop called “From vision to production”, where I was focused on talking to people about techniques teams using Agile Methodologies like Lean and eXtreme Programming to deliver products and features can use. How do you know if those features are the top ones?
During the practice, I’ve challenged teams to understand about how to build something that can be used to test the idea. Not tested by some xUnit framework, but tested by the market. If possible not even using a real software but using simple tools like a survey, interviews and paper prototyping.
Simple and small experiments that can help a team to learn faster. And prepare it to the next experiment. One of them may result in a software. One of them may result in many new users. One of them may take the company to a next level.
The whole thing is not about getting rich or getting money in a easy way. You know why?
One of those experiments may shutdown your idea, and “help you” to move to some other venture. But, how long would that take? One week? A Month? One whole year?
The thing is about failing as fast as possible, so you can pivot, so you can change direction, plan again, and try again.
Getting to the end…
This post was about sharing things I’m playing a lot.
I’m helping a product to grow for seven months now, since its official launch.
It’s not easy. But it can be fun.And the “experiences” I will share here, will be related also to other ideas I will help to grow.
Failure is expected. Always. But I’m not about winning all the time (although it’s very good).
I’m about learning.
And you should be too. 🙂So, to finish “The Lean Startup Experience” post, we should think about a song…
Hey Yo (The pivot song :-))
Hey Yo, where you goin’ with that idea in your head?
Hey Yo, I said, where you goin’ with that idea in your head?
I’m goin’ down to shut my old one baby
I caught her metrics and they are poor man
I’m goin’ down to start a new one baby
I’ll start messin’ round again* Any relation with The Jimi Hendrix Experience… is that I’m a left handed guitar player too. Just that. \o/
daniel wildt 