Publicado em

Você sabe o que é OpenAPI !?

A OpenAPI Specification, é uma iniciativa para a criação de interfaces usadas ​​para descrever, produzir, consumir e exibir serviços RESTful, existem também ferramentas para gerar código, casos de testes e outros recursos necessários fornecidos pela iniciativa.

O principal argumento para a adoção da OpenAPI Specification é o histórico fundamentado no Swagger que existe a muito tempo dando a credibilidade e a estabilidade necessárias garantida pela grande comunidade e suporte existentes.

Com cenários cada vez mais complexos fazendo uso de APIs, há uma forte demanda por garantir as aplicações em relação a padronização.

Com cenários cada vez mais complexos fazendo uso de APIs, há uma forte demanda por garantir as aplicações em relação a padronização, é a peça que estava faltando para iniciativas como a de Open Banking por exemplo.

Grandes players apoiam diretamente a iniciativa e a OpenAPI pelo que tudo indica veio para ficar, entretanto é sempre importante analisar os possíveis impactos em sistemas existentes, a OpenAPI dá suporte a uma grande quantidade de linguagens, isso significa que sistemas implementados com linguagens específicas podem sofrer grandes impactos, vale uma detida análise antes de qualquer ação mais radical.

A OpenAPI oferece um rico framework entretanto é importante que se atente as boas práticas existentes e destacadas pela iniciativa, para que se possa construir melhores APIs, para mais informações visite www.openapis.org.

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

Publicado em

Definição de Preparado, use com bom senso !!!

A definição de preparado (Definition of Ready) é um acordo entre o product owner e o time de desenvolvimento que serve para orientar quando uma história está pronta para ser executada em uma Sprint.

A boa prática orienta que o Product Owner tenha um “estoque” de histórias preparadas equivalente a 3 sprints conforme a velocidade medida historicamente do time, assim quando houver algum imprevisto que evite a elaboração e o refinamento de novas histórias, não se corre o risco do time ficar parado.

Entretanto precisamos tratar com cuidado esse tema, pois o que se vê em algumas situações é o time utilizar a definição de pronto como escudo, afirmando que algo não pode ser iniciado devido a falta de alguma condição determinada na DoR, isso afeta a colaboração entre o time de desenvolvimento e o product owner.

O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva, não deixe que .
O time scrum deve exercitar os valores do Scrum como Abertura e Comprometimento para que a colaboração seja efetiva.

É necessário que se use o bom senso, uma definição de preparado pode ser estabelecida como um contrato e servir como uma referência. Porém não quer dizer que se alguma demanda não alcançar todas as características determinadas nesta lista, não se deva trabalhar na demanda.

Se o time tiver o entendimento sobre o que precisa ser feito com as informações disponíveis para execução, devemos seguir. Aproveite os benefícios da utilização da definição de preparado (DoR), mas não deixe que isso se torne uma parede entre o time e o PO.

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

Publicado em

Product Owner novo na área, o que fazer ?!

O ideal é que o Product Owner conheça do negócio do lugar aonde ele vai atuar, mas caso seja novo na área que vai atender, não é o fim do mundo, fique frio(a) e siga o procedimento.

O primeiro passo é começar a construir um relacionamento com os stakeholders, se reúna com as pessoas que possam falar sobre o tema que você vai precisar tratar, procure capturar com a maior precisão possível as expectativas do negócio.

Analise o mercado e esteja ciente das tendências, identifique os principais competidores, sendo eles diretos, indiretos, potenciais ou substitutos, conforme as características como qualidade dos times, marca, base de usuários e etc.

Comverse com as pessoas, e busque as informações disponíveis, assim será bem mais fácil, perguntar não ofende!!

Analise o backlog atual caso exista, conheça o time de desenvolvimento converse com eles, fornecerão informações valiosas para que você consiga montar sua visão sobre o cenário do qual está integrando. Trabalhando em conjunto com os stakeholders e o time de desenvolvimento o processo deve ser acelerado, boa sorte.

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 o que é Value Stream ?!

O value stream representa o caminho por onde as ideias trafegam até que a mágica aconteça, a entrega, o value stream é o mapeamento de fluxo de valor, uma técnica Lean para análise de processos e como sabemos existem muitos desafios e oportunidades de melhoria nesse interim, precisamos eliminar as atividades que não adicionam valor, essa é uma ótima técnica pois vai ajuda-lo a isolar, comunicar e quantificar de forma eliminar o desperdício otimizando o tempo de entrega.

O objetivo é mapear seu processo e analisar cada ponto em busca de alguma não conformidade ou oportunidades de melhoria, veja abaixo o desenho de fluxo exemplificando as fases do desenvolvimento utilizado por uma squad.

Tipicamente na transição entre as fases temos oportunidades que podem ajudar significativamente a dimunição do lead time e cycle time.

Então para iniciar este tipo de trabalho é muito importante que se conheça e se entenda as fases por onde uma demanda trafega em seu ambiente, para identificar os problemas e promover as melhorias é essencial que se conheça a dinâmica de como as coisas acontecem.

Considerando o fluxo da imagem acima, podemos verificar em uma situação hipotética que temos um gargalo no code review e então ao analisar a questão mais de perto se descobre que temos uma pessoa responsável por isso e que está sobrecarregada, uma das soluções possíveis seria por exemplo que todos o desenvolvedores do time fizessem o Code Review no código do colega, isso reduziria o tempo em que as demandas ficariam paradas nesse passo, a ideia é eliminar ou amenizar os gargalos.

Crie métricas que possam ajuda-lo conforme o cenário e fique de olho no Lead Time e o Cycle Time, a cada intervenção avalie se houve o efeito desejado nas medições.

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

Utilização da Meta da Sprint

A meta da sprint (Sprint Goal) é o objetivo determinado para uma Sprint a ser executada acordado entre o Product Owner e o Time de Desenvolvimento, tipicamente durante a Sprint Planning.

Vemos alguns times que não definem a meta para a sprint, veja que com a meta da sprint o time pode se orientar sobre quais atividades são mais prioritárias para que o time alcance o resultado esperado, o trabalho planejado no início da sprint é um forecast e muitas vezes apesar não concluir tudo o resultado estabelecido na meta pode ser alcançado.

Algumas vezes pode acontecer de o time não considerar uma meta para sprint realística e permitir que mesmo assim seja estelecida, é necessário que todos participem ativamente para que todas as questões sejam resolvidas de forma consensual estando bom para todas as partes.

A meta da sprint deve ser clara e inequívoca para todos os participantes do time scrum

O Scrum Master deve promover a transparência e ajudar a revelar quais são as questões que precisam ser resolvidas de forma que não haja problemas entre o time de desenvolvimento e o product owner, seja imparcial e 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

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 !!!