scrum

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

José Carréra Agilidade , , , , ,

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.

Imagine um mundo SEM bugs no software

José Carréra Agilidade, Programação, Testes de Sw , , , ,

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?

José Carréra Testes de Sw , , , ,

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

José Carréra Agilidade, Tudo , , , , ,

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

José Carréra Agilidade, Programação, Testes de Sw , , , , , , , ,

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 minutos e Histó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.”

Exemplo PPT

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!

José Carréra Agilidade, Tudo , , , , ,

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

Thiago Burgos Agilidade, Tudo , , ,

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.

Um projeto pode ser ágil sem SCRUM ou KANBAN?

Thiago Burgos Agilidade, Tudo , , ,

Hoje em dia muito se fala sobre Scrum, Kanban, e estes conceitos estão realmente na moda atualmente. Primeiramente gostaria de dizer que não tenho nada contra o Scrum ou o Kanban, muito pelo contrário, uso Scrum a algum tempo e percebo no dia-a-dia os benefícios de tais práticas.

E então chegamos na palavra que eu queria chegar: Prática. Tanto o Scrum quanto o  Kanban e também o XP (eXtreme Programming) são práticas comuns (formas de fazer, de conduzir) comuns no mundo ágil. Muitas pessoas param por aqui quando estão falando sobre desenvolvimento ágil, mas uma pergunta importante precisa ser respondida: O que faz uma metodologia/prática ser considerada ágil? Nesse momento então chegamos ao ponto crucial que são os princípios e valores que estão por trás do que se considera ágil. Todas as práticas que se consideram ágeis é porque valorizam os pontos levantados no manifesto ágil:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Sabendo agora que existem princípios por trás de determinadas práticas, podemos então responder a pergunta se um projeto pode ser ágil mesmo sem utilizar Scrum ou Kanban, e a resposta é ‘SIM’! Basta que estejamos ligados a esses princípios.

Sendo assim, o contrário também pode acontecer: Você pode “utilizar” Scrum, ter post-its na parede, dividir seu projeto em iterações (sprints), fazer Scrum Daily Meetings e ainda NÃO SER ÁGIL!

Então sabemos mais importante do que Scrum ou Kanban, são os principios e valores por trás dessas práticas. No próximo post vou tentar detalhar mais o manifesto ágil e explicar melhor esse texto que só tem 4 linhas mas é enorme.

O Desafio do Sprint Planning 2 no Scrum

Thiago Burgos Agilidade, Tudo , ,

Uma boa sprint começa com um bom planejamento!

Para quem não está familiarizado com o scrum, no fluxo normal  nós temos dois passos que iniciam a execução da sprint chamados “Sprint Planning 1” e “Sprint Planning 2” (representados na imagem acima pelos dois primeiros blocos de fundo verde).   No Sprint Planning 1, é onde acontece a escolha de quais itens de backlog (IBL) serão feitas na sprint. Nesta reunião é muito importante a presença do product owner pois ele é um dos principais responsáveis pelo roadmap do produto/projeto sendo desenvolvido, na grande maioria das vezes ele que tem o conhecimento do negócio e que tem a visão mais acertada de onde quer que o produto/projeto chegue. Essa escolha das IBL’s é feita de pelo time todo, ou seja, todo o time tem que concordar que terão condições de implementar aquelas estórias escolhidas. Uma vez escolhidas as estórias que serão feitas na sprint, chega o momento da Sprint Planning 2…

Na reunião de “Sprint Planning 2” todo o time concentra seus esforços em quebrar aquelas IBL’s (estórias) em unidades menores de trabalho que são as conhecidas Tasks, representadas por post-its, e que estão eternizadas na imagem de uma parede cheia de post-its (nada contra, mas tenho pena das árvores 😛 vamos começar o movimento #RecyclePostIts). Bom, é nesse momento que acontece a explosão de tarefas, a sprint começa sem ter nenhuma tarefa a ser feita e na sprint planning 2 as tarefas são levantadas. A importância dessa fase do scrum é a seguinte: O que você levantar como tarefa aqui vai guiar seu desenvolvimento da sprint toda (e é claro que você pode lembrar/criar mais atividades no decorrer da sprint, mas essa visão inicial ajuda muito e já pode antecipar alguns problemas que poderiam acontecer).

É aí que aparece a pergunta: Mas como eu quebro as estórias em tarefas?  Qual a granularidade? E é justamente para tentar responder essas perguntas que eu vou tentar listar algumas dicas ou instruções de como quebrar as tarefas.

  • 1) Granularidade grossa: Uma das primeiras recomendações para a quebra de tarefas é sempre criar tarefas que possam ser feitas em 1 dia de trabalho (ou menos), caso contrário é melhor quebrar ainda mais a tarefa com o objetivo que ela caiba em 1 dia de trabalho. O objetivo desta dica é facilitar o gerenciamento das tarefas, e também poder visualizar o trabalho diário no burndown, que nesse caso vai se mover dia a dia, ao invés de ficar parado uns dias e depois se mover.
  • 2) Granularidade fina: O ideal para começar é tentar lembrar de cada detalhe, e transformar cada detalhe em uma tasks (lembrando que para que isso aconteça é preciso uma análise detalhada da estória a ser desenvolvida, levando em consideração todos os pontos possíveis: criação de classes, design, design gráfico, prototipação, testes, etc, etc, etc). Cada detalhe então vai virar uma task e isso facilita a vida de quem desenvolver a estória pois as tarefas já são quase que um guia e a finalização das tasks da estória simbolizaria que não falta mais NADA para aquela estória. Ex.: Se você sempre acaba a estória e vê que a equipe não fez uma validação javascript em um formulário, então na próxima sprint você já inclui a validação como uma tarefa (pois-it) a parte.
  • 3) Refinamento Contínuo: A idéia aqui é sempre adequar a quebra de tarefas a relidade da equipe. Como no exemplo citado no ponto 2, cada sprint servirá por base para refinar e definir melhor o nível de quebra de tarefas das próximas sprints. Se a granularidade foi muito fina, junta mais coisa em um tasks só (que façam sentido estar junto obviamente). Caso a granularidade tenha sido muito grossa, tenta detalhar mais cada uma e separar os detalhes em tasks individuais.

Bom, acredito que com essas coisas em mente vamos conseguir planejar melhor nossas sprints, e consequentemente finalizá-las melhor também! Você tem alguma dica a respeito da separação de tarefas no sprint planning? Deixa tua dica aqui como comentário 🙂 valeu!

Scrum Boards fora da parede

Thiago Burgos Agilidade, Tudo , , , ,

Times Ágeis Distribuídos? Parece uma coisa meio paradoxal, uma vez que metodologias ágeis pregam o time junto, unido, um ao lado do outro, de forma a reduzir ruídos de comunicação e até de forma a minimizar uma documentação extensiva (uma vez que estão todos juntinhos e sincronizados).

Sou a favor dessa proximidade física do time e entendo os benefícios, no entanto não podemos virar as costas para o movimento home-office ou mesmo para times distribuídos. Diversas empresas, como IBM, já adotaram home-office, e isso faz parte do dia-a-dia do desenvolvimento de software. Não é preciso nem comentar a respeito do desenvolvimento open-source, onde é praticamente todo distribuído, e ainda assim temos diversos casos de aplicações seguras, de qualidade e que são utilizadas em larga escala,  que foram desenvolvidas de forma distribuída.

Hoje em dia (e já a um bom tempo) temos diversas ferramentas que possibilitam esse desenvolvimento distribuído. Temos ferramentas para comunicação (email, msn, skype, etc…) , ferramentas para controle de versão/compartilhamento de arquivos/desenvolvimento paralelo  (svn, git, cvs, etc…), temos ferramentas de controle de bugs (mantis, trac, jira, etc…), e com o advento do scrum, hoje em dia também já temos ferramentas de scrum board (aquele quadrinho na parede cheio de post-it) on-line, que podem ser acessados pela web.

Como agora eu vou precisar trabalhar num time que utiliza scrum, e vou estar distante do resto do time, comecei a dar uma olhada em algumas ferramentas free de scrum board para começar a testar alguma.

Fiz uma pesquisa básica no velho google e achei algumas opções, mas procurei filtrar as que fosse de graça 😛 As opções que eu selecionei são as seguintes: Project Cards (esse aqui é integrado no eclipse, então não é bom pra gerentes e o povo que não usa eclipse) , FireScrum (bem legal, feito em flex, conheço a turma que trabalhou nele, disponibiliza um dashboard como o da figura ao lado) e SeeNowDo que eu vou falar um pouco mais adiante.

Bom, dentre esses o que me chamou mais a atenção foi o SeeNowDo, pelo simples motivo que oferecia tudo aquilo que eu procurava, gratuito, e rápido de utilizar. Ele oferece o dashboard do scrum (como cores diferentes para post-its de categorias diferentes), permite gerenciar múltiplos projetos, cadastro de sprints/estórias/tasks de forma simples e intuitiva, disponibiliza também o burndown chart das tasks cadastradas, e permite a transição das tarefas entre as colunas do quadro(TO DO/DOING/DONE) via drag and drop.

Ah, só tem um probleminha, você tem que utilizar a base de dados deles, pois não é possível fazer um download e instalar no ambiente da sua empresa/projeto. Então se houver alguma questão de confidencialidade no seu projeto, não é muito legal armazenar todas as atividades do projeto numa base on-line.

É isso, vou continuar minha pesquisa e ver se encontro outras ferramentas legais para scrum boards.

PS. Vale lembrar que tirar os post-its da parede e colocar numa ferramenta dessas é uma atitude também Verde (ecologica).

Menos post-its = menos papel = menos árvores derrubadas.