images (2)

Tendências em desenvolvimento de software e tecnologia

Saudações! Depois de alguns meses sem posts, eis que o bom filho à casa torna.

E eu venho pra falar das ultimas tendências em desenvolvimento de software para esse ano…Tá, reconheço que estou um pouco atrasado, estamos no meio do ano, praticamente, mas acredito que os conceitos aqui apresentados são válidos por um bom tempo (o que em T.I. quer dizer alguns meses…).

E agora, sem mais delongas, a “última moda” em desenvolvimento de softwares:

nerd-is-the-new-sexy_design-universofeminino

Aprenda e utilize uma linguagem moderna de scripts

Pode ser Python, Ruby, Groovy ou o que quer que seja a “linguagem do momento”. Contato que você tenha uma ferramenta rápida e fácil na mão para não ter que disparar aquela IDE Java hiper-mega-blaster-super-pesada-e-lenta (ok, talvez eu tenha exagerado um pouco nos quantitativos aqui…o que vale é a intenção 😉 ). Linguagens “Nossa, olha como é simples e fácil fazer isso usando [NOME DA LINGUAGEM]” nos deixam mal-acostumados com sua facilidade e elegância em implementar coisas simples.

Utilize controles de versão distribuídos

Se você ainda não utiliza controle de versão distribuído, pare de ler esse artigo e vá migrar todo o seu código pra um desses agora mesmo. Sério, eu espero! Ferramentas como GIT ou Mercurial fornecem agilidade e facilidades que um SVN ou CVS jamais conseguiriam de uma maneira natural e simples.images (1)

Torne o design responsivo

Design responsivo é tornar sua interface mutável de forma que ela seja visualmente agradável em qualquer device, seja um computador, tablet ou celular (ou a minúscula tela de um óculos, quem sabe…hehe). Foi-se a época em que tínhamos que nos preocupar com apenas um público alvo. Hoje as pessoas utilizam cada vez mais soluções móveis e são cada vez mais exigentes. Temos que nos adaptar à essa nova realidade.

Se familiarize com soluções NonSQL

Banco de dados como MongoDB e CouchDB são tendência uma vez que eles são extremamente escaláveis e performáticos. O conceito de “orientação à documentos” (document-oriented database) significa que, ao invés de estruturas rígidas de colunas cada registro é uma entidade, não precisando nem ter os mesmos atributos. O conceito de registro se torna o de documento suportado por estruturas de dados tipo JSON, queries dinâmicas e armazenamento eficiente de dados binários (como videos e imagens).

Aprenda metodologias e conceitos ágeis

Mais do que simplesmente aprender como funciona, pense ágil! Abra sua mente e deixe a filosofia ágil entrar. Seja você um gerente de projetos, desenvolvedor ou diretor de uma grande empresa, mais do que uma metodologia o ágil é um conceito, um estilo de vida (forçado? rs). Acredite em autogerenciamento, mudanças bem vindas, entregas constantes, melhoria contínua e desenvolvimento sustentável. Alguns paradigmas que vieram da metodologia ágil e devem virar tendência:

  • Integração contínua
  • Scrum
  • TDD (Test Driven Development)
  • BDD (Behavior Driven Development)
  • Desenvolvimento baseado em interações (Iteration-based development)

Go social

As redes sociais vieram pra ficar, então porque não utilizá-las para coisas que valham à pena (mais do que aquele seu amigo que fica o dia inteiro postando fotos do que come ou sua amiga que insiste em usar o mural do facebook para desabafos e pra mostra o quanto ela é uma pessoa verdadeira, íntegra, direta ou o que mais ela encontrar em fotos com frases bonitinhas…). As redes sociais tem um enorme potencial e não devem ser ignoradas como ferramenta de divulgação, interação e, porque não, corporativas.social-media-addiction

Go Mobile

Sim, o mundo está se tornando móvel. Desde o advento a popularização do smartphone (Salve Apple) mais e mais as pessoas preferem interagir com seus pequenos aparelhos de vidro e silício  Cada vez mais temos que pensar em soluções móveis que atendam rígidos critérios de funcionalidade e beleza.images

E você? O que acredita ser as próximas tendências?

Fontes: http://tatiyants.com/http://blog.mostof.it/http://agilemanifesto.org
UseProblemSolvingContenttoMarketAffiliateProducts1

Brainstorming

O Brainstorming é uma ferramenta popular para ajudar a gerar soluções criativas para problemas. É utilizado para desenvolver novas perspectivas.

Foi desenvolvida em 1950 por Alex Orborn, um executivo da Madison Avenue. Desde então, diversas melhorias foram implementadas criando o conceito do “Brainstorming 2.0”.

images

A ferramenta

O Brainstorming combina uma forma informal de resolução de problemas e pensamento lateral. Prega que as pessoas devem dar o máximo de ídeias possíveis não importando o quão louca elas pareçam para que depois elas sejam “lapidadas” em soluções originais e criativas. Incentiva as pessoas a pensar fora da caixa (“think out of the box”).

Durante uma sessão de brainstorming não pode existir crítica em relação às idéias para não inibir o pensamento criativo. Jugamentos e análises devem ser deixados para outro momento do processo.

Exemplo

O mais famoso exemplo de utilização de brainstorming é a solução encontrada por uma cidade para incentivar seus habitantes a utilizar mais as lixeiras ao invés de descartar o lixo nas ruas. Após alguém sugerir a “absurda” idéia das latas de lixo pagarem uma recompensa pela utilização, essa idéia foi convertida num sistema que contava uma piada quando alguém jogava lixo. As pessoas se divertiam tanto com as latas que passaram a utilizá-la sempre.

Inside an Old Pasadena Trash Can

Conclusão

O brainstorming é uma ferramenta para ser utilizada em grupos. Apesar de existirem conceitos e estudos sobre o self-brainstorming, na prática ele não é funcional porque as pessoas tendem a bloquear e criticar suas idéias absurdas.

É ideal ter pessoas de diversas áreas de atuação e disciplinas num mesmo grupo para prover a diversidade de idéias e quebra de paradigmas.

2013-New-YEar-Ahead1

2013 – A hell of a ride!

Hoje de manhã peguei a estrada de moto e, sozinho, comecei a refletir sobre o ano que passou e o que virá. Fiz um balanço da minha vida e minhas expectativas e me dei conta de uma coisa: Os anos são como viagens de moto. Sim, de moto! Se você não é motociclista não tente traçar um paralelo com uma viagem de carro, avião, trem ou qualquer outro meio de transporte. Acredite, não é a mesma coisa.

Me explico: Quando se viaja de moto, mesmo tendo um destino em mente o que conta mesmo é o trajeto. É nele que fica todo o prazer, o sofrimento, a diversão, as descobertas…enfim, tudo o que um motociclista espera em uma viagem.

E, como na vida, nunca sabemos o que vamos encontrar no trajeto escolhido. Podemos enfrentar tempestades, estradas bloqueadas, perigos iminentes, péssimos postos de paradas e climas desconfortáveis…são obstaculos que todo motociclista se propõe a enfrentar. Sim, porque viajar de moto não é algo simples. É desconfortável, barulhento, estressante…

383292363_602ce4c0df

Mas, como na vida, o prazer está nas coisas simples. Ver o nascer ou pôr-do sol enquanto pilota, a conversa despretensiosa em um posto de beira de estrada, sentir o vento no rosto enquanto ouve “Born to be wild” no fone de ouvido, o aceno cordial à um colega motociclista na estrada para demonstrar empatia como quem diz “Sim, estou passando pela mesma coisa…”. São sensações indescritíveis que só quem viaja de moto conhece!

motorcycle-rider-at-sunset

E as companhias…é muito bom viajar sozinho, ter um tempo pra si, refletir, mas é acompanhado que se vai mais longe e onde a viagem se torna mais divertida. São suas companhias que te incentivam quando você está cansado ou te refream quando você está muito afoito, que muitas vezes confudem seu caminho mas sempre com a intenção de te apontar a direção certa. Escolha bem quem te acompanha, porque são essas pessoas que te servirão de apoio.

43rd_sus_bde_motorcycle_ride_3_april_09

Quando aproveitamos ao máximo o caminho trilhado chegamos ao destino como chegamos ao fim de mais um ano…desejando que o próximo comece logo e seja melhor que o que passou!

Um feliz ano novo para todos e que 2013 seja uma viagem e tanto!

UseProblemSolvingContenttoMarketAffiliateProducts1

Análise de cause e efeito (Cause and Effect Analysis)

Quando você tem um problema sério é importante analisar todas as causas antes de pensar numa solução.

A ferramenta

A análise de causa e efeito foi desenvolvida pelo professor Kaoru Ishikawa (criado do Diagrama de Ishikawa, Diagrama espinha de peixe ou Diagrama 6M, que fundamenta essa ferramenta) nos anos 60. Essa ferramenta foi publicada depois (em 1990) no livro “Introdução ao controle de qualidade”.

É comumente utilizada para:

– Descobrir a causa raiz de um problema;

– Descobrir gargalos em seus processos;

– Identificar onde e porque um processo não está funcionando.

Utilização

A ferramenta é composta dos seguintes passos:

– Identificar o problema: Escreva detalhadamente o problema que você está enfrentando. Tente identificar os envolvidos, qual o problema, quando e onde ocorre. Escreva o problema eu um retângulo no lado esquerdo de uma folha e trace uma reta dividindo-a em duas.

– Trabalhe nos fatores mais importantes envolvidos: Podem ser sistemas, ferramentas, pessoas…enfim, qualquer dos fatores identificados. Tente identificar quantos você puder. Você pode usar outras ferramentas para isso, como brainstorming, os 5 porquês (descrito nesse post) ou o framework dos 7 S´s de McKinsey.

– Identifique as causas possíveis para cada fator identificado no passo anterior e desenhe essas causas com linhas saindo dos “ossos”. Desenhe “subcausas” para as mais complexas.

– Analise seu diagrama: Nesse ponto você deve ter seu diagrama desenhado e as causas do problema devem estar mais claras. Você consegue agora identificar os fatores mais importantes trabalhar em suas soluções.

 

UseProblemSolvingContenttoMarketAffiliateProducts1

Resolução de Problemas – O ciclo PDCA (Plan-Do-Check-Act)

O PDCA (da sigla em inglês Plan-Do-Check-Act ou Planejamento-Execução-Verificação-Ação) é, além de uma ferramenta de resolução de problemas, uma ferramenta de melhoria continua.

Conhecido também por “Ciclo de Deming” ou “Ciclo de Shewhart” por ter sido idealizado por Walter Andrew Shewhart e efetivamente aplicado por Edward Deming.

Nascido inicialmente para uso estatístico e métodos de amostragem, consiste em um processo de identificação e resolução de problemas divido em 4 fases

Plan (Planejamento)

Fase onde se estabelece a meta ou identifica o problema. Nessa fase se estabelece um plano de ação.

Do (Execução)

A execução consiste em testar o plano de ação definido no passo anterior através de um projeto piloto, por exemplo. Apesar do termo “execução” nessa fase não ocorre a implementação integral da solução. Isso acontece na ultima fase do ciclo.

Check (Verificação)

Monitoramento e avaliação dos resultados, avaliação dos processos e resultados confrontando-os com o planejado por meio de KPIs (Key Performance Indicator).

Do (Ação)

Depois de verificados os resultados o plano de ação é avaliado e melhorado, se necessário e o plano é executado em sua totalidade.

As fases 2 e 3 (“Do” e “Check”) podem acontecer várias vezes até que se tenha um resultado satisfatório para só então se implementar integralmente a solução.

O Ciclo PDCA é associado ao desenvolvimento de software em espiral e é, por definição, lento. Em situações emergenciais pode não ser a melhor solução.

Fontes: Mindtools, Wikipedia
UseProblemSolvingContenttoMarketAffiliateProducts1

Resolução de Problemas – Os 5 porquês (5 Whys)

Depois de uma série de artigos sobre tomada de decisões, agora vou falar sobre outra característica fundamental no gerenciamento de projetos: A habilidade em resolver problemas.

A técnica dos 5 porquês de tornou popular pelo sistema de produção da Toyota em 1970. Consiste em perguntar-se “porquê” em relação à um problema até se chegar na raiz dele. Normalmente a resposta do primeiro porquê leva a um segundo, cuja resposta leva a um terceiro e assim por diante. É possível que seja necessário mais ou menos de 5 perguntas até chegarmos na raiz do problema.

Os “5 porquês” é uma técnica simples que pode te ajudar a chegar rapidamente na raiz de um problema. E apenas isso. E quanto mais complicadas as coisas forem, maior a probabilidade dessa técnica te direcionar para um caminho falso. Se a resposta aos 5 porquês claramente não for correta, você pode utilizar outras técnicas de resolução de problemas.

Como funciona

Exemplo 1

Os usuários vivem insatisfeitos com o sistema desenvolvido internamente. Porquê?

Porque vive apresentando erros. Porquê?

Porque a equipe de TI não tem tempo hábil pra testá-lo antes de entregar. Porquê?

Porque já estão atrasados com outros desenvolvimentos. Porquê?

Porque não houve um bom planejamento do que deveria ser feito. Raiz do problema.

Exemplo 2

O veículo não liga. Porquê?

Porque a bateria não está funcionando. Porquê?

Porque o alternador quebrou. Porquê?

Porque as revisões devidas não foram feitas. Raiz do problema.

Até o próximo artigo.

Fonte: Mindtools, Wikipedia, iSixSigma
kanban

Kanban + MediaWiki = Wikanban!

A história é a seguinte: Me perguntaram recentemente sobre uma boa ferramenta para documentarmos os sistemas na empresa que trabalho atualmente. Nós também não usávamos nenhuma ferramenta para controle das demandas (Nós sempre fomos adeptos da filosofia “Keep it simple”!), então sugeri utilizar um kanban para controle das demandas e um wiki para documentação.

Porém os desenvolvedores sofrem de um mal comum em várias empresas: Excesso de demanda e falta de tempo para documentar. Então…porque não integrar os dois?

Foi dai que surgiu a idéia do Wikanban. Procurei uma boa ferramenta de kanban “Open source” na internet e não encontrei quase nada. Então decidi desenvolver uma do zero.

O Wikanban é feito com PHP usando Ajax. Tem o intuito de ser simples e eficiente. Funciona assim: Você cria as filas (que no nosso caso são os desenvolvedores), cria as tarefas e “cola” no quadro da fila em questão como se fosse um post-it. Qualquer pessoa pode incluir anotações ou impedimentos nas tarefas à vontade. Eventualmente essa tarefa vai para a fila “Homologação”. Uma vez homologada, a tarefa some do quadro. Pronto.

E onde entra a Wiki nisso tudo? Simples, conforme uma tarefa é manipulada (criada, homologada, apagada, alguma observação é inserida, etc) uma Wiki vai sendo atualizada com essas informações automaticamente. Tudo fica gravado para futuras referências. É só clicar no ícone “W” da tarefa para consultar a Wiki. E a ferramenta cria toda a estrutura de projetos automaticamente. Lindo, não!?

Você pode testar o Wikanban aqui (Totalmente funcional no Chrome. Ainda estou ajustando para os outros browsers…). Ele é uma ferramenta open source e pode ser baixada e alterada à vontade aqui.

As instruções para instalação podem ser encontradas no arquivo README.

Opiniões sobre como melhorar o produto são bem vindas nos comentários!

Até a próxima!