Nova estruturação do Blog

Você que já conhecia o blog Bytes don’t Bite [BdB] já deve ter notado que o design do blog mudou mais uma vez, e como sempre, para MELHOR! Não só o design gráfico, mas também a usabilidade.

Você pode reparar que existe um menu superior que tem um link para cada uma das novas seções do blog, onde você pode ler assuntos do seu interesse mais facilmente. Com essa nova organização, as seções existentes hoje são:

GeralProgramaçãoAgilidadeTestes de SoftareLiderançaStart-ups

Essa divisão foi criada para que você possa navegar e encontrar conteúdo mais facilmente dentro do BdB.

Ah! Quase que esquecia, pra completar, também estamos com endereço novo: http://bytesdontbite.com 🙂 (lembrando que o antigo endereço ainda continua funcionando também!)

Enjoy!

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.

Quebrando as regras – O líder criativo

Esses dias estive refletindo bastante sobre como deve se portar um líder de equipe diante das mais diferentes situações. Qual deve ser a postura de um líder criativo? Deve ser inspirador ou deve focar em mostrar que possui a situação sobre controle?

Decidi procurar referências em livros e uma amiga me indicou um bastante interessante. Se chama “The Leader’s Guide to Lateral Thinkin Skills“. O livro faz um paralelo bastante interessante sobre como se porta um líder clássico e um líder que está preocupado com inovação e com a disseminação do pensamento criativo. Dentre as principais diferenças entre esses dois tipos de líderes, vou citar algumas que me chamaram a atenção.

creative

Líder clássico: Dirige, desprende maior tempo em questões operacionais do dia-a-dia do que em novas estratégias, dá a direção e as ordens, desmerece idéias e iniciativas sem prévia análise, fechado à críticas, etc…

Líder criativo: Inspira, desprender maior tempo à procura de novas estratégias e parceiros, faz perguntas, pede sugestões e delega, encoraja todos tipos de iniciativas e frequentemente implementa idéias, encoraja críticas construtivas, etc…

Posto isto, fica evidente que o líder criativo possui um perfil mais vanguardista e está mais inclinado a aceitar e lidar melhor com os riscos chegando ao patamar onde o risco torna-se um aliado à inovação. O resultado desse relacionamento tão peculiar com os riscos (lembrando aqui a importância de ter a maioria deles sobre controle e identificados), o líder criativo aposta pela quebra de regras para promover a inovação dentro da sua equipe. Pra algumas pessoas, esse tema não é novidade, principalmente quem mergulhou de fato no mundo das metodologias ágeis, mas eu acho que é uma temática que deve ser sempre reiterada e que é crucial nos projetos em que se deseja inovar.

break the rules

A partir da quebra de regras de um negócio foi que se conseguiu um maior nível de inovação em determinado setor. Um bom exercício para tal é tentar identificar todas as regras intrínsecas ao seu modelo de negócio. Após haver mapeado um número razoável, pondere quais das regras parecem ser descartáveis e tente jogar com esse modelo retirando-a do contexto. Um bom exemplo para tal foi executado pela Heinz, a fabricante de ketchups. Enquanto a maioria dos molhos de tomate da concorrência nos EUA possuíam uma consistência mais líquida, o molho Heinz era mais espesso e exigia que o usuário tivesse que bater no fundo da lata pra conseguir extrair o conteúdo da embalagem. Havendo identificado essa particularidade, ao invés de mudar a fórmula do seu molho, a Heinz decidiu investir em uma estratégia de marketing onde se definia que o bom molho de tomate era o espesso. A campanha foi um sucesso e a Heinz hoje é uma das líderes no setor.

Existem N outros exemplos onde a quebra de regras foi crucial para a inovação. Será que vocês arriscam dar mais alguns exemplos? Como funciona o jogo de regras na sua equipe? Comenta aí!

Incentivando uma briga

Por muitas vezes refleti se as pessoas, que trabalham com testes de software, devem ter habilidades de desenvolvimento. Não nego que possuir conhecimento do negócio é necessário para o profissional da área de testes. Mas, entender sobre a estrutura do que é testado, que antes de tudo é um software, também é importante.

James Whittaker, que já trabalhou com testes na Microsoft e atualmente trabalha na Google, escreveu um livro que demonstra algumas técnicas para se “quebrar” um software. As falhas exibidas são bem interessantes, e possíveis de serem atingidas em abordagem caixa-preta.

Como testador, pude experimentar algumas técnicas mencionadas no livro. Vou relatar sobre a aplicação de uma dessas técnicas em um projeto que trabalhei. No software desenvolvido, um usuário poderia criar menus que seriam acessados através de um servidor. Quando acessado um determinado item do menu, uma ação seria acionada. Uma das ações disponíveis era verificar o usuário que estava acessando o item e direcionar para outra ação.

Na imagem acima, quando um usuário A acessa o ITEM 2 do MENU, a ação 2 é chamada. Uma vez que a AÇÃO 2 identifica que é o usuário A, a AÇÃO 3 é acionada. Olhando para este exemplo, tendo em vista que uma ação de decisão envolve processamento, já é possível reproduzir a falha. A idéia é forçar um processo a ser executado várias vezes. Imagine uma ação parecida com a AÇÃO 2 no lugar da AÇÃO 3, apontando para AÇÃO 2 quando o usuário for A.

Agora, imagine o usuário A acessando o MENU pelo servidor. Ele tenta acessar uma vez o ITEM 2, vai para a AÇÃO 2, que o direciona para AÇÃO 3. A AÇÃO 3 o manda de volta para AÇÃO 2, que o manda mais uma vez para AÇÃO 3. Vai para AÇÃO 2… Deu pra entender que nunca vai parar? Bastaram algumas requisições feitas com o usuário A para ser necessário reiniciar o servidor, pois o serviço havia ficado indisponível.

No livro “How to Break Software”, James Whittaker demonstra falhas que podem ser provocadas tanto pela interface com o usuário como através de outro software. Ele ainda fala que muitos têm dificuldade em entender o ambiente em que o software funciona. Na experiência que tive com testes de software até o momento, me deparei com vários testadores que somente interagiam com a porção de botões, ou outros componentes visuais, que lhe eram oferecidos através de especificações. Tais testadores desconsideravam sistema de arquivos, componentes externos, sistema operacional, rede, relacionamento com outras funcionalidades, etc.

Com esse post, pretendo incentivar uma briga.

Testadores, aprendam onde os desenvolvedores deixam os bugs. Acreditem, boa parte das falhas de um software estão no código! Estudem formas diferentes de se encontrar os problemas. Entenda o sistema operacional, analise o código fonte do software, entenda de redes, estude as falhas dos frameworks utilizados, avaliem a segurança do produto (não usem a desculpa de que segurança é um requisito não-funcional), estudem tudo o que for válido para certificar a qualidade do software.

Desenvolvedores, vocês vão deixar? Vejam o que esses testadores poderão fazer com o código produzido por vocês! Se aproximem do pensamento dos testadores, vejam como eles agem. Desenvolvam o senso crítico. Dêem seu máximo para que falhas comuns não aconteçam. Estudem onde os bugs aparecem para poder evitá-los!

No final, essa disputa saudável, entre evitar e encontrar os bugs, é uma forma de se obter um software de qualidade e uma equipe em evolução contínua.

Mais um Colaborador para o Bytes Don’t Bite

É com grande prazer que anuncio a nova “contratação” do Bytes Don’t Bite!

Edwin Carlo, é desenvolvedor de software por natureza e engenheiro de testes por vocação e paixão! Edwin irá escrever sobre testes de software e  outras coisas mais.

É um grande prazer ver o time do Bytes Don’t Bite crescendo!

Edwin, seja bem-vindo, a casa é sua! 🙂

Agile Restrospectives – Bom tutorial

Recentemente tenho quebrado a cabeça em como melhorar as retrospectivas em meu projeto. Após aproximadamente 2 anos, as retrospectivas tendem ao tédio e o time não consegue pensar em fatos diferentes de problemas com infra-estrutura e eventuais horas-extras.

Pensando nisso, decidi dar uma olhada no que está sendo feito em retrospectivas para tentar obter resultados diferentes e um plano de ação mais conciso. @estherderby é uma das referências quando se fala de Agile Retrospectives e no vídeo abaixo ela e uma companheira deram uma boa apresentação em como montar uma reunião de retrospectiva e o que fazer se você espera ter um resultado diferente. Mudar o foco é a palavra chave. Espero que vocês gostem.


Recently I have been struggling on how to improve Agile Retrospectives on my project. After nearly 2 years, retrospectives tend to boredom and the team cannot think of different facts otherwise than bad infrastructure and sparse extra working hours.

 

Thinking about that, I decided to have a look on what else I could be doing in a retrospective so that I could have a different output and a more concise action plan. @estherderby is one of the references when talking about Agile Retrospectives and in the video below she and a colleague give a nice presentation on how to set up a retrospective and what to do if you expec.t to have a different output. Changing the focus is the key point. I hope you guys enjoy.