Já conhece o eXtreme Go Horse Programming?

Você conhece o eXtreme Go Horse (XGH) Programming? Não?? Então não perca tempo e veja aqui essa maravilhoso processo 🙂 Será que a vida de desenvolvimento de software fica mais fácil depois das dicas desse processo? 😀

1- Pensou, não é XGH.

XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.

XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.

Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH.

XGH tende ao infinito.

4- XGH é totalmente reativo.

Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.

Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.

Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.

Os prazos passados pelo seu cliente são meros detalhes.

Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script maluco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.

Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro.

O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.

Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.

Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.

A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.

Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.

Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.

Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.

Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.

Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.

Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.

Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.

Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.

Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.

O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.

Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Fonte: http://gohorseprocess.wordpress.com/extreme-go-horse-xgh/

Esse texto é uma brincadeira, você pode me xingar no twitter: @maribalbe

#TGIF – Quer aprender a tocar guitarra?

Quem não gostaria de aprender a tocar guitarra? Então você precisa dessa guitarra: GTar!  A GTar possui um dock onde o iPhone é acoplado.

A GTar é elétrica e não necessita de cabos para funcionar. Seu corpo é feito em madeira e as cordas são do mesmo material de uma guitarra verdadeira. No entanto a afinação do instrumento não faz diferença na sonoridade do mesmo, uma vez que o som fica a cargo do iPhone e da acústica da guitarra. As primeiras guitarras serão entregues aos compradores a partir de setembro, uma vez que a empresa já atingiu o valor necessário para iniciar a produção. Segundo a startup cada gTar custará na faixa dos US$ 450.

Ferramentas de prototipação

No post passado comentei um pouco sobre wireframes e como abordá-los como processos e não apenas como artefatos. No final do artigo, mencionei que existem algumas ferramentas que normalmente são utilizadas pelos profissionais de UX. Antes de falar um pouco sobre ferramentas, vamos relembrar um pouco sobre o que é prototipação.

A fase de prototipação é aquela em que construímos um ou mais modelos para avaliar (no caso do design centrado no usuário, junto ao usuário) se a solução que desenvolvemos ainda é valida do ponto de vista de tecnologia, negócios e dos próprios usuários. Esses protótipos podem ter várias fidelidades, a depender basicamente do que queremos comunicar com aquele wireframe e o tempo disponível.

Se queremos comunicar apenas a ideia geral por trás da solução, podemos utilizar wireframes de baixa fidelidade. Eles representam um estágio inicial no desenvolvimento do produto e carecem propositalmente de detalhes mais profundos. Por outro lado, quando queremos contemplar mecanismos e informações mais detalhadas normalmente utilizamos wireframes de alta fidelidade.

Uma das principais ferramentas para o desenvolvimento do primeiro tipo citado – os wireframes de baixa fidelidade – é o Balsamiq. Essa ferramenta é bem simples e fácil de ser utilizada e pode gerar wireframes de maneira rápida apenas arrastando os componentes diretamente da barra. Por outro lado, desenvolver interações nesses wireframes é praticamente impossível, visto que o único mecanismo para tal é a troca de páginas. A simplicidade da ferramenta se reflete no seu preço de US$79.

Balsamiq
Balsamiq

Existem muitas ferramentas que seguem a linha do Balsamiq mas que têm um ou outro recurso a mais ou a menos. Algumas também utilizadas e que têm esse diferencial são: Mockingbird (planos a partir de US$9/mês), iPlotz (planos a partir de US$15/mês), MockFlow (US$59/ano) e ForeUI (US$150).

Quando se fala de prototipação em alto nível, temos também várias ferramentas. Entre elas uma merece destaque, o Axure RP. Atualmente ela se apresenta como talvez a mais usada e completa. Podendo gerar mais do que wireframes estáticos, o Axure RP chega a versão 6.5 com a possibilidade de inserir interações complexas com o uso até de variáveis e rotinas em javascript. Tal flexibilidade e poder tem o seu preço. Nesse caso, o preço é de US$549.

Axure
Axure

Independente da ferramenta, prototipação é algo trabalhoso. Em alguns casos, o bom e velho lápis e papel ainda vai ser o jeito mais fácil de comunicar aos stakeholders qual é a melhor solução para eles, em outros, quando não houver escolha e algo formal deve ser entregue, resta escolher a melhor ferramenta.

Os 7 princípios do teste de software

No post – Os bons testes falham – falamos sobre um dos princípios de teste definidos no livro “Fundamentos de testes de software”. Hoje, compartilho com vocês dois vídeos, bem curtos, que resumem os 7 princípios definidos no livro. Os mesmos servem como referência, principalmente para aqueles que estão iniciando na área de testes.

O primeiro vídeo, exibido acima, aborda os 4 primeiros princípios, são eles:

1 – Teste demonstra a presença de defeitos.

Os testes reduzem a probabilidade que erros desconhecidos permaneçam no sistema, mas mesmo que nenhum defeito seja encontrado isso não é prova de conformidade.

2 – Teste exaustivo é impossível.

Mesmo com auxílio da automação, o número de combinações possíveis de cenários de teste numa aplicação é gigantesco, inviabilizando a possibilidade de se afirmar que TUDO foi testado.

3 – Testes devem iniciar o quanto antes e erros encontrados tarde custam mais para corrigir.

Iniciando o mais cedo possível no ciclo de vida do desenvolvimento do software, diminuímos o custo das correções e possibilitamos que erros de design, requisitos e arquitetura sejam encontrados no momento ideal. (Link para vídeo que aborda o assunto)

4 – Agrupamento de defeitos 

80% dos defeitos são causados por 20% do código. Ao identificar essas áreas sensíveis, os testes podem prioriza-las, enquanto ainda procuram por erros nas demais regiões.

O segundo vídeo, exemplifica os princípios anteriores e apresenta os 3 últimos pontos:

5 -Paradoxo do Pesticida

Caso os mesmos testes sejam aplicados repetidamente, em determinado momento eles deixam de ser úteis, ou seja, não conseguem encontrar nenhum novo defeito. Por isso, os testes precisam ser revisitados com frequência.

6 – Teste é dependente do contexto

Diferentes tipos de aplicações exigem a aplicação de técnicas diferentes de teste.
7 – A ilusão da ausência de defeitos

De nada adianta o sistema estar correto funcionalmente, porém não atender a real  necessidade do usuário.

O Cliente

Entre todos os princípios listados, acredito que os números 3 e 7 representam os principais aspectos da nossa atividade. A busca constante por antecipar cada vez mais as possíveis falhas da aplicação e assegurar que o sistema entregue atenda as reais necessidades do cliente, agregando valor ao seu negócio.

E vocês que aspectos consideram mais importantes nos testes de software?

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

BdB Recomenda – Custo de vida

Hoje o BdB Recomenda irá falar de uma ideia simples que acabou se transformando em um site muito útil, este é o custodevida.com.br, criado pelo mineiro Lucas Franco. Quem nunca teve que viajar a negócios, a lazer ou até mesmo está interessado em se mudar para cidade e quer conhecer um pouco sobre os preços e custo de vida da cidade?

É claro que é do interesse de todos saber os preços de todas as categorias possíveis, como preços de aluguel, cinema, supermercado, aquele chocolate do mercadinho da esquina ou até mesmo a cerveja da sexta-feira.

O Custo de vida é um site colaborativo onde os usuários podem contribuir informando os preços encontrados dentro de sua rotina como restaurante, aluguel, combustível, etc. A ferramenta faz uma média dos valores dos produtos de que os usuários informaram e cria uma estimativa de preço de cada item. Além disso o site mostra um índice para cada cidade, para combinar mais facilmente o custo de vida entre duas cidades.

Vale a pena dar uma olhada e também colaborar, pois para quem está visualizando preços, uma cidade com um grande número de colaboradores, faz com que as estimativas de custo de vida tendem a ser mais exatas. Hoje o custo de vida possui colaboração de mais de 4000 mil pessoas e 650 cidades cadastradas.

A Educação está mudando…

Um estudo recente comparou duas versões de um curso de introdução a estatística, um ensinado (face to face) por professores e uma maioria ensinou online com apenas uma hora por semana de tempo face to face. Os pesquisadores descobriram que os alunos se saíram igualmente bem em ambos os formatos. A única diferença era que o grupo online aprendeu mais rápido que o ensino convencional.

Nos EUA, diversas universidades renomadas estão indo para este lado. O MIT (Massachusetts Institute of Technology), além de disponibilizar cursos de graça em seu site e uma plataforma para cursos online, chamada MITx, também tem parcerias de peso no lançamento de novas ferramentas, como o edX, em parceria com Harward. Por sua vez, Harward também dosponibiliza diversos cursos online em seu site. CMU (Carnegie Mellon University) também não fica para trás. Nem tampouco a Stanford University, disponibilizando cursos no iTunes. Adicionalmente, uma plataforma que integra 4 universidades do US (incluindo Stanford) tem feito bastante sucesso. Paralelamente, diversas startups estão sendo lançadas nesse segmento buscando esta oportunidade de mercado.

Dia desses abri um bate-papo destes com os alunos da UFSCar – Sorocaba. Interessante que diversos alunos já vem participando de cursos online como forma de complementar sua formação. Mesmo aqueles que tem dificuldade em matérias face to face tem procurado cursos na web para lhes auxiliar no processo de aprendizagem. Ou seja, o ensino/universidade está mudando rapidamente e como diria Jonathan Quinn, em 1997, “Universities won’t survive. The future is outside the traditional campus, outside the traditional classroom. Distance learning is coming on fast.” Finalizo o post com uma pergunta de outro post de um grande pensador, Silvio Meira: E a Universidade, já era?

 

#TGIF – Facebook = Inovação (até na Infraestrutura)

 

O Facebook cresce a cada dia, expandindo seu alcance na vida dos usuários. A empresa, que é exemplo de inovação em diversos seguimentos, nos mostra nesse vídeo, como alguns simples procedimentos internos podem ser reorganizados de maneira a diminuir os custos e facilitar a vida dos colaboradores.

Para ver mais fotos do ambiente de trabalho no facebook, clique aqui.

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

BdB Recomenda – Photaf Panorama

Hoje o BdB Recomenda vai abordar um aplicativo para celular, mais especificamente Android com uma funcionalidade, no minimo, sensacional. O Photaf panorama é um aplicativo para tirar fotos, contudo, ele possui a inteligencia de criar fotos panorâmicas, isto é, fotos de até 360º. Entretanto, não existe mágica, por processamento de imagem, ele analisa e te ajuda a tirar fotos seguidas de forma alinhada, tanto vertical quanto horizontalmente.

Ao fim de todo processo, depois de todas as fotos tiradas, basta apertar o botão “Finish” e ele irá fazer a união das fotos, formando a imagem panorâmica.

Ele também possui algumas outras funcionalidades, tais como compartilhar as suas fotos com seus amigos no facebook, ferramentas de zoom na imagem do panorama, converter seu panorama para um papel de parede. Além disso seu panorama pode aparecer no site oficial do aplicativo, onde existe uma galeria com as fotos dos usuários dos quatro cantos do mundo. Para os usuários Android, esse aplicativo não pode faltar nos passeios e viagens!

#Vagas – Stefanini – Desenvolvimento de Software

 É com prazer que o BdB  continua  a parceria com a área  de Talent Acquisition (que é a área responsável por recrutamento e seleção) da Stefanini. Lembrando sempre que as vagas e oportunidades que forem surgindo vão ser divulgadas aqui no BdB para que você possa aproveitar e se candidatar (caso interesse).

Interessados enviar currículo para talentosrs@stefanini.com especificando no campo “assunto” com o código da vaga.

Analista De Sistemas JR(Cod. 011)
Requisitos: experiência com criação de requisitos de sistemas a partir de requisitos de negócios. Inglês Fluente.
Remuneração: de acordo com o perfil profissional
Vagas: 1
Local de trabalho: Porto Alegre/RS

Desenvolvedor Java JR/PL(cod. 002)
Requisitos: Experiência em desenvolvimento Java. Bons conhecimentos em PL / SQL, design e padrões de projetos. Desejável conhecimentos em weblogic, webservices, Soa e certificação. Inglês minimo intermediário(fala, leitura, escrita).
Atividades: Para trabalhar com manutenção, melhorias (novas aplicações ou migração de tecnologia) e desenvolvimento de sistemas em Java em projetos internacionais, compostos por times distribuídos geralmente no Brasil, Estados Unidos, Índia, Malásia, Japão, Rússia e outros.
Remuneração: de acordo com o perfil profissional
Vagas: 1
Local de trabalho: Porto Alegre/RS

Project Manager Júnior (cod. 024)
Requisitos: Experiência com liderança de equipes, distribuição e controle de tarefas, conhecimento da ferramenta MS Project. Inglês Fluente.
Atividades: Atuar em projetos internacionais (times globais).
Remuneração: de acordo com o perfil profissional
Vagas: 1
Local de trabalho: Porto Alegre/RS

Wireframes como processos e não artefatos

Quando se trabalha construindo a experiência do usuário muito se fala de fazer wireframes. Eles, os wireframes, são os artefatos mais gerados por esse perfil de profissionais e é em boa parte aquilo que serve de guia para o desenvolvimento de aplicações e produtos. Entretanto, o que acontece é que muitas pessoas têm uma definição errada do que são os wireframes e como podemos utilizá-los.

Para mim, os wireframes atuam como uma forma de “dispositivo de pensamento” para a definição e exploração de um determinado problema. Para entender a utilidade dos wireframes é importante compreender a natureza do projeto. Eu uso os meus esboços e wireframes como meios para fazer movimentos exploratórios e avaliar as conseqüências desses movimentos.

Eu acho que é bastante comum para quem trabalha com experiência do usuário utilizar os wireframes para exibir o design como resolução de problemas. Para mim, o design através do uso de wireframes é uma busca em um espaço do problema de alternativas, é um processo de definição de problema, tanto quanto é um processo de resolução de problemas.

O processo de design poderia ser melhor descrito como passar de uma fase de divergência, por uma fase de transformação, para uma fase de convergência. Ao longo de cada fase, wireframes são apresentadas às partes interessadas para crítica e conversação.

Durante a fase divergente, as limitações e as possibilidades de situação de projeto são exploradas. Grande parte desta fase consiste em reunir informações e tentar entender e formular o problema de projeto e muitas vezes são informados pelos primeiros modelos conceituais que esbocei. Ao gerar um número de wireframes, posso explorar alternativas. Todas as ideias impossíveis e concebível são apresentados, testados e em muitos casos, atiradas para longe. Normalmente as visões iniciais são formadas durante esta fase.

Primeiros esboços do que virá a ser um wireframe
Primeiros esboços do que virá a ser um wireframe

Na fase de transformação, diminuímos o número de alternativas. Começamos a jogar fora idéias realmente ruins que eu poderia ter imaginado no início. É normalmente nesse ponto que eu volto e leio o documento de requisitos e tentar entender o ecossistema completo das necessidades dos stakeholders e de negócios, e tratar aqueles que estão no contexto do meu principal objetivo do projeto: uma solução elegante para a atividade principal do meu público-alvo.

É também neste momento que eu começo a lidar com as necessidades dos concorrentes. Também nesse momento começamos a envolver as partes interessadas, mas também trazer o designer gráfico, o líder de desenvolvimento, e o engenheiro de qualidade para que eles possam contribuir com o processo e dar mais idéias além de apontar falhas e limitações.

Versões posteriores de um wireframe
Versões posteriores de um wireframe

Finalmente, eu como designer, eu tenho que tomar a decisão de implementar o projeto em uma especificação. Durante a fase de “convergência”, eu crio dois ou três candidatos para consideração final. Eu uso anotações para embasar os wireframes durante os testes com partes interessadas e engenheiros de testes.

Resumidamente, enquanto wireframes são um produto bastante comum usado por profissionais de experiência do usuário para se comunicar design, é importante entendê-los, tanto quanto um processo de design como o resultado final, cada um com objetivos específicos. Ao classificarmos um wireframe como um processo em vez de um artefato, acredito que descobrimos que temos a oportunidade criar excelentes experiências para o usuário.

Existem também ferramentas específicas para a construção de wireframes mas essa é uma história a ser abordada em um outro post. 🙂

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