R.I.P – Engenharia de Software

Atenção: Este é um post provocativo, então não se surpreenda com alguns argumentos radicais. O objetivo principal é gerar discussão e avançar a área de desenvolvimento de software.

Quando eu comecei a conhecer Engenharia de Software, era tudo lindo e maravilhoso. Eu li livros como o tradicional livro de Sommerville e toda aquela idea de fazer com que o  desenvolvimento de software chegasse mais perto das tradicionais engenharias fazia muito sentido para mim. Com isso, “ganhamos” o nome de Engenharia de Software.

Quem não lembra (ou vive no seu dia-a-dia) todos aqueles conceitos como gerenciamento de riscos, gerenciamento de mudanças, gerenciamento de projectos, gantt charts, gerenciamento de requisitos, mil e um diagramas UML, etc, etc??

Desenvolvimento de Software deixou de ser uma coisa artesanal para ser uma coisa um tanto quanto burocrática. E o que acontece quando se vira burocrático demais? Sua capacidade de reagir ao que seus clientes querem vai gradativamente diminuindo.

( Nesse momento é importante fazer uma observação para explicar que existem determinados domínios de aplicações que precisam de um controle e burocracia maior do que outros. Um software embarcado que é safety-critical precisa naturalmente de um controle e rigidez maior no seu desenvolvimento. No entanto, uma aplicação web que pode ser deployed muitas vezes ao dia e não um impacto muito grande pode muito bem ser desenvolvida sem maiores burocracias )

Bom, um grupo de pessoas já chegaram a essa conclusão lá em 2001 e eles fizeram nascer uma coisa chamada Manifest Ágil! Esses caras entenderam que existem coisas mais importantes no desenvolvimento de software do que seguir todo o conhecimento que (ainda hoje) tentamos adiquirir de outras disciplinas. Que saber porque??

Porque [praticamente] todo software é SINGULAR!!

Nas outras engenharias é claro que existem desafios, mas a maioria dos projetos como construir um ponte, ou uma casa, ou um carro é um conhecimento estabelecido. E uma vez contruido/montado o primeiro carro (que por sinal, provavelmente vai demorar mais do que os demias), se segue exatamente o mesmo processo para montar os proximos duzentos mil.

No mundo do software, a diferença é que [praticamente] todo software é Singular, [praticamente] todo software é igual ao primeiro carro que precisa ser construido. [praticamente] Todo software é único. Cada linha de código, cada classe, cada método, cada framework. Algumas coisas contribuem para isso como, por exemplo, a velocidade que surgem novas tecnologias, novas linguagens de programação, novos frameworks javascript (os frontend developers sabem do que estou falando).

O post vai ser finalizado com algumas perguntas, que podem gerar debates interessantes….

Levando em consideração que [praticamente] todo software é NOVO, faz realmente sentido tentar se parecer mais e mais com as engenharias tradicionais? Ou deveríamos achar qual é o caminho que faz mais sentido para o desenvolvimento de software  (a depender da área de aplicação?

Deveríamos nos livrar do nome Engenharia de Software? Ou faz sentido tentar se beneficiar de conceitos já estabelecidos nos outras engenharias?

Deixa aí teu comentário sobre esse tópico 😉

Anúncios

Brasil Campeão da Copa do Mundo de Testes de Software

Uma semana se passou após a divulgação do resultado das finais, e talvez nesse momento eu já consiga compartilhar com vocês, de maneira mais precisa, como foi essa experiência.

Após o anúncio de nossa vitória na etapa continental, começamos uma série de preparativos, que consistiram desde a parte logística da viagem (passagens, hotel, documentos…), as demandas da organização (fotos, vídeos, entrevista…) e a preparação técnica para a organização.

Na parte técnica, analisamos o nosso desempenho na fase continental, destacando os pontos fortes que precisavam ser mantidos e os pontos de melhoria, onde precisaríamos realizar ajustes. A partir dessa análise nos dividimos, de modo a realizar as tarefas, que consistiam desde ajustes na estratégia de testes, test report e principalmente atividades de estudo e seleção de ferramentas para áreas como acessibilidade, segurança e usabilidade.

A competição:

A etapa final seguiu o mesmo modelo da continental, tivemos 3 horas para validar a aplicação (Comércio Eletrônico) e enviar um Test Report, que deveria abranger a estratégia utilizada, findings, recomendações e análise do produto. O grande diferencial nessa fase, foi que os jurados, equipe de reportagem e platéia podiam nos interromper com perguntas durante as três horas, o que aconteceu algumas vezes e exigiu jogo de cintura para responder e retomar o trabalho sem perder a concentração.

Este slideshow necessita de JavaScript.

Durante a prova final, utilizamos diversas ferramentas de apoio, abaixo aponto algumas:

  • Google Docs: Colaborativamente alimentávamos o test report, durante a execução, adicionando os defeitos encontrados e informações relevantes.
  • Trello: Antes da competição preparamos um quadro virtual, onde listamos as áreas de teste, e pudemos nos organizar, com o objetivo de evitar duplicação de trabalho e assegurar uma melhor cobertura.
  • MindMeister: Ferramenta para criação de mapas mentais, utilizada para descrevermos nossa estratégia de maneira mais visual.
  • HP Pronq Agile Manager: Ferramenta oficial da competição para gerenciamento dos defeitos.
  • Acessibilidade: Utilizamos ferramentas online, como Wave e daSilva, com o objetivo de apontar falhas de acessibilidade na estrutura do código.
  • Segurança: O Firebug foi uma das ferramentas que utilizamos para identificar potenciais falhas de segurança.

Placar com contagem de bugsAo final das três horas de trabalho intenso, ficou claro para nós ao conversarmos com alguns dos jurados e organizadores, que além das capacidades técnicas em testes, eles também estavam avaliando aspectos relacionados às metodologias ágeis, como a organização da equipe e comunicação interna e com o cliente.

Divulgação do resultado:

No dia seguinte, durante o Keynote de abertura da conferência, recebemos a premiação da etapa continental.

premiacao_etapaContinentalEnquanto, que a divulgação do resultado final aconteceu apenas a noite, durante a festa temática, organizada pelo evento. E claro, que ficamos muito felizes com o resultado final, representando o Brasil e elevando a nossa comunidade de testadores a uma posição de destaque.

Brasil Campeão

Por fim, um agradecimento especial a toda a organização do evento, toda estrutura e apoio fornecido antes, durante e após o evento foram impecáveis. Além da competição, pudemos aproveitar os 3 dias da conferência, que também foram excelentes e em breve compartilharei com vocês um pouco das palestras e workshops que pude assistir.

S.O.L.I.D – Coisas que todo programador deveria saber

Esse post é mais um da série “Coisas que todo programador deveria saber” (talvez o primeiro do BytesDontBite [BdB] com esse título na verdade :P).

Hoje vou falar um pouco sobre o S.O.L.I.D, que é na verdade um acrônimo onde cada letra representa um “princípio” de design de orientação a objetos.  A importância desses princípios é imensa. Então vamos lá:

  • S (Single Resposability Principle) – Toda classe deve ter uma única responsabilidade, e essa responsabilidade deve ser completamente encapsulada por essa classe. Parece uma coisa simples, mas a grande maioria dos problemas que vejo por aí, acontecem pelo simples motivo de termos classes (e métodos) gigantes que fazem tudo o que você pode imaginar. Talvez esse seja, ao meu ver, o mais importante (e o mais simples) desses princípios. Obviamente ele é muito relacionado aos conceitos de (alta) coesão e (baixo) acoplamento, e também é bem descrito e detalhado pelos princípios do GRASP (tópico para o próximo post dessa série)

    Arquitetando…
  • O (Open/Closed Principle) – Todas as entidades do software (classes. módulos, métodos, …) deveriam ser abertas  (open) para extensão e fechadas (closed) para modificação. Isso significa que essas entidades do software tem que permitir uma mudança de comportamento sem a alteração do seu próprio código fonte. Em uma conclusão bem óbvia e simplista, estamos falando de usar mais interfaces e classes/métodos abstratos, que podem facilitar a mudança não dolorosa de comportamento de algumas entidades.
  • L (Liskov Substitution Principle) – Qualquer objeto do tipo X (que é subtipo Y) deveria poder substituir um objeto de tipo Y sem alterar as propriedades básicas do sistema (corretude, etc).
  • I (Interface Segregation Principle) – Prega que as interfaces tenham somente os métodos que serão usados por quem vai implementar essa interface. Ou seja, separar (segregar) interfaces que contenham muitos métodos, em interfaces menores, de forma que, quem implemente a interface, não seja forçado a implementar métodos que não são usados naquele contexto.
  • D (Dependency Inversion Principle) – Esse princípio prega uma forma de desacoplamento, aonde os módulos tem que depender de abstrações (leia-se interfaces) ao invés de depender de classes concretas. Isso se aplica principalmente quando falamos das dependências entre as camadas arquiteturais de um determinado sistema. Uma forma de inversão de dependência é a Injeção de dependência.

Como você pode notar, todos esses princípios meio que se completam de forma a atingir o objetivo que é um design flexível e de fácil manutenção. Espero que tenha sido útil, e até o próximo post dessa série, onde falaremos sobre o GRASP 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Se você está curioso por algumas estatisticas sobre o ano de 2013, aqui está, basta clicar na figura abaixo e seguir o link 😉

Estatisticas do BdB no ano de 2013 (Antes tarde do que nunca :P)

Pedacinho de texto das estatisticas:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 22,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 8 sold-out performances for that many people to see it.

Click here to see the complete report.

Agilidade é Ritmo!

Assitir palestras de alguns gurus é sempre interessante! Mesmo quando a palestra não está legal, em algum momento você pode escutar alguma frase ou alguma explicação que pode mudar sua vida. Eu diria que é mais ou menos como um atacante de futebol que é artilheiro, mas está jogando uma péssima partida, mas o técnico o deixa em campo pois a qualquer momento ele pode fazer um gol!

Dito isto, eu estava em uma longa palestra com um artilheiro, mas a palestra não estava tão interessante. Mas em determinado momento, falando sobre agilidade,  ele disse: “Agile is about rhythm!” Essa frase então chamou minha atenção e fiquei atento a explicação do que isso significava, e fez sentido pra mim.

Se você participa de um projeto que tem um determinado ritmo como por exemplo entregar um release do software a cada 6 meses, você tem “muito tempo” para pensar/fazer/detalhar requisitos, “muito tempo” pra implementar e por aí vai. É óbvio que você vai terminar fazendo mais do que o necessário para o momento e talvez não consiga finalizar tudo, além de colher o feedback muito tarde (em 6 meses tudo pode mudar).

No entanto, se você tem um ritmo de fazer um release por mês, você tem menos tempo pra focar em vários requisitos, por isso você só seleciona alguns deles (os mais importantes do ponto de visto do cliente), você nao tem tanto tempo pra discutir requisitos em um nível de detalhes muito aprofundado (a  não ser que realmente seja preciso) e você não tem tempo para perder tempo com reuniões sem sentido e etc, então você foca em desenvolver aquilo que tem pra ser desenvolvido de forma a receber feedback o mais rápido possível e mudar o mais rápido possível (antes que o custo da mudança seja muito caro ou inviável).

Ah, acho que tem um cenário pior do que os dois que apresentei, que é o caso de você não ter ritmo nenhum!

E você o que acha? Qual o ritmo que faz mais sentido para você ou para sua empresa?

O fator ônibus *

O post de hoje é simples e curto mas apresenta um conceito que é muito importante no dia-a-dia das empresas e dos projetos (principalmente de software, mas não necessariamente se limita a software).

Já participou de algum projeto onde uma ou talvez duas pessoas possuiam todo o conhecimento sobre o projeto? Acho que não é muito difícil isso acontecer, eu mesmo já participei de alguns. Alguns onde outra pessoa tinha todo o conhecimento acerca de um projeto, e outros onde eu mesmo tinha o conhecimento “concentrado” em mim (não porque eu queria, mas por conta das circunstâncias).

O fator ônibus * (do inglês bus factor), significa a quantidade de pessoas, que se forem atropeladas por um ônibus, farão o projeto desandar, ou até mesmo inviabilizar a continuidade do projeto. É óbvio que quanto maior essa medida melhor, pois dificilmente 10 pessoas são atropeladas por um ônibus no mesmo momento.

Moral da história: Se o seu projeto tem o fator ônibus igual a 1 ou 2, você corre sérios perigos! Então corra atrás, compartilhe o conhecimento, treine as pessoas, sugue o que puder sugar dos que tem mais conhecimentos, pergunte, leia, converse e se informe para o bem do seu projeto e da sua equipe!

* Observação: Vale a pena lembrar que o fator ônibus não significa ser literalmente atropelado por um ônibus. Ser atropelado por um ônibus pode significar: Algum membro da equipe conseguir um outro emprego, alguém sair de licença maternidade, alguém decide mudar o estilo de vida, alguém pedir demissão, alguém simplesmente sair de férias por 1 mês (parece absurdo né?), ou realmente alguém for atropelado mesmo por um ônibus 😛

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.