agile

Cargo cult, eXtreme go horse e afins

Renato Molina Agilidade, Programação, Tudo , , ,

Depois de alguns anos escrevendo código, e também, observando códigos de outras pessoas, meus códigos antigos e código legado percebi alguns comportamentos e padrões entre o aptidão e/ou tempo de experiência X design do código das pessoas.

Investigando esses padrões, consegui entender melhor os “porquês” da incidência, em projetos grandes e bem financiados, de fenômenos como Cargo cult, eXtreme go horse, programação orientada a gambiarra e afins.

Contextualizando – Cargo Cult, descrito por Steven C. McConnell no livro Code Complete, é o fenômeno cultural observado em tribos indígenas/aborígenes, durante a segunda guerra mundial, que envolviam impactos entre duas civilizações, sendo uma moderna em aspectos tecnológicos e outra primitiva. Durante a guerra, soldados americanos necessitavam pousar em ilhas desertas para recarregar combustíveis ou armar mísseis, entretanto muitas dessas ilhas visitadas eram habitadas por esses povos. Ao ocorrer o choque das civilizações, os primitivos imaginavam que os soldados, com todo seu aparato, fossem deuses. Depois da partida da civilização moderna, os indígenas costumavam fazer rituais em determinados períodos do ano com o intuito de invocar os supostos deuses soldados, mudando assim o comportamento cultural/religioso do local.

Ao trazemos esse conceito para computação temos situações clássicas que vivemos no nosso dia a dia, talvez a mais popular seja : Ao perguntar a um desenvolvedor/gerente/engenheiro: – Para que serve esse pedaço de código? Ele te responde: – Não sei, mas não mexe aí! Pode parar de funcionar! Em outras palavras o desenvolvedor possui um tipo de ritual para realizar determinadas tarefas, como inserir código legado, bibliotecas, classes que não necessariamente são úteis para a implementação do mesmo, acarretando a incompreensão sobre o sistema de forma geral.

Para falar de eXtreme go horse temos que esquecer de qualquer boa prática, Scrum, Kanbam, Pair Programming ou qualquer coisa que lembre engenharia de software, isto é, se focar em escrever código e vencer o prazo. Infelizmente é uma realidade triste do mercado, que muitas vezes pode indicar falta de comprometimento do time e falta de alinhamento de interesses entre equipe/empresa ou má gestão do líder.

A verdade é que o caminho para esses cenários(caóticos) são convergentes podendo ser resumidos em falta de maturidade da parte do líder ou desenvolvedor, insegurança, pressão, contratos com prazos irreais, falta de comprometimento da equipe, etc. Muitas vezes esses motivos também podem acarretar um efeito dominó, piorando a situação exponencialmente.

Claro, podemos determinar inúmeras hipóteses para a solução do problema de desenvolvimento de software, entretanto, é fato que a solução está bem longe de determinar metologias rígidas ou mudar conceitos das mesmas. Temos que ir além, precisamos mudar conceitos, quebrar paradigmas, criar um time com determinação e com aptidão, mensurar e explorar potenciais, trabalhar com dificuldades, amadurecer a equipe e acima de tudo cair na real.

Teste está morto parte 2

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

Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.

A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.

Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.

Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.

Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.

O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.

Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.

Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.

Um produto errado é muito pior do que um produto com o comportamento errado.

A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.

E como podemos testar a idéia?

A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)

Alberto cita ainda alguns dos sinais observados, que o levam a crer no fim dos testes tradicionais.

Sinais do Testpocalypse:

– Diminuição no numero de contratações
– Comoditização dos testadores
– Saída dos antigos líderes e ausência de novos
– Mais e mais empresas partindo para o Post-Agile

Acompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)

Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.

P.S. Todas as imagens utilizadas estão nos slides da apresentação, disponível aqui.

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

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.

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.