#TGIF – “Tudo” sobre o iPhone 5

Está marcado para o dia 04 de outubro mais um evento da apple, onde já foi confirmado o lançamento do iPhone 5. Fãs da apple aguardam ansiosamente por mais uma versão do produto, que já há alguns meses é assunto por toda web.

Diversos são os rumores sobre as novas características do produto, enquanto outro assunto recorrente são os casos envolvendo supostos protótipos do aparelho “esquecidos” em bares e restaurantes por funcionários.

O #TGIF dessa semana selecionou alguns desses links para você se inspirar e rir um pouco nessa sexta-feira.

Primeiro, um dos muitos vídeos que mostra as supostas funcionalidades do iPhone 5, entre elas teclado laser e display holográfico.

Em seguida, mesmo que você seja um fã de carteirinha da apple, não há como não rir com as brincadeiras, que parecem sem fim, sobre o problema com a antena do iPhone 4.

Fonte: Macstories.net

Por fim, vídeo divertidíssimo ilustrando a reação dos diretores da apple com a perda dos protótipos do iPhone 5.

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– A brilhante [última] palestra de Randy Pausch

– Por que você deve investir em UX

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

Anúncios

A Metáfora da Dívida Técnica: O preço das gambiarras

O XP (eXtreme Programming) tenta se utilizar de metáforas no desenvolvimento de software para trazer o entendimento de todos para mais próximo do mundo real. Metáforas são um instrumento poderoso.

Recentemente compareci na QConSP, e no meio de tantas palestras uma me chamou a atenção em particular, e se tratava justamente da explicação de uma metáfora (que acredito ser maravilhosa para se comunicar com a gerência ou clientes).

Todos nós sabemos o que é uma dívida no mundo real, e todos nós eventualmente entramos em dívidas, seja um financiamento de um imóvel que você vai pagar por 300 meses, ou um carro que você vai ficar endividado por 60 vezes. O pior de tudo é que além da dívida normal, você irá pagar um montante de juros absurso dependendo do tamanho da dívida que você está assumindo.

Existem as dívidas responsáveis ou conscientes como as citadas acima mas também existem dívidas inconscientes ou não responsáveis que são piores, pois surgem de uma hora para a outra sem te dar tempo para pensar se desejava assumir essa dívida ou não (ex: alguém gastando desordenadamente no cartão de crédito e quando vai ver a fatura fica surpreso).

Pois bem, no desenvolvimento de software é a mesma coisa!

Você tem que adicionar uma funcionalidade no seu sistema. Nesse momento  você enxerga duas formas de fazer isso: Uma forma é rápida de fazer, mas é meio bagunçada e com certeza você iria ter mais trabalho ainda no futuro para modificar aquilo. A outra forma é mais elegante e organizada, porém vai demorar mais. Isso lhe parece familiar?! Esse trade-off acontece o tempo todo no desenvolvimento de sistemas, mas o que esquecemos é das dívidas que assumimos quando escolhemos a forma mais rápida e mais bagunçada (ex.: gambiarras)!

Parece que não temos ciência que todas as vezes que assumimos uma dívidas técnicas no sistema, mais lento o desenvolvimento se torna, mais difícil de modificar as funcionalidades existentes, mais difícil adicionar funcionalidades novas (como mostra o primeiro gráfico) e muito mais provável que uma mudança qualquer tenha impactos indesejados e desconhecidos. Temos que estar cientes das dívidas que assumimos no dia-a-dia do desenvolvimento de software.

Ah, então é por isso que não conseguimos aumentar a velocidade do time depois de tantas sprints??

Talvez! Aí nasce a  questão importante que é o momento que iremos pagar nossas dívidas, ou ao menos parte delas. A grande maioria dos times conhecem os lugares no sistemas que estão com dívidas, e é preciso separar um tempo para PAGAR essas dívidas caso contrário os juros só fazem aumentar. Enquanto as dívidas não são pagas, nós nos deparamos com o cenário onde sprint após sprint, vamos fazer menos coisas (vide o segundo gráfico) pois agora é muito mais difícil modificar o sistema com tantas dívidas do que era no início do desenvolvimento quando não tínhamos dívida ou as poucas dívidas que tínhamos eram controláveis.

Cuidado com suas dívidas técnicas ou elas vão afundar você e seu projeto! 

#TGIF – Conceitos, protótipos e ficção científica – Os primeiros passos para evolução.

Qualquer semelhança é uma mera coincidência 🙂

O TGIF de hoje vai falar sobre a importância de conceitos, protótipos e porque não Ficção Científica. Muita gente não dá a devida importância para estes temas, mas é bom ter em mente que se não houvessem pessoas que trabalhassem com isto, com certeza que a nossa evolução não seria tão rápida quanto vemos. Exemplos clássicos estão a nossa volta como a famosa saga de Star Trek que inspirou na criação de vários dispositivos que hoje utilizamos largamente no nosso dia a dia como celulares e iPods.

Como diz o cantor Jorge dü Peixe da Nação Zumbi: “Ficção Científica é a nossa grande literatura de idéias.” E é a partir dessa literatura criadas por diversos “professores pardal” no mundo.
Segue um video de um conceito que nos tempos de hoje podemos dizer que é antigo mas que ainda surpreende muita gente. O nome dela é GINA.
GINA é um conceito da BMW que teve inicio em 2001 e que foi exibido apenas em junho de 2008 no qual o carro não possui uma “lataria” e sim uma roupa. Isso mesmo, um carro revestido por uma “pele” super resistente feita de poliuretano, que deixa o mesmo completamente flexível e elegante. O resultado é que GINA não foi apenas um protótipo, foi uma mudança de paradigma. Este projeto mudou drasticamente a forma como nós olhamos para um carro. Chris Bangle,diretor de design da BMW, disse no video: GINA “humanizou” o carro e mudou a forma de pensar como desenvolver um. A filosofia de GINA em poucas palavras é tudo sobre ser flexível, contexto sobre o dogma.

Já imaginou um carro “piscando o olho” pra você ? A GINA faz. Vejam o video abaixo :

A série – Thank God It’s Friday ou #TGIF – aborda sempre um conteúdo menos técnico, mas que ainda assim possa contribuir com o seu crescimento pessoal e profissional.

Leia, também, outros artigos já publicados na série:

– A brilhante [última] palestra de Randy Pausch 

– Por que você deve investir em UX

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

Código: cobrir ou não cobrir, como e quando?

Em todo projeto bem planejado sempre se tem alguns critérios definidos em cada fase do projeto. Basicamente são os critérios de entrada, que define o que e como deve estar os artefatos/situações/infra que estão diretamente ligados aquela fase para que a mesma possa ser iniciada, e os critérios de saída que são os critérios que definem que uma determinada fase esta pronta para ser finalizada. Lembrando que nem sempre os critérios de saída de uma fase do projeto são também critérios de entrada de outra fase, principalmente nos dias atuais no qual o tempo é um fator crucial e os projetos raramente utilizam modelo de desenvolvimento em cascata para desenvolver o software e as fases de um projeto muitas vezes acontecem em paralelo.

Um dos critérios mais comuns em qualquer fase de um projeto de teste é a cobertura. Geralmente quando a conversa é com o cliente, se discute cobertura das funcionalidades e quando a conversa é com uma equipe de desenvolvedor, a conversa muitas vezes muda de escopo e passa a ser cobertura de código. Principalmente quando estamos falando num dos primeiros momentos em que teste dinâmico (Necessita de execução de código) se envolve em um projeto de desenvolvimento de software, que são com testes unitários. E um dos critérios de saída mais conhecidos na fase de desenvolvimento dos testes unitários são os de cobertura de código. Mas antes de conseguirmos calcular a porcentagem de cobertura dos testes unitários em relação ao software ou módulo deste software, precisamos definir qual a menor parte de código é considerada no projeto (linha de código, método, classe, etc.) e depois de implementarmos os testes unitários para exercitar esta menor parte de código é que podemos partir para próxima etapa. Ou o contrário se caso o projeto utilizar o processo de TDD (test driven development) no qual inicialmente temos apenas as assinaturas dos método e iniciamos primeiramente a implementação dos testes unitários para depois implementarmos o código do software. Geralmente os projetos que utilizam o TDD corretamente, possuem uma cobertura de código muito boa.

Para medirmos cobertura de código, além da definição da menor parte do software, a próxima estapa é definir a dimensão que nossos testes vão ser medidos,  pois as técnicas de cobertura apenas medem uma dimensão de um software por vez. Isso quer dizer que: Temos que ter cuidado quando falamos de 100% de cobertura. Podemos sim dizer que temos 100% de código coberto mas isso não a obrigatoriedade de termos 100% do código testado. Um exemplos disso  é:  Dois valores distintos de entrada podem exercitar as mesmas linhas de códigos mas uma pode encontrar um erro e a outra não.

Falando um pouco sobre as técnicas de medição de cobertura de código, as duas mais conhecidas são: Statement Coverage e Decision Coverage. A primeira nada mais é que a quantidade de números de linhas de código exercitados pelos testes, dividido pela quantidade total de linhas de código. Isso significa que se eu tenho um método com 10 linhas de código e um conjunto de testes que juntos executam 8 linhas de código daquele método, então posso dizer que a cobertura dos meus testes em relação ao método é de 80%. Quando falamos de decision coverage, a coisa não fica tão trivial assim. Decision coverage leva em conta se todas as linhas de códigos que possibilitam um ou mais caminhos de fluxo, foram completamente exercitados. Isso quer dizer que, estruturas de condição como: IF, CASE e estruturas de repetição como: DO-WHILE, REPEAT-UNTIL foram completamente exercitados pelos testes.

Complicado né ? Não se preocupem, no meu próximo post vou mostrar na prática como utilizar uma ferramenta, free obviamente, para medir a cobertura de código utilizando essas duas técnicas de medição.

Abracos e até a próxima.

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.

#TGIF – A brilhante [última] palestra de Randy Pausch

Essa palestra tem como título “Really Achieving Your Childhood Dreams” e sua tradução seria algo como “Como realmente atingir seus sonhos de criança”. Eu preciso dizer que essa foi uma das palestras mais brilhantes e mais emocionantes que eu já assisti.

No momento que Randy Pausch apresentava essa palestra ele estava diagnosticado com câncer de pancreas (um dos mais difíceis tipos de câncer) e sabia que iria morrer dentro de alguns meses. Mesmo diante dessa dura realidade, ele não perdeu a alegria pela vida e pelas pessoas que ele amava. Um exemplo de atitude.

(A palestra é meio longa – 1h e 16 min – mas definitivamente vale a pena assistir. Se você não está com tempo agora, guarde o link dessa página, ou do vídeo no youtube e confira depois)