Publicado em

Facilitando a Retrospectiva.

A retrospectiva é um momento em que o time faz uma pausa para uma auto análise, verificando o que houve durante a sprint, é importante que o time seja orientado a não só analisar o que foi feito, mas principalmente o como.

Durante a sprint, observe como as coisas acontecem, vá registrando as situações que funcionam bem ou que precisam melhorar, permita que o time rode a sprint sem interferir, no caso de times com menos experiência é possível que sejam necessárias intervenções pontuais, porém sem atrapalhar o andamento da sprint.

Observe também como o trabalho flui, quais os problemas de comunicação e coordenação aparecem, os momentos em que eles fazem a coisa certa, como estão emocionalmente, quais tipos de situações causam variação na moral do time.

Perseguir a realização de retrospectivas que viabilizam a melhoria do time é algo indispensável, a facilitação para torná-la efetiva é fator crítico para o avanço, ajude-os.

Colete essas informações para preparar um tipo de pauta para a restrospectiva, tente direcionar para o tema mais relevante e que tem potencial de trazer maiores ganhos, no início da reunião pergunte a opinião do time sobre a relevância dos assuntos, dê sua sugestão mas permita que escolham o que é mais prioritário para discutir.

O time deve inspecionar e adaptar, ações de melhoria devem ser determinadas com responsável e devem ser verificadas na reuniões de retrospectivas subsequentes, para ajudar que se cumpram os compromissos assumidos lembre-os, deixe a lista em um lugar visível aonde todo o time possa ver.

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

Publicado em

Você sabe a diferença entre Wireframe, Mockup e Protótipo ?!

Um recurso muito utilizado nos dias de hoje e que pode evitar muita dor de cabeça e desperdício de dinheiro é a utilização de Wireframe, Mockup e Protótipos, antes de começar a codificar, isso alinha o entendimento das partes envolvidas, evita retrabalho e dependendo da necessidade do projeto você pode usar um deles ou os três em conjunto, cada um com características específicas, veja a seguir.

É muito comum antes de começarmos um desenvolvimento que exista a necessidade de confirmação de como serão as telas que serão criadas, desenha-las logo de cara exatamente como serão pode ser um desperdício de tempo, neste caso o rápido é mais devagar e o devagar é mais rápido.

Wireframes mostram apenas um ideia geral de como deverá ser o que está sendo projetado, são muito simples e tem um custo baixo, tem baixa fidelidade e neste ponto ainda não estamos pensando como será viabilizado tecnicamente, neste ponto queremos fechar a estrutura e layout básicos.

Mockups são imagens estáticas de como a versão final do produto irá se parecer, é importante no apoio da definição de coisas como tipografia, estilo, representação visual, cores e etc. É um design representando o que foi desenhado na forma de wireframe (que é o passo anterior) porém com uma fidelidade maior especificando mais detalhes, esse tipo de artefato tipicamente é produzido por designers.

Protótipos nos permitem explorar a interface do usuário procurando possíveis problemas no fluxo além de deixar mais clarificado (já que é possível interagir) o que deve ser feito facilitando também melhorias no que foi planejado até então. Esse artefato é fundamental para realização de pesquisa de usabilidade, também fica mais fácil pra vender caso precise convencer alguém que o que está fazendo é uma boa ideia.

Cada artefato tem o seu papel e valor no passo em que o design da aplicação está, são interrelacionados e vão aumentando a fidelidade conforme o avanço no processo, para resumir:

  • Wireframe trata a estrutura; (Baixa fidelidade)
  • Mockup a parte visual; (Média fidelidade)
  • Protótipos são para interação e usabilidade; (Alta fidelidade)

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

Publicado em

Facilite a Revisão da Sprint

O time deve organizar a reunião que tem o objetivo principal demonstrar o que foi produzido na última sprint executada, não é preciso nada muito elaborado, porém deve ser o suficiente para que as partes interessadas na reunião possam entender o que foi entregue.

Podem começar dizendo o que foi feito em relação ao que foi planejando anuciando quais funcionalidades serão demonstradas pelo time, instrua-os a mostrar utilizando as funcionalidades contando as necessidades que serão atendidas conforme o andamento.

Instrua os stakeholders a fornecer o feedback dando entendimento ao time se os objetivos foram alcançados e se não, quais são os motivos que os levaram a essa conclusão.

A Review é a hora da verdade, o Product Owner deve verificar se o que foi feito pelo time endereça ao que foi planejado, porém além disso há outros objetivos que precisam ser levados em conta, oriente e deixe o time tocar, exerça a observação para posteriormente conversar com o time e fazer os devidos ajustes.

Aproveite para falar de alguma situação/impedimento que está alheia ao time e que as partes interessadas podem ajudar a solucionar, se não puderam ajudar, ao menos ficaram a par das pendências de forma atualizada.

Observe as interações entre o time de desenvolvimento, product owner e partes interessadas, fique em silêncio mas tome nota do que será necessário conversar com time em formato de sugestões para o próximo ciclo.

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

Publicado em

Prepare os ambientes do projeto antes que seja tarde !!!

Uma coisa que usualmente não tem a devida atenção nos projetos é o planejamento para montagem dos ambientes necessários para o projeto, considerando desde o ambiente para desenvolvimento até ao que será utilizado para a homologação com o usuário, o que demanda um ambiente integrado no caso do último.

As vezes não existe disponibilidade para que se tenha todos os ambientes necessários, pode haver compartilhamento com outros projetos por exemplo, para cada situação é necessário considerar quais são os impactos no projeto e qual será a estratégia para contornar os problemas previstos, podem haver muitas dependências e pessoas que precisam ser envolvidas.

Projetos que envolvem muitos sistemas conectados por integrações trazem um cenário dramático quando o assunto é deixado para depois, todos são impactados.

Quanto maior a quantidade de sistemas envolvidos mais eminente será a necessidade de elaborar uma abordagem e identificar quais os impactos para tratativa, imagine o quão difícil é fazer testes confiáveis nesse cenário, teste “mocado” não vale.

A questão deve ser colocada na mesa o mais rápido possível, há situações que podem envolver adaptações importantes no planejamento além da possível necessidade de novos investimentos, já presenciei ambientes que levaram mais de 6 meses para serem montados devido a complexidade envolvida, isso dá muita confusão, prepare-se.

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

Publicado em

Obtenção de Métricas Avançadas

No último post falamos de busca de informações que podem ajudar a ter um direcionamento no ínicio do trabalho e fazer as correções necessárias para que se garanta a integridade das informações prestadas, com essa base, podemos extrair métricas que vão ajuda-lo a dar um direcionamento aos times no médio e longo prazo.

Cycle Time: o tempo médio de quando os itens começam a ser executados até a entrega dentro processo estabelecido.

Lead Time: o tempo médio de finalização dos itens desde a hora em que o item aparece no backlog até a entrega em ambiente produtivo, percorre todo o processo de desenvolvimento, de ponta a ponta.

Throughput: é o número de itens executados dentro do fluxo de desenvolvimento em um determinado período.

WIP: Número máximo de itens que devem estar em progresso, isso ajuda na organização do time, para que se evite que se coloque mais itens em andamento do que o time consegue tratar, já que cada pessoa consegue andar com uma tarefa por vez.

Com a utilização de métricas vários aspectos de um time podem ser analisados e melhorados conforme a necessidade e priorização, porém é necessário ter uma base sólida e íntegra para que se possa ver.

Com a utilização destas métricas é possível controlar e calcular o tempo total de uma tarefa, gerando informação para que se possa tomar iniciativas de melhoria, diminuir o tempo em que as coisas ficam paradas e ajustar estimativas.

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

Publicado em

Processo de homologação, como é que é ? (Parte 3/3)

Depois de preparar o ambiente aonde acontecerá a homologação é necessário verificar conforme o cenário qual será a estratégia de execução, dependendo do tamanho dos sistemas mais de uma área de negócio precisará dar o sinal verde, precisamos organizar isso através da elaboração de um plano.

Um plano de homologação precisa ser elaborado desde o início do projeto aonde todas as pessoas necessárias precisam ter ciência que nesse momento serão acionadas. Um erro muito comum é que haja essa comunicação na reta final do projeto e dessa forma fica mais difícil que todos consigam se planejar para estarem a disposição no momento necessário, causando atrasos.

Quando falamos dessas necessidades, não estamos falando apenas da área de negócio, mas de pessoas e recursos de todas áreas que precisam contribuir de alguma forma para que a homologação possa ocorrer (criação de banco de dados, questões de hardware, configuração de ambientes, migração de dados, dentre outros), incluindo pessoas que estão envolvidos na execução do próprio projeto, o planejamento da homologação deve ser iniciado juntamente com o próprio projeto, isso é fundamental e deve evoluir conforme o projeto avança.

Existem muitas formas de executar, porém as decisões precisam ser tomadas conforme o cenário e as restrições colocadas. Tipicamente o que acontece, com o objetivo de ganhar tempo, é a montagem de algumas frentes que executarão a homologação em paralelo, porém para fazer isso precisamos conhecer quais são as dependências e como será a divisão para que o sistema possa ser validado.

Por isso a necessidade de criar o plano desde o início do projeto, para que haja tempo hábil de se conhecer quais recursos serão necessários para cada assunto, deixar tudo isso para o final é a fórmula para a bagunça.

Veja o exemplo do caminho a percorrer para validar o funcionamento de cadastro de produto em um site de e-commerce:

  1. Cadastro de Produto
  2. Geração do Pedido de Venda
  3. Recebimento de Mercadoria
  4. Incremento do Estoque
  5. Precificação do Item
  6. Produção do SKU (Colocar informações e imagens para aparecer no site)
  7. Ativação
  8. Disponibilização de cálculo de Frete
  9. Fechamento de Compra
  10. Envio para ERP
  11. Faturamento
  12. Geração de Nota Fiscal

Bastante coisa não é, agora imagine planejar como irá testar tudo isso apenas no final do projeto, veja que a cada passo dependendo do que precisa ser homologado vai ter uma abordagem diferente, por exemplo, como o teste é do cadastro de produto, não preciso neste momento validar se o cálculo do frete está correto, só precisamos que o recurso esteja disponível de forma que o teste possa ser executado até o final com as variações necessárias para validação.

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

Publicado em

Você sabe a diferença entre Erro, Defeito e Falha !?

Vamos dar uma passada em principios elementares de teste de software, vamos analisar qual é a diferença entre Erro, Defeito e Falha.

O Erro é um engano cometido por uma pessoa, pode ser um erro de lógica cometido durante a codificação por exemplo, entretanto um erro pode acontecer em qualquer fase do desenvolvimento, erros de sintaxe, tratamento de erros, erros de cálculo, erros de interface de usuário e etc.

Na tratativa de um bug sempre devemos buscar a causa raiz para eliminar o problema, precisamos descobrir o erro e eliminá-lo.

O Defeito demonstra desvios que revelam o não atendimento dos requisitos especificados impedindo que o software entregue o resultado planejado, consequência de um erro impetrado de alguma forma no software.

A Falha é a consequência de um defeito, um comportamento incorreto que se manifesta durante a utilização do software, ou seja nem todos os defeitos resultam em falha, se essa parte do código por algum motivo não for executado nunca saberemos dele.

  • Resumindo

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

Publicado em

Velocity x Débito Técnico

É comum times que priorizam a velocity (soma dos pontos entregues ao final de uma sprint) não considerando qualidade e a completude dos itens no afã de entregar tudo que foi planejado.

Quando isso acontece, a velocidade atribuída ao time não é real, pois no caminho os débitos técnicos surgem se acumulam gerando um backlog informal que em algum momento precisará se resolvido, afetando exatamente a velocidade do time já que a capacidade de entrega será diminuída, com o passar do tempo.

Tipicamente ao implementar as histórias subsequentes existirá a necessidade de fazer trabalho adicional relacionado aos débitos técnicos existentes conforme a evolução dos trabalhos.

Na maioria dos casos a falta de transparência no time scrum permite que o débito técnico seja criado e mantido durante o projeto.

Ou seja a velocidade “oficial” passa a não ser real pois devido aos problemas que deverão ser tratados durante as sprints, em algum momento o planejamento não poderá ser mais cumprido, e se chegará a conclusão que itens entregues no passado não estavam realmente prontos, é melhor controlar o passo agora para não tropeçar depois, mantenha a transparência.

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

Publicado em

Não se engane, uma boa arquitetura de sistema é fundamental !!!

Como sabemos existem algumas fases no desenvolvimento de software que precisam ser consideradas para a construção de sistemas de forma organizada não importando se estamos falando de ágil ou cascata.

Uma das questões contidas no planejamento de desenvolvimento de um sistema é a arquitetura, tem a missão de linkar uma ideia (requisitos) a um plano de alto nível de como um sistema deverá ser implementado.

No momento de determinar como será a solução temos que levar em consideração os requisitos não funcionais como por exemplo a manutenabilidade, que determina facilitar as intervenções futuras no produto, é necessário considerar todos os requisitos envolvidos para que se planeje uma solução equilibrada, itens como segurança e performance por exemplo que podem conflitar.

Seja previdente, antes de iniciar os trabalhos de implementação verifique a solução de arquitetura elaborada inicialmente com o time e evite sofrimentos futuros.

Divida um sistema grande em sistemas menores (sub-sistemas e módulos) isso simplifica as tarefas de desenhar e dar manutenção, fica mais fácil encontrar problemas e escalar a solução.

Veja que a arquitetura de um sistema não é algo que se pode corrigir depois de implementada, ou seja, boa programação não resolve os problemas proporcionados por uma arquitetura inadequada.

Imagine construir um prédio e após levantar alguns andares descobrir que existe um problema na fundação, ai já era, precisa derrubar tudo e construir de novo, então sempre valide a solução de arquitetura sugerida com os envolvidos e seja mais feliz.

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

Publicado em

Processo de homologação, como é que é ? (Parte 2/3)

Antes de iniciarmos uma homologação precisamos nos certificar que uma série de coisas tenham sido feitas para que não haja impactos no planejamento previsto com a descoberta de problemas que deveriam ter sido resolvidos nos testes dos times.

Cada time envolvido precisa realizar os testes relacionados ao seu escopo, é recomendável que haja um ambiente aonde os incrementos possam ser integrados e façam conexão com sistemas que compõem a solução como um ERP ou um TMS por exemplo:

  1. Testes unitários;
  2. Testes de regressão;
  3. Testes automatizados;
  4. Testes integrados (quando possível);
  5. Testes de performance;
  6. Testes de segurança;
  7. Testes de carga;
  8. Testes de usabilidade;
Os times precisam garantir a integridade do seu incremento passando por todos os passos necessários conforme a natureza da sua demanda.

Quantos mais testes forem feitos no ambiente integrado (“pré-homolog”) pelos times melhor, deve haver um responsável para organizar as subidas para esse ambiente de forma a garantir sua integridade e disponibilidade, assim todos poderão executar as validações e fazer os ajustes oriundos dos apontamentos que surgirão, não se pode garantir que todos os problemas sejam eliminados porém essa prática garante maior robustez ao incremento do programa para a homologação.

Apesar de exigir grande esforço de organização é de extrema importância que aconteça, caso esses passos não sejam realizados, passamos a atribuição dos testes para os responsáveis pela homologação juntamente com a área de negócio, o que é extremamente contraproducente, vamos parar por aqui, continuamos no próximo post.

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