Todos os desenvolvedores de software possuem um mesmo objetivo: Entregar software com valor, rápido e com baixo custo. Esse é um objetivo aparentemente simples, mas que tira o sono da indústria e academia há décadas. Correndo atrás desse sonho está a área da Engenharia de Software, buscando oferecer ferramentas, práticas e estudos para que o desenvolvimento e manutenção dos produtos sejam mais eficientes. Mas já parou para pensar em quantas técnicas, padrões, frameworks etc. existem? Incontáveis soluções são oferecidas e devem ser adequadas a cada um dos casos. Independentemente das práticas utilizadas, uma pergunta tem que estar em mente o tempo todo: Como anda a engenharia de software do meu projeto? E, para responder essa pergunta, foi criado o SEMAT.

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 (Português) SEMAT – Como Anda a Engenharia de Software do Seu Projeto? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

The post Debugging your code appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 Software prototype appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

 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 (Português) Lições aprendidas no Scrum appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

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 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 pequena 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 ScrumHalf Blog - Agile and Scrum Software - Brazil.