Evento AgiDC

Seminário de Sexta

Palestra agil completa

View more presentations from Rafael Vinicius Kuhn Toebe

Desenvolvimento Ágil de Software

Neste post de estreia, compartilho os slides da apresentação que tive a oportunidade de realizar no 1º Seminário AgiDC, onde abordei o tema "Desenvolvimento Ágil de Software".

A apresentação tem por objetivo expor os motivadores para o surgimento de novas abordagens de desenvolvimento de software e introduzir os valores e princípios do movimento ágil de software.

Apresentação: Desenvolvimento Ágil de Software

Negócios Ágeis - agilidade focada ao negócio

Olá!

No link abaixo está a apresentação realizada sobre Negócios Ágeis na Datacoper.
Dentro do 1º Seminário do AgiDC de negócios, desenvolvimento e gestão ágil  -

Apresentação sobre Negócios Ágeis na Datacoper

Vamos em frente!

Jordano Gonzatto

1º Seminário AgiDC

Abordagens ágeis na Datacoper

Olá!
Tendo como temática o objetivo de convergir dentro da estrutura da Datacoper/Vistra, o assunto de Business and developer focados em Agile.

Se fosse para resumir o que isso tudo significa em uma frase, na minha visão seria a frase do Mark Suster @msuster, que diz:

"Indivíduos não fazem grandes empresas. Times fazem"

É nessa linha que as organizações devem seguir, indiscutivelmente.

Vamos em Frente!

Jordano Gonzatto
Business

Caro buscador de uma bala de prata.

Entendo que, como gestor, ao buscar um processo ágil, você esteja buscando que sua produtividade melhore. Quem não gostaria de escolher um novo processo e ver tudo melhorar automaticamente? No entanto e infelizmente, o seu time é composto de pessoas, e isso significa que o comportamento dele não é determinístico, assim como o seu próprio.
Nós podemos ajudá-lo a entender como o Scrum funciona, e ajudá-lo a utilizar o Scrum na sua empresa, algo que tem o potencial de mudar para sempre como sua empresa funciona. Pode ser que durante este processo você descubra outra bala de prata que lhe pareça mais atraente e abandone o Scrum. Muitos meses se passam até que a média das empresas perceba que o Scrum não vai fazer o seu trabalho, e que elas ainda precisam resolver os próprios problemas.
As empresas que realmente estão dispostas a mudar seu comportamento relatam melhorias na previsibilidade das suas entregas, na qualidade dos seus produtos, e no relacionamento dos times e da empresa como um todo. Tais empresas também costumam reagir mais rápido à mudanças, inovam mais e tem um turnover menor.
No entando, as empresas que apenas dizem estar usando Scrum mas mantém velhos comportamentos, hábitos e processos são muito mais comuns do que as que recebem os benefícios citados. Mudar velhos hábitos sempre é difícil. Trabalhar dificuldades técnicas e políticas a caminho de uma melhora genuína é difícil. O Scrum e a agilidade em geral exigem estas mudanças. Assim, a maioria das empresas falha ao adotar e Scrum ou outro framework ágil, porque precisam confiar em seus funcionários, entender que eles estão fazendo o melhor ou buscando chegar lá, melhorar suas práticas de engenharia, e enterrar egos e pessoas com comportamentos políticos nocivos.
Sendo assim, se você não quiser passar por essas mudanças para alcançar os benefícios citados não use Scrum ou outro framework ágil. Se quiser genuinamente melhorar e está disposto a passar por tais dificuldades até que os benefícios comecem a aparecer, estamos à disposição.

Fonte

Os principais erros de equipes que estão querendo adotar Scrum

·         O Gerente nomear um líder de equipe para ser ScrumMaster

·         O Scrum Master acreditar que o Scrum irá se adaptar a empresa e que  já está tudo pronto para misturar processos antigos com Scrum

·         O Product Owner não é presente.

Ai vai uma explicação de cada ponto:

O primeiro:

Quando um gerente nomeia um líder para ser Scrum Master e o líder não conhece bem as regras do Scrum ou verte a camisa do gerente e o mesmo passa a interferir em uma das principais premissas do Scrum, os times auto gerenciáveis. 

O segundo:

Não funciona bem assim, a empresa que se adapta ao Scrum e não o contrario.

O Scrum é um disciplinador, ele vai fazer você seguir umas determinadas regras para que sejam atingidos os objetivos, caso a equipe comece a retirar essas regras provavelmente a adoção do Scrum irá fracassar.

O terceiro:

Como partimos do ponto em que não sabemos de todas as variantes do projeto e vamos nos adaptando as mudanças que virão com o decorrer da Sprint, é necessário um P.O presente para ir esclarecendo as varias duvidas que irão surgindo durante o desenrolar do projeto, para isso o P.O deve estar sempre contribuindo para que sua participação não passe a ser um impedimento.

Quem cria código é responsável pela Qualidade.

Como QUALIDADE faz parte da agilidade aqui tem parte de uma matéria que achei interessante.

Um resumo rápido:

Diferença entre cientista da computação, desenvolvedor e programador.

O Cientista da Computação

Eles não precisam saber se algo funciona, eles apenas se preocupam em provar se aquilo funciona ou não. Para um cientista da computação habilidades interpessoal e boa comunicação não são necessários.

O Desenvolvedor

São especialistas em achar formas diferentes (e igualmente eficientes) de resolver o mesmo problema. No tempo livre um desenvolvedor costuma tentar criar o novo Facebook ou se dedica a atividades extras computacionais, que não têm nada a ver com programação, desenvolvimento ou ciência da computação.

O Programador

Eles precisam apenas saber as melhores soluções para os problemas que encontram mas não precisam saber (ou conseguir provar) que aquelas soluções são as melhores.

Qual deles você é?

 Fonte

Rafael Toebe

Agile Vale 2011 - Scrum e mudança organizacional

Segue o link do vídeo que passei no dia do clube do vídeo para os que queiram ouvir de novo ou em melhor som e qualidade.

Scrum e mudanças organizacionais

Att Rafael Toebe