Publicado em

A importância do time box.

O time box tem o objetivo de limitar uma quantidade de tempo para a resolução de uma atividade, existe um time box para todos os eventos do Scrum por exemplo.

O time box de certa forma promove a auto organização já que o planejamento de cada sprint será feito considerando o tempo determinado promovendo a oportunidade do time trabalhar em grupo encontrando soluções que caibam no tempo estabelecido em cada cenário.

O time box colabora que todos estejam focados na mesma questão ao mesmo tempo, isso facilita a coesão do time na busca pela meta da sprint. As pessoas que estão mais proxímas do problema serão encorajadas a criar a melhor solução possível dentro da período estabelecido para sua finalização dado o contexto situacional vigente.

O time box é um recurso do ágil muitas vezes negligenciado, entretanto temos muitos benefícios na sua correta utilização.

Apesar de ser um ferramenta importante não seja radical, não há problema por exemplo se em uma daily exceder o tempo, caso a conversa esteja sendo pertinente e for importante para o time, permita, sempre use o bom senso.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Pecado capital no ágil escalado.

O trabalho precisa ser organizado e sequenciado, as dependencias resolvidas e os resultados apresentados, isso pode ser dificil quando temos mais de um time utilizando o mesmo backlog de produto devido a necessidade da integração destes incrementos e testes integrados.

As dependências precisam ser mapeadas o mais cedo possível e é essencial que os times envolvidos colaborem para completar o trabalho de forma a alcançar a definiçao de pronto, é importante que tanto os times quanto o backlog do produto sejam organizados de forma a diminuir essas dependências otimizando o trabalho, a forma em que acontece vai variar conforme o ramo e os recursos envolvidos.

O sucesso da iniciativa depende fundamentalmente da participação ativa dos envolvidos, a colaboração é a chave.

Posto isso um pecado capital costumeiro e que presenciei em várias ocasiões é a crença dos times de que devem se importar apenas com o seu trabalho ignorando o que acontece com as dependências, o trabalho que está sendo executado nos outros times do projeto deve ser acompanhado regularmente e quando necessário deve haver colaboração para que o planejamento realizado continue em linha.

A continuidade deste tipo de expediente é um dos principais motivos de falha nos projetos escalados, é essencial que todos tenham ciência da responsabilidade em conjunto com cada interação do projeto na integração de um incremento coeso, fique de olho nas dependências, não as perca de vista, se alguém não conseguir chegar você também não consegue fazer sua entrega.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Scrum Master com time novo, o que fazer !?

Dependendo do cenário, este evento pode acontecer com mais ou menos frequência, o fato é que como Scrum Master de um time recém formado, uma de suas atrubuições é ajudar o time a começar o trabalho da melhor forma e no menor tempo possível.

Solicite que as pessoas do time se apresentem falando brevemente sobre suas carreiras e habilidades, seja o primeiro a fazer isso e não seja muito formal, crie um ambiente para que as pessoas se sintam a vontade nesse momento, vale até contar alguma piada que caiba no contexto, seja gentil.

O Scrum Master deve facilitar o início dos trabalhos do time aproximando o Product Owner e o Time de Desenvolvimento.

Peça ao Dono do Produto para apresentar o projeto, explicar quais são as dores, metas/objetivos, cenário e claro responder as dúvidas do time.

Com essas informações peça para o time Time de Desenvolvimento comece a discutir como eles imaginam que poderiam trabalhar em conjunto no contexto colocado com as informações disponíveis até o momento para iniciar os trabalhos de transformar Backlog do Produto em software, isso deve ajudar como ponta pé inicial.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Tratando requisitos não funcionais no ágil

Além dos requisitos funcionais que traduzem as funcionalidades previstas para uma aplicação, muitas vezes é necessário observar outras necessidades/características que estão inerentes ao que precisa ser desenvolvido, são os requisitos não funcionais que ensejam necessidades como segurança, performance, usabilidade dentre outras.

No contexto de agilidade, temos algumas formas de tratar os requisitos funcionais que quando não tratados o mais cedo possível costumam causar toda sorte de contra tempos, é muito mais difícil fazer um sistema performar mais rápido depois de que ele está desenvolvido do que fazer um planejamento de como essa questão será tratada previamente.

Requisitos não funcionais devem ser tratados o mais cedo possível conforme as necessidades emergem durante o projeto.

Tipicamente podemos tratar essa questão incluindo itens que endereçam as questões relacionadas aos requisitos não funcionais no Backlog do Produto e atribuindo a definição de pronto as atividades necessárias para nos ajudar a identificar como se fará a implementação considerando esses requisitos.

Podemos por exemplo determinar testes de carga estabelecendo uma métrica para a aprovação fazendo parte da definição de pronto, isso irá ajudar o time a se planejar para que os requisitos não funcionais sejam levados em conta desde o início do trabalho.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Scrum Escalado x Definição de Pronto

Em Scrum escalado utilizando frameworks conhecidos como o SAFe ou Nexus por exemplo, existe mais de um time trabalhando no mesmo Backlog do Produto, isso implica na necessidade de uma organização maior já que para que um incremento de software seja considerado pronto, o trabalho executado por mais de um time deve ser integrado para que a entrega possa ser realizada de forma correta.

É responsibilidade de cada time que todo o trabalho previsto no Sprint Backlog ao final reflita a Definição de Pronto (DoD) vigente.

No caso de mais de um time, todos eles são responsáveis por garantir que seus respectivos incrementos sejam devidamente integrados aos incrementos dos outros times envolvidos, pois a soma de todos os incrementos formarão o incremento do projeto para um determinado período (Sprint(s)) sempre levando em conta a Definição de Pronto acordada na iniciativa ou projeto.

Um engano comum é que a entrega seja considerada realizada sem a devida integração do que foi implementado pelos times envolvidos, isso causa diversos contra tempos além do atraso, já que os incrementos ainda terão que ser integrados e ajustes certamente precisarão ser feitos durante o processo gerando mais tarefas “não previstas” (correção de bugs, testes regressivos e etc) afetando o planejamento do trabalho subsequente.

Os times precisam chegar a um acordo sobre uma definição de pronto

O ideal é que uma vez que os times estejam trabalhando no mesmo Backlog do Produto, seja alinhada uma Definição de Pronto comum para todos os times inseridos em uma determinada iniciativa, sendo assim o trabalho previsto nesta Definição de Pronto será considerada no planejamento de cada time envolvido, o que facilitará a integração do trabalho de todos os times ao final de uma sprint.

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!! 

Publicado em

Utilização de técnicas de aprendizagem na TI.

Também atuo como professor, dou aulas há mais de 15 anos e nos treinamentos que ministro dentro das minhas possibilidades do conforme a instituição que estou atendendo, crio uma linha de raciocínio me baseando no que vejo nas empresas por onde passei e o que cada perfil (SM, PO, Dev Team) tipicamente enfrenta, faço isso fazendo uso de uma técnica utilizada na aprendizagem baseada em projetos na área de educação que é a problematização, colocando cenários aonde em grupo as pessoas possam discutir e trabalhar em conjunto para chegar a uma solução com acompanhamento e mediação adequeadas. Em treinamentos InCompany sempre que possível gosto de considerar as DIMENSÕES DE CONTEÚDO (aprendi isso em uma pós de docência):

Implementação de algum processo em relação ao conteúdo ministrado pode ser monitorado e avaliado em três aspectos:

Dimensão Conceitual: Operacionalizar a internalização dos conceitos passados em aula, demanda compreensão e estabelecimento de relações o que aumenta a complexidade de avaliação. (O que saber)

Dimensão Procedimental: Se resume a saber o que fazer, está ligada a operacionalização dos conceitos obtidos propriamente dita. (Saber fazer)

Dimensão Atitudinal: O comportamento individual que é formado por valores e crenças de cada pessoa e seu relacionamento com o contexto do qual está inserida, por meio de observação, sugestões podem ser formuladas com o objetivo de maximizar o aprendizado do conteúdo. (Como fazer).

A abordagem tende a dar mais resultados quando existe um acompanhamento dos egressos após o treinamento, em loco o que certamente exige um esforço e investimento adicionais.

Dimensões de conteúdo caem como uma luva quando falamos em cenários de implantação do Scrum nas empresas, a técnica é perfeitamente aplicável. 

Para me conhecer melhor acesse meu site e meu perfil no LinkedIn, fique a vontade para entrar em contato, vamos conversar !!!