Aprenda as funções do Scrum Master em 5 minutos

O Scrum é uma das metodologias ágeis mais utilizadas pelas empresas de TI, porém diversos pontos ainda geram dúvidas: Papéis, práticas, ferramentas, etc. Nesse contexto, cada equipe acaba realizando seus ajustes baseados na própria experiência e na natureza do projeto.

O Vídeo, abaixo, faz uma representação divertida do papel do Scrum Master na equipe. São apenas 5 minutos, que de maneira divertida traduzem os principais aspectos da atuação desse profissional.

As principais funções do Scrum Master destacadas pelo vídeo são:

– Assegurar a eficiência e comprometimento de todos ao Daily Meeting.

Evitar que o cliente interfira diretamente no trabalho da equipe durante a Sprint.

– Assegurar que a definição de “Pronto” esteja clara para toda a equipe. “Qualidade é chave!”.

Gerenciar o Quadro de Atividades do Scrum.

Remover impedimentos, permitindo a produtividade máxima da equipe.

Proteger e Liderar o time.

Consulte nossa seção de agilidade, e confira outros posts relacionados a Scrum.

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Anúncios

Imagine um mundo SEM bugs no software

Na indústria de software estamos habituados a ideia de que todo software possui defeitos e que pouco podemos fazer para mudar isso. No vídeo a seguir, de apenas 9 minutos, Jeff McKenna, co-fundador do Scrum apresenta uma visão radical: um mundo sem bugs no software. O vídeo foi extraído de seu próximo livro “Conscious Software Development.”

O vídeo é excelente e nos faz pensar principalmente na atitude em relação aos bugs que temos em nossos projetos. Segundo Jeff, não basta corrigirmos os defeitos encontrados precisamos entendê-los e aprender com eles, só assim construiremos sistemas SEM defeitos.

Assista ao vídeo. Em seguida, destaco os principais pontos abordados por McKenna.

 

Temos sistemas de gerenciamento de defeitos, realizamos triagens, mas será que em algum momento pensamos sobre o que eles são? ou como surgiram? como fazer para não surgirem mais?”

Segundo Jeff, temos sido muito complacentes com os defeitos, acreditamos que existem muitos, e que os mesmo são parte de todos os sistemas. Porém, o autor não acredita nisso e nos convida a imaginar um mundo SEM bugs de software.

“Podemos atingir números bem menores do que as pessoas consideram razoável, e isso pode ser feito de maneira simples”

McKenna indica que, a simples conscientização a respeito dos bugs já possibilita imensos ganhos. Precisamos entender porquê eles estão presentes e agir para evitar novas falhas.

Como diminuir a quantidade de bugs?

– Reduzir o tempo entre a introdução de um bug e sua correção

A medida leva em conta o momento no qual o bug foi introduzido no sistema e não o momento em que o mesmo foi detectado. Para isso é necessário utilizar as ferramentas de controle de código, assim, após identificado o motivo do defeito podermos voltar versões do código e identificar o momento em que ele ocorreu.

Olhando para o exato momento em que o erro aconteceu podemos aprender a escrever menos bugs. Porque esse é o verdadeiro objetivo.”

O objetivo não é encontrar mais bugs e a função dos analistas de qualidade não se resume a isso.

“Classificação e triagem de feitos são uma perda de tempo, em termos de aprendizado sobre como escrever menos bugs”

Segundo McKenna, pouco importa a severidade do defeito e suas características, pois geralmente o critério de correção está diretamente ligado a questões de negócio, como a importância de um determinado cliente. Logo, se estamos tentando aprender a escrever menos bugs, não há diferença entre os mesmos, sejam eles de alta ou baixa prioridade todos são comportamentos não esperados do sistema.

“Corrigir os defeitos era a atividade de maior prioridade”

Jeff, exemplificou suas recomendações com as seguintes práticas executada em um de seus projetos:

1- Sempre que um bug surgisse, a primeira pessoa que estivesse livre passaria a trabalhar no defeito. Onde, um profissional era considerado livre quando terminava a tarefa que estava executando no momento. Bugs possuem prioridade mais alta, que todas as demais tarefas ainda não realizadas. Desse modo, no máximo em alguns dias o defeito era analisado.

2 – Corrigir e entender o problema. A mais alta prioridade era a correção do defeito, associado a criação de novos testes automáticos. Porém, o mais importante é você falar porquê aquele bug estava lá, a razão do mesmo ter ocorrido.

“O que queremos fazer é encontrar o bug o quanto antes para que possamos consertá-lo o mais cedo possível e provar o aprendizado”

Para McKenna, temos o prazo máximo de até 6 meses da introdução de um defeito, para podermos aprender algo através de sua correção, após isso a oportunidade de aprendizado terá sido desperdiçada.

“O objetivo real é escrever software SEM defeitos.”

E para atingir esse objetivo, a principal característica que temos que desenvolver é a de olhar sempre para frente. Se ficamos sempre olhando para trás 6 meses, 1 ano, analisando um código que não vemos a muito tempo, isso literalmente é perda de tempo. Então, o que queremos fazer é olhar para frente a todo o momento e ter a atitude de ZERO defeitos.

“Um bug é algo que você esmaga imediatamente.”

Ao eliminar rapidamente os bugs encontrados acabaremos com tarefas, como a priorização de defeitos. Afinal, a quantidade de bugs pendentes será sempre pequena e desse modo o foco poderá ser maior no que está sendo construído.

Este é um vídeo para ser visto diversas vezes, e se conseguirmos absorver sua ideia central, penso que, poderemos melhorar ainda mais nossos processos e principalmente nossa atitude.

Conheci esse vídeo primeiramente no Software Testing Club, uma excelente fonte de informações para testadores, com bons textos e vídeos sobre a área. Espero que tenham gostado.

…………………………………………………………………………………………………………………………………………..

Agora você já pode acompanhar as novidades do BdB pelo Facebook, acesse e curta nossa página.

Por que os bugs graves surgem no último dia?

Os últimos dias que antecedem a uma entrega, com frequência, são repletos de correria, stress, pressão e claro bugs e mais bugs, que parecem intermináveis.

O que pode nos levar a pensar, que estamos cometendo os mesmos erros. Pensamos, refletimos, avaliamos e discutimos durante reuniões de Sprint Retrospective, que as vezes parecem intermináveis, o porquê de, mais uma vez, termos feito diversas horas extras nos últimos dias que antecederam a entrega.

Abaixo, listamos alguns dos fatores, que podem contribuir para esse número de bugs elevado, os quais podemos combater e assim, pelo menos, reduzir sua probabilidade de ocorrência.

Ausência de testes durante a sprint
Um dos problemas mais comuns que econtramos está relacionado a ausência de testes intermediários durante a sprint, sobrecarregando os testes de sistema realizados nos últimos dias e consequentemente proporcionando um número maior de CRs graves nos últimos dias.

Testes mal priorizados
Durante a execução do ciclo de testes de sistema, a priorização da ordem de execução também tem se mostrado um elemento fundamental para permitir que a maior parte dos defeitos graves sejam encontrados nos primeiros dias de execução.

Prazos irreais para testes
Sistemas gigantescos, com diversos requisitos de hardware, contando apenas com alguns dias para testes. Mais um grande motivo, para que o planejamento seja mal feito, a execução corrida e, desse modo, defeitos graves acabem não sendo antecipados ou até mesmo escapando.

Prazos irreais para correção
Desenvolvedores pressionados pelo “dia da entrega” implementando soluções, que nem sempre são a “melhor” solução, podendo, também, gerar novos bugs no sistema.

Especificação Deficiente
Estórias ou requisitos mal descritos, ausência de Product Owner ou Engenheiro de Requisitos, proporcionam dificuldades para desenvolvedores e testadores, o que acaba significando um maior número de defeitos.

Testes mal realizados
Diversos pontos da estratégia de testes podem precisar de uma boa revisão, é comum a ausência dos testes estáticos na documentação, a precariedade dos testes unitários, e a falta dos de componente. Criando, dessa forma, um enorme gargalo nos testes de sistema ou de regressão.

Porém, ledo engano nosso, achar que ao identificar e corrigir todos os possíveis problemas, nenhum bug grave será encontrado nos últimos dias. Na verdade, isso apenas minimiza o problema (o que é fundamental) e, hoje, não temos como garantir, que iremos conseguir antecipar todos os defeitos graves.

Enquanto houver tempo para testar, e o time possuir qualidade e disposição, devem haver bugs, inclusive graves…
E se adiarmos a entrega por mais alguns dias… continuaremos a encontrar bugs…

E você o que acha? Que outras medidas podem ser tomadas?

Acompanhe as novidades do BdB pelo Facebook, acesse e curta nossa página.

Em time que está ganhando não se mexe

Ao longo dos meus, ainda curtos, cinco anos de experiência numa empresa projetizada, felizmente, posso afirmar que tive a oportunidade de trabalhar com diversas equipes extremamente competentes tecnicamente. Porém, facilmente consigo destacar algumas, que além da qualidade técnica possuíam uma sinergia de trabalho natural, a qual permitia um melhor desenrolar das atividades.

Por dentro da Cabeça de Steve Jobs

Enquanto lia o livro “A cabeça de Steve Jobs”, escrito por Leander Kahney, o qual recomendo a todos que trabalham com TI ou que se interessam pelos produtos desenvolvidos pela Apple, diversos trechos chamaram minha atenção.  Logo nos primeiros capítulos o autor descreve o sucesso da Pixar e como ela se difere da forma tradicional de criar filmes em Hollywood. E o seguinte trecho me chamou a atenção, pois o pude relacionar diretamente com as minhas experiências pessoais.

 “O problema do modelo de Hollywood é que geralmente no dia em que você termina a produção é que você percebe que finalmente descobriu o jeito de trabalharem juntos”,

disse Randy S. Nelson, reitor da Universidade Pixar

 Já, a Pixar, o autor descreve que trabalha de maneira oposta:

“Os diretores, os roteiristas e a equipe técnica são todos empregados assalariados com grandes concessões de opção de compra de ações. Os filmes da Pixar podem ter diferentes diretores, mas em todos eles a equipe básica de escritores, diretores e animadores é a mesma, trabalhando como empregados da companhia.”

Podemos dizer que o mesmo cenário se repete na indústria de software. Durante cada projeto, a equipe se desenvolve (tecnicamente e pessoalmente), porém ao final do mesmo esse time é desfeito e todo o aprendizado que poderia ser potencializado é desperdiçado. Cada integrante, leva consigo os aprendizados, porém, nem todos poderão ser aplicados para a nova equipe.

Em outro trecho do livro, o autor destaca também a forma de trabalhar da equipe de designers da Apple, extremamente premiados e reconhecidos por sua competência. Jonathan Ive, líder da equipe traduz a forma de trabalho da seguinte maneira:

Mantendo uma equipe central pequena e investindo significativamente em ferramentas e processos, podemos trabalhar com um nível de colaboração que parece particularmente raro”, disse Ive

Ive diz que a equipe, pequena e íntima, é crucial para a criatividade e a produtividade.

Os benefícios de trabalhar com equipes pequenas, já podemos perceber ao seguir os conceitos do Scrum e das metodologias ágeis. Equipe íntima, ou seja, onde as pessoas se conhecem e confiam nas habilidades dos demais integrantes. E assim, talvez, conseguir criar um ambiente colaborativo que permita a criação de produtos de sucesso.

Então, será que não deveríamos refletir um pouco mais sobre essas afirmações? Acredito que manter, ao menos, a base das equipes que conseguem atingir um padrão de excelência parece sim ser uma boa alternativa e que pode trazer bons frutos para as empresas projetizadas. Vai mexer nesse time? E vocês o que acham? Em time que está ganhando não se mexe?

Nessa semana o BdB comemora seu primeiro aniversário, se você ainda não aproveitou os presentes de nossos parceiros, clique aqui e leia as instruções.

Aumentando a qualidade do software com apoio do Powerpoint

Como havia prometido no post – Apertem os Cintos, o Analista de Requisitos Sumiu!, descrevo hoje como abordávamos o gerenciamento dos requisitos (estorias) num dos projetos desenvolvidos no C.E.S.A.R. gerenciado com SCRUM. A mesma, já foi inclusive mencionada por Marcelo Nunes no post Mapeando Requisitos em Projetos Scrum.

Espero que de alguma forma, nosso exemplo, possa ser útil a vocês, para que possam tentar aplicá-lo em seus projetos ou que ao menos possa servir de referência para que apliquem suas ideias em seu ambiente de trabalho e com a cooperação dos colegas possam construir soluções para seus problemas. Se você ainda não conhece bem o Scrum, consulte os seguintes links: Scrum em 10 minutosHistórias de Usuário

O que descrevemos nas próximas linhas, como uma abordagem, surgiu naturalmente durante o projeto e foi sendo aprimorado, com o simples intuito de garantir que as estórias selecionadas para a próxima sprint fossem compreendidas de maneira uniforme por toda a equipe, e atingindo esse objetivo outros benefícios eram proporcionados, como: Diminuição do número de defeitos, maior satisfação do cliente, melhor comunicação entre os membros da equipe, entregas realizadas no prazo correto, além de poder servir como guia para novos integrantes da equipe, entre outras vantagens.

A partir do momento em que as estórias haviam sido selecionadas para a nova sprint, os seguintes passos eram iniciados:

  1. Detalhar estórias da sprint 
  2. Discutir o PPT com toda equipe
  3. Implementação da estória
No passo 1, as estórias selecionadas eram descritas através de slides, seguindo a prioridade estabelecida entre as mesmas. Desse modo as mais importantes eram liberadas com maior antecedência para as etapas seguintes. O slides deveriam ser simples e diretos, descrevendo o objetivo central da estória, geralmente continham esboço da interface e informações a respeito do escopo.
Abaixo, exemplificamos o uso dos slides para uma estória fictícia, descrita da seguinte forma: “Como um administrador do blog eu quero saber quais os posts mais acessados para que possa analisar o perfil dos visitantes.”

Já o passo 2, consistia de uma reunião com todo o time, onde o responsável pela elaboração do PPT explicava o funcionamento da estória. Sendo este o momento mais importante da nossa abordagem, o qual permitia um entendimento mais profundo da necessidade do cliente. Durante a reunião todos interagiam procurando esclarecer os detalhes que envolviam a estória, seus possíveis impactos em outras funcionalidades previamente implementadas, além de como a mesma deveria se comportar em determinados cenários.

Ao final da reunião, normalmente algumas mudanças no PPT eram realizadas em razão dos pontos levantados, e a partir desse momento o passo três podia ter continuidade, tendo agora como base também as informações disponíveis no PPT, facilitando o trabalho de desenvolvedores e testadores, através da diminuição da quantidade de retrabalho causado pelo diferente entendimento das estórias.

A abordagem utilizada por nós, atingiu o objetivo do projeto, garantindo que as necessidades do cliente fossem compreendidas pelo time e desse modo proporcionando entregas de maior qualidade. É importante, também, ressaltarmos que o fundamental para o sucesso da abordagem está diretamente ligado a troca de ideias e ao comprometimento com a qualidade, sendo o PPT apenas uma forma rápida e ágil para apoiar essa comunicação.

E o que não podemos nos esquecer, é que a utilização, melhoria e adaptação dos processos deve ser um ato contínuo, onde as características do projeto e das pessoas que fazem o mesmo precisam ser levadas em consideração.

Ficou interessado na abordagem proposta? Caso haja qualquer dúvida ou dificuldade ao tentar aplicá-la em seu ambiente de trabalho, entre em contato conosco.

Apertem os cintos, o analista de requisitos sumiu!

Todo analista de sistemas sabe da importância da correta identificação e gerenciamento dos requisitos de uma aplicação, e o papel fundamental que os mesmos representam durante todo ciclo de vida de um projeto.

Apertem os cintos, o piloto sumiu

Com o crescimento na utilização de metodologias ágeis, muitos dos problemas em relação aos mesmos foram minimizados, porém o problema está longe de ser considerado resolvido. Muito pelo contrário, não é preciso ter muita experiência em projetos de TI para perceber que diversas vezes os problemas encontrados no software têm origem nos requisitos(ou estórias) ou na falta deles e diversas são as causas para tais problemas. Onde, a principal causa talvez seja o fato do gerenciamento dos mesmos, durante um projeto, continuar sendo frequentemente menosprezado.

Apesar de impactar o trabalho de todos envolvidos em projetos de software (desenvolvedores, testadores, designers e até mesmo dos gerentes) os requisitos ainda são comumente relegados a segundo plano. Até o próprio assunto não é debatido com muita freqüência nas empresas e na internet, e com esse post tentaremos trazer um pouco mais o referido tema para o BDB.

Abaixo tentamos listar alguns dos problemas comumente encontrados por nós, focando, nesse primeiro momento, nos projetos que utilizam metodologias ágeis e versões adaptadas das mesmas:

Isso não funciona:

– Analista de requisitos inexistente:

      É comum e até indicado pelas metodologias ágeis que os profissionais tenham perfis multidisciplinares e possam atuar em diferentes papéis durante o projeto, porém isso muitas vezes é confundido e acaba gerando a eliminação de alguns especialistas, onde o caso dos requisitos é um bom exemplo de atividade, que cada vez mais é realizada por pessoas não dedicadas inteiramente a função e que não possuem os atributos requeridos para a mesma, assim temos engenheiros sobrecarregados e muitas vezes executando tarefas que não os agrada.

– Product Owner distante:

      No scrum o product owner é muitas vezes o responsável pela definição das estórias e por apoiar a equipe no esclarecimento de eventuais dúvidas a respeito do comportamento esperado das estórias escolhidas para a sprint. Porém, essa comunicação nem sempre funciona de maneira eficiente, fatores como a distância física, dificuldade em entender as responsabilidades do papel ou até mesmo os conflitos naturais que podem surgir da relação cliente X equipe podem criar barreiras que dificultam o trabalho da equipe.

– Entendimento das estórias:

     Mesmo quando temos uma comunicação eficiente com o product owner, ainda precisamos nos preocupar com a garantia de uma boa comunicação entre os membros da equipe, evitar ao máximo que as pessoas tenham entendimento diferente das estórias selecionadas, garantir que os mesmos compreendam a extensão e os detalhes que envolvem cada estória.

– Projetos longos:

      A medida que o tempo de vida de um projeto aumenta, diversos outros pontos começam a surgir e que podem dificultar o desenrolar das atividades, por exemplo, a necessidade por algum tipo de rastreabilidade entre os requisitos, atividade que dificilmente pode ser executada de maneira eficiente sem dedicação plena.

– Turnover:

A chave do sucesso dos projetos ágeis está na comunicação entre os membros da equipe, o conhecimento a respeito das funcionalidades do projeto passa diretamente pelos integrantes, onde alguns por possuírem determinadas habilidades, acabam se tornando referenciais técnicos, quando tratamos do comportamento correto da aplicação. Porém, frequentemente enfrentamos a rotatividade de pessoal, o que consequentemente leva a perda desse conhecimento, aumentando o grau de dificuldade para novas tarefas e realização de correções e melhorias.

– Cliente imediato não é o cliente final, logo como não documentar tudo?

Muitas vezes confundimos também a idéia de evitar o excesso de documentação encorajada pelas metodologias ágeis com documentação zero, o que para alguns projetos específicos pode fazer sentido e não gerar nenhum tipo de problema, porém de maneira geral dificulta a entrada de novos integrantes ou a correção de defeitos relacionados a estórias implementadas a algum tempo. Esse problema pode ainda se tornar maior quando nosso cliente imediato não é o cliente final, quase que eliminando a possibilidade de trabalhar focado nas necessidades imediatas e feedbacks do usuário final.

– Todo mundo quer ser ágil:

      A adaptação da metodologia ágil selecionada para as características da equipe de trabalho é essencial, porém ocorre também o erro comum de tentar aplicar métodos ágeis em todos os projetos, no entanto nem sempre eles são os mais indicados. Com isso surgem situações como projetos ágeis sendo guiados por um imenso documento de requisitos tradicional, repleto de casos de uso e quase nenhuma flexibilidade.

P.S. A partir dos 2 minutos o vídeo exibe apenas propaganda dos produtos da IBM.

Por enquanto, é melhor nem falarmos dos requisitos não funcionais, onde os problemas e dificuldades são ainda maiores.

No próximo post descreveremos algumas soluções que tem ajudado em nossos projetos. Participe comentando sobre problemas relacionados a requisitos enfrentados por você e sua empresa.

Links relacionados:

Vídeo explicando o Scrum

Vídeo descrevendo o problema com a definição do software através do documento de requisitos

Post Scrum master não pode ser o product owner

Para relaxar:

Review das funcionalidades de um website com South Park

o Mundo da Agilidade

Acabei de fazer uma apresentação sobre agilidade, e decidi compartilhar com vocês. O FOCO foi nos valores que o manifesto ágil listou, e não nas práticas, afinal esses valores que caracterizam um desenvolvimento ágil, e não práticas X, Y ou Z.

Apesar de falar sobre os VALORES, também falei sobre duas metodologias que considero muito boas que é o XP e o SCRUM.