O SEMAT (Software Engineering Method and Theory) foi fundado em 2009 para ajudar a resolver diversos problemas que a indústria vem enfrentando. Seu primeiro passo foi fornecer uma fundação (chamada de Kernel) que irá suportar todo o pensamento de software daqui em diante, independentemente das práticas e ferramentas utilizadas. Com esse kernel, é possível entender se o processo, seja ele ágil, cascata ou qualquer outro, está atendendo as áreas consideradas pelo grupo como essenciais: Os chamados Alphas. Esses Alphas são divididos em temas e se relacionam entre si das mais variadas formas, como podemos ver na figura a seguir.

Mais informações sobre o modelo, os estados e os Alphas podem ser obtidas no guia de referência, mas farei uma breve descrição de cada um deles a seguir:

Cliente:

Área que se preocupa em saber se o time entende os stakeholders e a oportunidade que está sendo endereçada

• Oportunidade: As circunstâncias que fazem apropriado a criação ou alteração do sistema em questão.
• Stakeholders: As pessoas, grupos ou organizações que afetam ou são afetadas pelo sistema.

Solução:

Área que se preocupa  em saber se o time estabeleceu um entendimento conjunto dos requisitos e implementou um sistema capaz de atender os mesmos.

• Requisitos: As restrições que o sistema deve atender para endereçar a oportunidade e satisfazer os stakeholders
• Sistema de Software: O sistema como um todo, composto de software, hardware e dados

Endeavor (Traduzido livremente para esforço):

Área que se preocupa com o time, sua maneira de trabalhar e com o trabalho a ser feito.

• Trabalho: As atividades envolvendo esforço (mental ou físico) com objetivo de alcançar o objetivo
• Time: O grupo de pessoas engajado no desenvolvimento, suporte e gerência do projeto
• Maneira de Trabalhar: O conjunto de práticas selecionado que guiará o time e ajudará no trabalho

Cada um desses alphas possuem um estado a ser determinado pela equipe, utilizando a técnica denominada de Progress Poker. Esse método foi criado para ser rápido de ser executado e prover valiosa informação sobre o projeto de uma forma geral. O objetivo é que a equipe avalie cada Alpha, os estados que o mesmo possuem e entre em um consenso da situação atual naquele quesito.

É importante avaliar os itens que não foram atendidos porque são eles os pontos a serem atacados para a melhoria do processo.

Para verificar na prática essa técnica, utilizamos em um dos nossos projetos e obtivemos o seguinte resultado:

Como podemos ver, estamos bem posicionados em relação a Cliente (Oportunidade e Stakeholders) e Solução (Requisitos e Sistema de Software) mas pecando um pouco na área de Esforço (Time, Trabalho e Maneira de Trabalhar).

Sabemos que a causa dessa situação se deu pela entrada de diversos membros novos na equipe que ainda não haviam internalizado as práticas e atividades que a empresa executa. Esse foi o foco de maior trabalho para que o cenário identificado fosse revertido.

Em relação as outras duas áreas, é satisfatório perceber que bons resultados estão sendo obtidos e as práticas adotadas continuam sendo mantidas.

Faça você também a avaliação do seu projeto e deixe um comentário com a sua impressão!

The post SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Em sua apresentação, baseada no conhecido livro Code Complete, Rodrigo apresentou que a diferença de tempo entre desenvolvedores para encontrar a fonte do problema pode variar de até 20 vezes. Para reduzir o tempo de desenvolvimento perdido com essa tarefa, é de extrema importância saber as práticas que facilitam localizar os defeitos. Os passos descritos são simples, no entanto de extrema importância para se realizar o Debug com eficiência. A idéia é aplicar o método científico ao cenário de depuração, como descrito brevemente nos passos abaixo.

1. Estabilize o erro – Procure encontrar os valores de entradas e as condições em que o problema ocorre.

2. Localiza a causa do erro – Formule hipóteses, realize o teste delas até que consiga encontrar a fonte do problema

3. Corrija o defeito – Realize a correção. Cuidado! 50% das vezes em que um erro é corrigido, outro é colocado no lugar!

4. Teste – Realize o teste para verificar se o erro foi mesmo corrigido. Nesse momento, além de testar manualmente, porque não criar um teste automatizado para garantir que a situação nunca se repita?

5. Procure erros semelhantes – Identifique cenários parecidos e códigos semelhantes em que o defeito também possa ter acontecido.

​

Uma prática que costuma reduzir muito o tempo para se encontrar ou corrigir um problema é apresentar para a equipe os sintomas e qual é o objetivo final do código. Baseado em experiências anteriores, os outros membros da equipe podem formular hipóteses e acelerar em muito o processo de depuração. Em alguns casos é até possível que a equipe decida por uma mudança de estratégia e realize uma alteração maior do código buscando melhorar a manutenção e a flexibilidade.

No entanto, ao levar o problema aos outros desenvolvedores, fique atento a forma com que o mesmo será levado. Muitas vezes, fazer a pergunta certa é essencial para uma resposta rápida. E esteja preparado para responder uma simples pergunta como: “O que você já tentou?”. Essa pergunta é tanto válida para a identificação do problema quanto para a solução. Saber explicitar seus passos até então e seu conhecimento sobre o assunto questionado é importante para evitar que os demais ofereçam solução triviais ou não aplicáveis para o caso. Para entender mais sobre assunto, recomendo a leitura desse post (em inglês): whathaveyoutried.com

A depuração é um trabalho que sempre existirá durante o desenvolvimento de software. Portanto, possuir boas técnicas e ferramentas é essencial para evitar tempo desperdiçado e garantir uma maior produtividade dentro da equipe. E você, qual a sua experiência com o assunto? Deixe seu comentário com práticas, dicas ou dúvidas para continuar a discussão!

The post Boas práticas de depuração appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

No post de hoje iremos falar um pouco sobre prototipação. O motivo do interesse no tema é um caso real que vivemos na empresa durante esses últimos 3 meses. Queriamos criar algo novo, um produto para colocar no mercado. No entanto, todos sabemos que levar um produto pronto, completo e testado ao mercado demora tempo e não é possível saber se a aceitação do mesmo será boa. Por isso decidimos por criar um protótipo para amadurecermos a idéia, provar o conceito e conseguir investidores.

A prototipação de software consiste em criar algo mais consistente que uma simples descrição de um caso de uso e que não demore tanto quanto o sistema inteiro. Exemplos básicos de protótipo são as telas de um sistema. As mesmas podem ser desenhadas antes mesmo das funcionalidades serem introduzidas. Dessa maneira, o usuário pode validar se a tela está de acordo com o seu negócio e se atende as suas expectativas. Essa técnica, quando bem utilizada, reduzem custo, evitando retrabalho, e aumenta a qualidade do produto.

Existem prototipações evolutivas e descartáveis. A primeira consiste em evoluir o protótipo, fazendo os ajustes e incrementando novas funcionalidades até que o sistema esteja construído. O sistema parte do protótipo como base. A prototipação descartável é também é usada para validar e verificar os requisitos, mas sua estrutura de código não será reaproveitada na construção final. Muitas vezes isso ocorre porque o protótipo é feito em uma linguagem mais fácil e rápida e, no entanto, o sistema final requer uma linguagem mais robusta para sua implementação final. O protótipo, mesmo quando descartável, não é perda de tempo ou trabalho jogado fora. Ele é uma potente ferramenta para evitar divergências entre produto idealizado e produto final.

No nosso caso, a prototipação foi um sucesso. Executamos um projeto Scrum para a criação do protótipo e fomos aprendendo junto com a criação do sistema. O protótipo foi sendo adequado à necessidade do mercado e conseguimos provar o conceito em um tempo muito menor do que o necessário para criar o sistema todo. Isso é de extrema importância para apresentar aos clientes, que sentem muito mais segurança em apostar na idéia ao ver o sistema funcionando, mesmo que com funcionalidades limitadas.

Realizar um protótipo de software é um recurso poderoso que auxilia na verificação e validação dos requisitos. É importante debater se a prototipação será evolutiva ou descartável antes de começar o projeto. De qualquer forma, boas práticas de programação devem estar sempre sendo adotadas porque agilizam o processo e aumentam a qualidade e a flexibilidade do código final.

The post Prototipação de software appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

 Quando falamos sobre métodos ágeis, a comparação com os métodos tradicionais é inevitável. Esse é um assunto muito discutido e muito interessante. Apesar de diferentes, é possível notar objetivos convergentes nas duas linhas. Traçar um paralelo, sempre que possível, é importante para facilitar o aprendizado da nova metodologia e mostrar que muitos dos objetivos não mudaram. Hoje iremos falar sobre a melhoria continua.

Para os praticantes e estudiosos do PMBOK, o termo “Lições aprendidas” deve ser comum. Ao final de um projeto , sendo ele concluído com sucesso ou não, é necessário documentar os erros, acertos, feedbacks, novas competências adquiridas etc. para que você possa buscar o aumento da sua eficiência no próximo projeto. No planejamento de uma nova empreitada, as lições aprendidas anteriormente devem ser estudadas para definir a melhor equipe, o melhor método e a melhor tecnologia para atacar esse novo desafio.

Essa prática, embora altamente benéfica, é muitas vezes ignorada ou esquecida. Após o aceite final, o projeto é dado como concluído e as lições aprendidas muitas vezes são negligenciadas. As vezes por falta de tempo, outras pela cultura organizacional.

Em paralelo, no Scrum existe a Reunião de Retrospectiva, que ocorre ao final de cada sprint e incentiva a equipe a externalizar e registrar tudo o que considerou bom, para ser mantido, e ruim, para ser melhorado. Essa prática é utilizada para incentivar a equipe a buscar o constante aprendizado e evolução. A Sprint curta permite que o tempo entre uma reunião e outra seja pequeno, possibilitando aos participantes que lembrem com mais clareza os pontos que julgaram relevantes para serem documentados. Essa reunião é de extrema importância para o Scrum e a sprint não pode terminar sem que ela tenha sido realizada.

Os pontos levantados em cada retrospectiva devem ser levados em consideração já no planejamento da próxima Sprint. Afinal, quanto mais rápida for a implementação das soluções levantadas mais rápidas serão obtidos os benefícios dessas melhorias.

Quando estudamos métodos ágeis mais a fundo, podemos perceber que muitos dos conceitos e dos objetivos das metodologias tradicionais não são ignorados. Muitas vezes, a maneira de se executar determinados passos é apenas alterada, mas o benefício buscado é o mesmo. Espero que tenha mostrado a você a importância da melhoria contínua, que é incentivada tanto pelas metodologias ágeis quanto pelas metodologias tradicionais. Além disso, espero ter mostrado que as metodologias não são diametralmente opostos no final das contas. O comparativo entre as duas metodologias é um assunto muito interessante que pretendo continuar tratando nos próximos posts. Deixem suas sugestões nos comentários. Até a próxima!

The post Lições aprendidas no Scrum appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.

Converso com muitas pessoas sobre o Scrum e obtenho as mais diferentes reações. Desde entusiastas aos mais céticos, uma reação muito comum é “Meu chefe nunca vai concordar com isso”. Fico pensando porque essa reação é maioria e uma das explicações que eu acredito é a drástica mudança de desenvolvimento que o Scrum propõe quando comparados as outras metodologias, chamadas de tradicionais. Quando colocadas lado a lado, encontramos focos e valores diferentes.

Uma grande dificuldade na implantação do Scrum é a mudança de hábito e de cultura da empresa. Muitas vezes, a cultura existente é centrada no plano, ou seja, dá mais valor aos procedimentos e métodos bem aplicados do que o valor gerado pelo resultado. Essa filosofia é chamada de desenvolvimento movido ao plano, onde é dada muita importância aos artefatos bem construídos e etapas bem realizadas. Esse tipo de desenvolvimento é muito difundido por diversas metodologias e existem diversos motivos para elas continuarem existindo.

O Scrum se encaixa em outro tipo de desenvolvimento: O desenvolvimento centrado em valor. O seu objetivo está em agregar valor ao cliente. Toda a estrutura do framework está montada para permitir responder rapidamente a mudanças e se ajustar ao desejo do cliente.

No Scrum, o planejamento é considerado muito importante: Ter uma visão do produto é essencial. No entanto, o plano, a maneira que será executado para atingir o objetivo esperado, não é. Esse plano pode, e deve, ser alterado caso o objetivo mude, buscando atender melhor aos desejos do cliente. Dessa maneira, ele está mais preocupado em fazer o software certo do que fazer certo um software.

Podermos perceber nesse ponto que uma grande dificuldade na implantação do Scrum é essa mudança da maneira de pensar da organização. No manifesto ágil é descrito o que as metodologias ágeis consideram mais valiosos. É importante perceber qual o grau de concordância que a sua empresa tem com esses valores para antecipar a dificuldade que será adotar o Scrum.

A primeira adoção do Scrum é sempre traumática. Nesse ponto, acredito que seja melhor adotar em pequenos projetos ou até mesmo dentro de um pequeno setor como experiência. A supervisão de pessoas que já adotaram a metodologia antes com sucesso é muito importante para aumentar a chance de êxito e tornar a metodologia bem vista diante toda a empresa.

The post Diferenças entre valores ágeis e tradicionais appeared first on Blog ScrumHalf - Scrum e Agilidade - Software - Brasil.