Arquivo de março de 2009

Os 7 mandamentos da TAM

segunda-feira, 30 de março de 2009

Os . Num dos links no final conta um pouco da vida do comandante Rolim.

1- Nada substitui o lucro
2- Em busca do ótimo não se faz o bom
3- Mais importante que o cliente é a segurança
4- A maneira mais fácil de ganhar dinheiro é parar de perder
5- Pense muito antes de agir
6- A humildade é fundamental
7- Quem não tem inteligência para criar tem que ter coragem

http://www.tammarilia.com.br/trabalheconosco.php

http://www.tam.com.br/b2c/vgn/v/index.jsp?vgnextoid=239b8c0583068110VgnVCM1000004232690aRCRD

II WORKSHOP DE GERENCIAMENTO DE PROJETOS DE SOFTWARE (WGPS 2009)

quarta-feira, 25 de março de 2009

Ouro Preto / MG – 04 de junho de 2009

Introdução

O II Workshop de Gerenciamento de Projetos de Software (WGPS) ocorrerá no escopo das atividades do VIII Simpósio Brasileiro de Qualidade de Software (SBQS 2009) e será, a exemplo do ano anterior, um fórum dedicado à apresentação dos resultados obtidos com a aplicação do Gerenciamento de Projetos no contexto de Tecnologia da Informação. O objetivo deste workshop é compartilhar conhecimento de técnicas, ferramentas, métodos e relatos de experiências de Gerenciamento de Projetos no segmento de Tecnologia da Informação, mostrando os resultados obtidos e as lições aprendidas. Pretende-se ainda estimular a integração e a cooperação de pesquisadores nesta área, com empresas e entidades que apóiam, oferecem serviços, ferramentas ou utilizam conceitos de Gerenciamento de Projetos nas suas organizações.

Datas importantes

- Prazo de submissão de relatos de experiência: 31/03/2009 (NOVA DATA)

- Notificação aos autores: 26/04/2009

- Entrega da versão final (camera-ready): 03/05/2009

- Entrega do material de apresentação (slides): 23/05/2009

Tópicos de interesse

Os temas de interesse do WGPS 2008 incluem relatos de experiências que revelem exemplos da aplicação de boas práticas de Gerenciamento de Projetos na área de Tecnologia da Informação, mais especificamente em software, sem, no entanto, se limitar a eles:

- Casos de Projetos bem sucedidos

- Lições Aprendidas em Projetos mal sucedidos

- Gerenciamento Ágil de Projetos

- Ferramentas de Gerenciamento de Projetos

- Análise de Viabilidade de Projetos

- Gerenciamento de Projetos no Contexto do CMMI e MPS-BR

- Garantia da Qualidade em Software

- Gerenciamento de Desenvolvimento de Produtos em Software

- Métricas de Software

- Gerenciamento de Riscos

- Comunicação em Projetos

- Corrente Crítica

- Gestão de Mudanças em Projetos de Software

- Gerência de Portfólio de Projetos

Submissão dos trabalhos

Prazo para submissão: 31/03/2009

Todos os trabalhos submetidos serão avaliados pelos membros do Comitê de Programa, formado por especialistas na área de Gerenciamento de Projetos. Os artigos devem obrigatoriamente atender aos seguintes critérios, todos eliminatórios:

- Seguir rigorosamente as instruções de formatação

- Não possuir qualquer tipo de Marketing de fornecedores ou produtos

- Apresentar resultados práticos

- Possuir relevância para a comunidade de Gerenciamento de Projetos, especialmente na área de Tecnologia da Informação

- Possuir atratividade para o público presente no WGPS

Os trabalhos selecionados deverão ser apresentados pelos autores durante o Workshop e serão publicados nos anais do evento. A submissão ao II WGPS deve ser feita através de um relato de experiência descrevendo e analisando a aplicação de processos, métodos ou ferramentas de gerenciamento de projetos, contextualizando a experiência e mostrando os resultados obtidos e lições aprendidas, em um caso prático, com contribuição para a indústria de software.

Os trabalhos devem ser submetidos diretamente de forma eletrônica pelo sistema JEMS, utilizando a seguinte página: https://submissoes.sbc.org.br/sbqs2009

Com relação ao formato, pede-se observar os requisitos a seguir, que são todos obrigatórios. O relato de experiência deve:- ser escrito em português ou inglês- ter entre 4 e 6 páginas, incluindo todas as figuras, referências e apêndices- seguir o formato definido pela SBC (Sociedade Brasileira de Computação), disponível em http://www.sbc.org.br, indo até a aba “Eventos”, janela “Arquivos” (à esquerda), item “Template para publicação de artigos”.- ser enviado no formato Adobe Portable Document Format (PDF) .

Coordenação

Dra. Sheila Reinehr

Email: sheila.reinehr@pucpr.br

Testando iphone

sábado, 21 de março de 2009

Ok

Certificações Top em Tecnologia para 2009

quinta-feira, 19 de março de 2009

“Escrevo aqui uma lista das certificações top em tecnologia para este ano de 2009. Os critérios para escolha foram baseados na relevância do mercado e popularidade discutidas no site About.com.

Como a lista foi baseada em um site internacional, não coloquei o salário estimado como eles fizeram, porque aqui no Brasil a realidade é outra e o salário é bem menor do que o praticado lá fora.

toptechcerts

CCIE: O CCIE sempre está no topo de listas como essas. Muito provavelmente porque somente 26% passam, o que pode ser considerada como a mais difícil de todas as certificações em TI.

CISA: Uma certificação para Auditores de Sistemas, que diferentemente das certificações de mercado com orientação a funcionalidade, que torna-se obsoleta com o tempo, a certificação CISA possui foco às melhores práticas e conhecimentos necessários à eficiência no processo de auditoria de sistemas.

CCSE: O CCSE é a certificação em Segurança mais avançada da CheckPoint. Um CCSE é capaz de, por exemplo, identificar riscos para uma rede, criar um diagrama de rede e definir uma política de segurança.

MCSD: Microsoft Certified Solution Developer (MCSD) é uma certificação para Microsoft .NET, onde desenvolvedores de primeira linha projetam e desenvolvem soluções empresariais com ferramentas de desenvolvimento, tecnologias e plataformas Microsoft e com o Microsoft .NET Framework.

PMP: É um rigoroso Programa de Certificação Profissional desenvolvido e mantido pelo PMI – Project Management Institute. É uma certificação que requer muita experiência e habilidades para obtê-la.

certificationachieveCISSP: Certificações em Segurança estão em alta. Pessoas com a CISSP (Certified Information Systems Security Professional) ganham bem e precisam fazer apenas um exame para tê-la. Obviamente, é preciso alguns anos de experiência.

RHCE: Red Hat Certified Engineer (RHCE) é um teste baseado em desempenho que mensura a competência em sistemas reais. A principal certificação em Linux do mercado, o RHCE comprova as habilidades de configurar os serviços de rede e segurança em sistemas rodando o Red Hat Enterprise Linux. São mais de 5 horas de testes “hands-on”.

SCJP 6.0: Caso tenha vontade de se tornar um programador profissional e se aprofundar nas tecnologias java, essa é a certificação que deve ser adquirida. Com o SCJP, o profissional tem a possibilidade de se desenvolver futuramente nas plataformas JSE, JEE e JME. Ele também pode usar o SCJP 6.0 para as certificações “Oracle Certified Solution Developer” e “Oracle Certified Enterprise Developer”.

CAPM: Criada para ser um intermediário até a obtenção da certificação PMP®, a CAPM é indicada para pessoas que procuram estabelecer e demonstrar uma base comum de conhecimento e termos no campo do gerenciamento de projetos.”

Fonte:  GotchaIT

Adiciona a esta lista três certificações:

- LPI (agora atualizada e com a nova versão 303 – só existe um no Brasil, o meu amigo Leonardo Neves )

- Zend PHP 5 Certification – esta “separa o jóio do trigo”

- Zend Framework Certification – esta certifica que além da sintaxe o programador PHP tem o mínimo de procupação com padrões de projetos e engenharia de software

O princípio EUquipe na criação de software

quarta-feira, 18 de março de 2009

Era uma vez… um anúncio de emprego:

“Vaga: Estagiário de Sistemas/ Estagiário de Desenvolvimento
Requisitos:
- Formação superior em andamento na área de informática
- Inglês técnico
- Prática em programação web e teste de software

Conhecimentos desejáveis:
- Programação desktop
- Conhecimentos sobre webservices e xml
- UML, RUP e XP

Irá atuar em todas as fases do desenvolvimento de software: modelagem de negócios, análise de requisitos, projeto de software, implementação (principalmente), teste de software e implantação. Além de atuar na manutenção dos sistemas auais e suporte ao usuário.”

Esse pode parecer um anúncio de emprego do tipo Caracu, na qual o empregador entra com a cara e o candidato com o complemento. Mas nele se esconde, o princípio Euquipe.

A vantagem da área de tecnologia na área de empregos é que pode-se começar a trabalhar muito cedo. Aprende-se a programar sozinho, com alguma boa vontade, internet e/ou livros e muitas horas sentado escrevendo códigos, testando algoritmos, etc.

A questão é que desenvolvimento de software profissional deixou de ser uma atividade solitária de software e virou uma cadeia produtiva com especializações em diversas áreas e o conjunto delas é conhecido como Engenharia de Software. Da mesma forma que a Engenharia tradicional diversificou-se entre Civil, Mecânica, Elétrica, etc. A profissão ainda é nova e há uma enorme confusão até mesmo dentro do meio acadêmico.

O que é Engenharia de Software?

São um grupo de áreas de conhecimento que definem como criar e entregar software. De acordo com o IEEE Computer Society Software Engineering Body of Knowledge (SWEBOK), a lista de de Áreas de Conhecimento (KA ou Knowledge Area) é composta por:

  • Software requirements
  • Software design
  • Software construction
  • Software testing
  • Software maintenance
  • Software configuration management
  • Software engineering management
  • Software engineering process
  • Software engineering tools and methods
  • Software quality

Então imagine o super-estagiário que os canalhas acima querem laçar. Se traçarmos um paralelo com medicina, eles querem um: cirurgião geral, com especialização em neurologia, pneumologia, hematologia, barba, cabelo e bigode (depilar mulheres é um plus).

A culpa não é do RH das empresas, mas da cultura corporativa industrial: minimizar com a “mão de obra”. Em tecnologia é um das maiores fontes de gasto, mas também, a única geradora de renda, através de solução de problemas e inovação. Os profissionais resolvem um problema e se expressam em ferramentas, scripts, programas de computador, diagramas, documentos, planilhas, apresentações. Ou seja, você precisa de cérebros capazes de tratar, interpretar e apresentar informação, não apertadores de botões.

Para de enrolar Bicalho, o que é o Princípio Euquipe?

1. Princípio Euquipe é quando uma empresa ou prestador de serviço resolve economizar todo o processo de produção de software em cima de um único profissional. Todas as responsabilidades, do levantamento de requisitos, implementação, testes e homologação, manutenção e implantação, ficam sob os ombros de uma única pessoa.

É a sabotagem de um projeto antes mesmo de iniciado e uma atitude de mau caratismo. Tanta importância delegada a um único indivíduo não é motivo de comemoração. É a velha mania de terceirização da culpa, o “tirar da reta” para depois dizer: O fracasso do projeto foi porque o(a) Euquipe da Silva é um(a)  incompetente. Tudo estava sob responsabilidade dele(a) e deixou o projeto afundar.

E quem estava responsável pelo trabalho do profissional? Dessa pergunta, vem a segunda definição do Princípio Euquipe:

2. Ninguém é incompetente sozinho.

“Tudo o que é preciso para o mal prevalecer são os bons não fazerem nada.” (Edmund Burke)

Fonte:
Meiobit

Bicalho’s Memory About Fraked Up Jobs, Websites de Emprego, SWEBOK

Modelagem de Negócios: A Encruzilhada por Paulo Vasconcellos

terça-feira, 17 de março de 2009

Se não vai no atacado, vai no varejo mesmo!1 Há tempos ameaço retomar a publicação de artigos técnicos aqui no finito. Tardei. Espero não falhar.

Já comentei por aqui: a modelagem de negócios é, entre todas as disciplinas que dão forma para a engenharia de software, a menos compreendida. Consequentemente é pouco e mal utilizada. No entanto, surgem evidências e suspeitas de que esta situação deve mudar. Iniciativas SOA, BPM e de Arquitetura Corporativa, em níveis diferentes, exigem a existência ou a criação de modelos de negócios. Mas não se trata de outra demanda ‘falsa’, parida exclusivamente nos domínios de TI. O pessoal do mundo do negócio também começou a perceber os benefícios de bons modelos de negócios. O que nos traz para a encruzilhada do título. Neste artigo vou apresentar duas alternativas de modelagem, uma bem TI e outra bem “negócio”. Ambas foram apresentadas em livros lançados recentemente. E indicam um momento crítico para a evolução da disciplina.

Encruzilhada

Modelando Negócios, segundo TI

Acabou de sair, pela Morgan Kaufmann/OMG (Object Management Group), o livro “Business Modeling – A Practical Guide to Realizing Business Value“, de David M. Bridgeland e Ron Zahavi. Como obras que tratam exclusivamente a modelagem de negócios ainda são raríssimas, este lançamento merece destaque. E vai receber. Repare, não se trata de um livro sobre BPM e afins. O papo aqui é apenas sobre modelagem. Os autores, otimistas, começam mostrando que a tendência é de uma crescente adoção da disciplina. E apostam que por volta de 2011 ela atingirá “massa crítica”2. Justificam suas apostas de forma simples: “a Modelagem de Negócios se tornou mais popular porque transformações em negócios se tornaram mais comuns“. E explicam que “modelos ajudam na implementação de mudanças. Se nada muda, você não precisa de modelos, assim como não precisa de mapas se não pretende viajar para lugar nenhum“.Business Modeling

Os autores mostram que a modelagem pode gerar valor para o negócio de oito maneiras: i) Comunicação entre pessoas; ii) Treinamento e Aprendizado; iii) Persuasão e Vendas; iv) Análise de alguma situação do negócio; v) Gestão de Conformidade; vi) Desenvolvimento de Requisitos de Software; vii) Execução direta dos modelos através de mecanismos de software; e viii) Gestão do Conhecimento e Reuso.

A lista, apesar de extensa, me parece incompleta. Neste ponto os autores não citaram a possibilidade de simulação e experimentação de novas ideias e a identificação de oportunidades de outsourcing de processos (BPÒ), por exemplo. Mas as omissões são relativamente pequenas. O que me preocupa de verdade são as sugestões apresentadas no livro.

Bridgeland e Zahavi partem do princípio de que não há um padrão completo para a modelagem de negócios. E não deixam de reclamar em diversos momentos do texto a total ausência de ferramentas que contemplem uma “completa” modelagem. Eles apresentam a modelagem como um conjunto de 4 disciplinas: Modelagem da Motivação do Negócio, da Organização, dos Processos e das Regras. Completo, na visão deles, seria um padrão que possibilitasse a criação de modelos das 4 disciplinas. Eu acredito que o problema foi criado pelos próprios autores, no “quebra-cabeças” de padrões que eles selecionaram.

Para a modelagem da motivação do negócio eles optaram por um novíssimo e único padrão existente, o BMM (Business Motivation Model), um trabalho do BRG (Business Rules Group) aceito pelo OMG em agosto de 2008. Como os próprios autores acusam, o OMG cometeu grave pecado ao aceitar e liberar o padrão antes de definir seu perfil visual – um padrão para os diagramas. O BMM cuida da visão (fim) e da missão (meios) de um negócio, de maneira abrangente e consistente. Mas parece uma ilha isolada do resto do mundo. Não se relaciona com nenhum padrão existente. Talvez o OMG tente incorporá-lo futuramente a algum metamodelo. No entanto, quando o assunto é o OMG e seus constituintes, tudo é incerto.

Há tempos eu joguei todas as minhas fichas na EPBE (Eriksson-Penker Business Extensions). E sempre reconheci que a forma como essa extensão trata dos objetivos (motivações) do negócio é fraca. Por isso apresento mapas estratégicos e BSC’s (Balanced Scorecards) como complementos. Como a EPBE é extensível como sua base, a UML, não tive nenhuma dificuldade em incorporar a ela o BMM. Oportunamente eu falo mais sobre BMM e EPBE. Mas se você não aguenta de curiosidade, relembre aqui o metamodelo EPBE e obtenha aqui uma visão geral (bem alto nível) do BMM.

O problema dos autores aumenta quando eles entram em sua segunda disciplina, a Modelagem da Organização. Eles afimam que não haveria um padrão para a construção desses modelos. Quem diria, nossos velhos e bons organogramas carecem de um padrão. Mas a questão não é só essa. Bridgeland e Zahavi ignoram outros recursos, outros elementos da estrutura de um negócio. Não citam, por exemplo, a necessidade de modelagem de produtos, serviços etc. A EPBE fala em Visão da Estrutura, não de Modelagem da Organização. A EPBE contempla, portanto, a modelagem de qualquer tipo de recurso.

É fácil entender a omissão ao vermos o padrão que eles selecionaram para a Modelagem de Processos. Sim, eles optaram pela BPMN. Um padrão cheio de promessas e com um futuro promissor, mas que entrega muito pouco quando o assunto é *Modelagem de Negócios*.Sigo aguardando ansioso pelo dia em que uma boa alma apareça dizendo: “gente, BPMN é só um fluxograma 3.0 – um falso padrão3 sacaneado por ilustres fornecedores que deveriam defendê-lo. Um falso padrão que tem pouco ou nenhum valor quando nossa preocupação é entender um negócio“.

Os autores justificam sua não opção pela UML dizendo que esta é muito ‘complicada’ para usuários finais. Concordo. Mas, apesar deles citarem o trabalho de Eriksson e Penker, “Business Modeling with UML“, ignoram por completo a EPBE. Ao relacionarem UML exclusivamente com o diagrama de atividades, demonstram desconhecer todas as outras opções de diagramas apresentadas no trabalho da dupla escandinava. Sigo desconfiado de que é este pequeno detalhe geográfico que segue fazendo da EPBE uma ilustre desconhecida.

Problema dos autores, que tiveram que se revirar ainda mais no momento de fixar um padrão para sua última disciplina, a Modelagem de Regras. Acertam na escolha do SBVR (Semantics of Business Vocabulary and Business Rules), outro padrão adotado pelo OMG em 2008. Mas não conseguem deixar de mostrar a fragilidade das ligações desta com as outras 3 disciplinas que formam sua proposta. Eles reclamam muito da deficiência de ferramentas. O buraco é mais embaixo: os 4 padrões sugeridos pelos autores carecem de um alicerce único, de um metamodelo. Ao jogarem todas as suas fichas em padrões do OMG, implicitamente os autores apostam que esta entidade será capaz de suprir essa imensa necessidade. Ao ver os probleminhas que o OMG tem enfrentado só com a BPMN 2.0, sou obrigado a ‘mineiramente’ desconfiar. Com seus passos de cágado, talvez lá em 2037 o OMG apresente uma bela sugestão de metamodelo para uma completa modelagem de negócios. Vamos esperar sentados?

O Negócio pelo Negócio

É um livro de modelagem?!?Aí vem aquele “velho” cara de negócios e pergunta: “meu caro, diz aí, o tal OMG entende de negócios?” Antes que uma resposta (ou desculpa) pinte em nossas cabeças, o velho saca de sua estante um estranho livro quadrado: “The Back of the Napkin“, de Dan Roam (Portfolio – 2008). O velho nos diz: “Parece que o tal do Dan aí entende de negócios, e presta serviços de consultoria para empresas como Google, eBay, GE, Wal-Mart…

Se o livro de Dan Roam usou o termo “modelagem” em algum momento passou despercebido. Ele prefere o termo “Pensamento Visual”. Mas seu livro é só sobre isso: Modelagem de Negócios. Saca só o subtítulo: “Resolvendo Problemas e Vendendo Ideias com Figuras”. Não espere ver nada sobre UML, BPMN e coisinhas afins. Dan é um cara de negócios. E, por isso mesmo, insiste que devemos fugir de ferramentas informatizadas: “mão, caneta e guardanapos são suficientes para resolvermos qualquer problema de negócio!” Radical? Não, prático e pragmático mesmo. E, preciso dizer, ágil!

Dan apresenta uma metodologia completa, formada por 4 elementos. Ele a apresenta como um “canivete suiço”. Sua primeira parte é formada por “3 ferramentas básicas para o pensamento visual”: nossos olhos, mente e mãos. Na sequência ele apresenta as 4 fases do pensamento visual: Ver, Observar, Imaginar e Mostrar4.Aí vem o SQVID5, uma série de 5 perguntas que “nos ajuda a abrir os olhos da mente: simples ou elaborado, qualitativo ou quantitativo, visão ou execução, individual ou comparações, mudança ou ‘as-is’?” Por fim as 6 formas como enxergamos que também são as formas como deveríamos mostrar, os 6W’s: “Who/what, hoW much, Where, When, hoW e Why”. Parece bobinho, não? Se você não reparou, até a sequência como o “canivete” é apresentado é “simplificadora”: 3 (ferramentas básicas), 4 (passos), 5 (perguntas) e 6 (formas de ver/mostrar).

Parece bobinho, mas Dan escora suas sugestões em bases muitos fortes, como pesquisas muito recentes no campo da neurobiologia. Os 6 W’s, por exemplo, realmente representam a sequência pela qual nossos olhos passam informações para o cérebro. Por isso seriam intuitivas, naturais. Logo no início do livro o autor se preocupa em “escorar” suas sugestões. Em três páginas quase consecutivas ele nos convida a visitar o apêndice A, “A Ciência do Pensamento Visual”. Justamente para derrubar nossas possíveis desconfianças e mostrar que, apesar de simples, suas propostas são sérias. Aliás, a simplicidade é uma grande qualidade de seu trabalho. Porém, mais que o alicerce científico, são os casos reais apresentados que atestam a utilidade e força de seu método.

O ‘Codex’ do Pensamento VisualAcontece que, a primeira vista, as sugestões de Dan Roam parecem totalmente incompatíveis com a disciplina que conhecemos como Modelagem de Negócios. Em nenhum momento ele cita o OMG ou coisinhas mais ‘pop’, como BPMN. Trata-se realmente de outro mundo.

O diagrama ao lado mostra do “CODEX” do Pensamento Visual, uma grade que cruza os 6 W’s com as 5 decisões que tomamos no SQVID. Repare que, para cada W, Dan sugere apenas um tipo de desenho: retrato para o “quem/o que”; gráfico de barras para o “quanto”; mapas para o “onde”; cronograma ou linha de tempo para o “quando”; fluxograma para o “como”; e um gráfico comparativo (plot) para o “porque”. O SQVID ajuda a definir uma versão diferente para cada tipo de desenho.A única sugestão de Dan que se aproxima minimamente de nosso mundo é o fluxograma. Todos os outros desenhos parecem distantes de tudo que conhecemos para a modelagem de negócios: retratos, mapas, gráficos de barras…

Precisa ser assim? Digo, TI e negócio precisam ser tão distantes até nisso, numa disciplina que deveria ajudar um a compreender melhor o outro? O mundo de TI precisa seguir insistindo em padrões lentamente definidos e sistematicamente desrespeitados?

Como a Modelagem de Negócios é uma disciplina ainda em fase de definição, acho que é hora de revermos alguns caminhos, particularmente aqueles trilhados pelo OMG e fornecedores de ferramentas como SAP, IBM e Oracle.

Em paralelo, os Analistas de Negócios, principais usuários da Modelagem de Negócios, devem procurar uma base que combine o melhor dos dois mundos. No próximo artigo apresentarei uma sugestão, um ‘remix’ das ideias de Dan executado na vitrola da EPBE/UML. Inté!

Notas:

  1. O “atacado” seria o livro, que já toca neste assunto (com outras palavras. Aliás, muito mais palavras e figuras). Mas, como eu já disse em um pequeno post-agenda, não se trata apenas de um livro, mas também de um novo negócio e um sistema. Adiei o lançamento para costurar melhor todas as partes. Conto com a compreensão e paciência de todos.
  2. Em dinâmica social, massa crítica é a mentalidade de um grupo que é suficiente para, em quantidade e qualidade, permitir, propiciar e sustentar determinada ação ou comportamento. (Wikipedia).
  3. Digo que BPMN é um falso padrão porque ele não é respeitado por quase ninguém. Grandes fornecedores, como IBM, Oracle e SAP, insistem em ter seu “sabor” do padrão. Claro, assim eles dificultam a debandada de clientes insatisfeitos. Nada de novo no front de TI: SQL, HTML, COBOL e várias outras coisinhas também nasceram um dia para serem “padrões”.
  4. Minha tradução livre para Look, See, Imagine e Show.
  5. SQVID é uma sigla estranha mas de fácil compreensão: Simple, Quality, Vision, Individual e Change (D é de delta, mudança). O SQVID é apresentado como um seletor ou equalizador. O nome indica as primeiras opções. O contraponto, na mesma sequência, é: Elaborate, Quantity, Execution, Comparison e As-is.  Como o gráfico acima ilustra, para cada um dos 6 W’s escolhemos um lado do SQVID. Simples ou Elaborado, por exemplo.

A foto utilizada neste artigo é de Kevin Slavin (Flickr). Aliás, vale a pena olhar o curioso jogo “Crossroads” que ele montou com GPS, usando Manhatan como tabuleiro.

Fonte: Finito

Qualidade de Software: custo ou investimento?

sábado, 14 de março de 2009

“O triângulo equilátero da gerência de projetos teve que sofrer ajuste. A máxima de que projetos de software são afetados somente por Custo, Tempo e Escopo caiu por terra. Atualmente um item, antes útil, que agora se torna diferencial competitivo, é “a tal” da Qualidade.

Mas o que é qualidade para você? E o que é qualidade de um software?
O meu conceito de qualidade de software pode ser um e para o cliente do projeto, outro completamente diferente. Num portal de notícias você aceitaria erros de língua portuguesa (com ou sem nova norma ortográfica da Língua Portuguesa)? E um e-commerce, seria tolerável sua venda não ser concluída por erro?

O conceito de qualidade é muito subjetivo, mas o fato é que todos nós, e o cliente não será exceção neste quesito, temos um padrão de qualidade esperado.

E quanto custa ter a qualidade desejada para o seu “sisteminha” funcionar corretamente? Opa! Corretamente? Acurácia é uma das Subcaracterística da Qualidade, segundo a Norma ISO/IEC 9126-1. É preciso profissionais capacitados e isso ainda é um dilema mesmo com o crescente número de certificações na área, cursos de formação e até MBA.

Testar com T maiúsculo

Muita gente ainda pensa, digo, gerentes, que testar é só sentar e ficar batucando o teclado ou dedilhando o mouse até que alguma coisa aconteça e que você nem saiba como foi causado. É preciso uma série de processos, conhecimentos, experiência e talento para esta atividade ainda tão negligenciada.

Bons profissionais de teste custam tão caro quanto muitos desenvolvedores, mas como ainda é uma área pouco valorizada pela maioria, guardemos as devidas proporções salariais.

É preciso prazo para que as atividades de teste sejam feitas de forma relevante ou do contrário será somente feito o Monkey Test: aquele teste que uma criança ou um macaco podem fazer e que, certamente, não garante absolutamente nada de qualidade.

Um erro muito cometido é deixar a atividade de teste para o final do desenvolvimento. A fase de desenvolvimento atrasa (ou isso só acontece nas Bahamas?), mas o tempo para testar parece não ser abalado por isso. Comparo a um paredão de tijolos: não é possível passar através dele.

Acredito que o sonho de todo bom desenvolvedor é ver um bug bem relatado, com passo a passo executado, resultado encontrado, resultado esperado, evidência do teste etc. Se os bugs são inevitáveis, que pelo menos sejam bem reportados. Isso é o mínimo aceitável. Sim, você também tem seu critério de qualidade e aceitação para atividades do cotidiano e por que não no seu trabalho?

Perfil profissional: não é para todos

Mas não pense que é qualquer um que pode sentar e testar. “Coisa de programador frustrado”, “atividade de segunda linha”, “analista de sistema que não é inteligente o bastante pra ser programador”… Tudo isso já ouvi dizer sobre testadores e/ou analistas de teste.
Isso não é verdade. Assim como existem desenvolvedores medíocres, existem testadores medíocres, gerentes medíocres e assim por diante em qualquer área de atuação profissional.
Entretanto, profissionais pouco qualificados, que são jogados ou caem de pára-quedas na área de teste, estão denegrindo a imagem desta.

Mas tenho que concordar que ouvir alguém que se diz Analista de Teste falar “pá mim fazer”, escrever “ecessão” entre tantas outras pérolas, dá medo só de pensar no resultado dos testes.

Algumas empresas antenadas com a nova tendência mundial de preocupação com a qualidade como diferencial competitivo, tem investido na formação de equipes de teste e ferramentas para automação. Pena que a maioria das empresas ainda veem como custo e não como investimento.”

Fonte: Fórum Meiobit

Scrum no jornal O Globo!

sexta-feira, 13 de março de 2009

No último domingo, dia 15/02/2009, foi publicado no caderno “Boa Chance” do Jornal O Globo uma matéria de duas páginas sobre o Scrum. O repórter Rodrigo March conseguiu explicar, de forma muito didática, o que é Scrum e as suas principais vantagens e o que leva o Scrum a ter o destaque que tem hoje quando fala-se de métodos ágeis de desenvolvimento de software.

Entrei em contato com o Rodrigo, e consegui, além de autorização para publicar a matéria aqui no site, a matéria em si em formato PDF, o que facilita MUITO a leitura da mesma. Ana Cristina Roullier, coordenadora do scrum.org.br, foi entrevistada para a criação desta matéria, e teceu alguns comentários que estão na segunda parte.

Para ver/baixar os PDF da matéria, clique:

aqui, para primeira parte (1,8MB)

aqui, para segunda parte (650KB)

Gostaria de registrar um agradecimento ao Rodrigo March, do jornal O Globo, por colaborar com o scrum.org.br e permitir a divulgação e veiculação da matéria na íntegra!

fonte: scrum.org.br

O que acontece quando você junta 24 cartões Samsung de 256 GB SSD?

quinta-feira, 12 de março de 2009

Meu  computador principal é muito rápido, com um belo overclocked Core 2 Duo, memória RAM e uma rápida placa de vídeo. Infelizmente ele não tem uma peça abrandar o.  Enquanto meu disco rígido é SATA, eu amaria substitui-lo por um drive SSD mais rápido. Minha questão principal é que a velocidade que ganho não justifica o preço. Mas e se o preço não for objeto? Era o que poderia fazer com que você diga, 24 drives SSD top de linha? Você pode abrir todo o Microsoft Office em meio segundo. Você tem uma taxa de transferência de 2GB/s. Você ainda poderá fazer o vídeo visto acima.

VIA [ Dvice ]

Tradução: Scrum Falácio

quarta-feira, 11 de março de 2009

5 dias atrás, Martin Fowler escreveu um artigo que pode ser um pouco polêmico para Scrummers, mas não vejam isso como uma crítica ao Scrum e sim como uma crítica a quem aplica Scrum da maneira errada e a quem não se preocupar em tornar isso aparente. A seguir eu traduzi o artigo dele na íntegra, e no final coloquei alguns comentários meu mesmo.

Existe uma bagunça que eu ouço em muitos projetos recentemente. Funciona assim:

  • Eles querem usar um processo ágil, e escolhem Scrum
  • Eles adotam as práticas Scrum, e talvez até os princípios
  • Depois de um tempo o progresso é lento porque a base de código é uma bagunça

O que acontece é que eles não prestaram atenção à qualidade interna de seu software. Se você cometer esse erro irá rapidamente descobrir que seu progresso foi desacelerado porque é muito difícil adicionar novas funcionalidades que você gostaria. Você caiu no problema de Débito Técnico e seu scrum caiu de joelhos. (E se você esteve num scrum real, saberá que isso é uma Coisa Ruim).

Mencionei Scrum porque quando vemos esse problema, Scrum parece ser particularmente comum como o processo nominativo que a equipe segue. Para muitas pessoas, a situação é exacerbada pelo Scrum porque Scrum é um processo centrado em técnicas de gerenciamento de projetos e deliberadamente omite qualquer prática técnica, em contraste (por exemplo) com Extreme Programming.

Defendendo o Scrum, é importante apontar que só porque ele não inclui nenhuma atividade técnica dentro de seu escopo isso não deve levar ninguém a concluir que ele não acha isso importante. Sempre que ouvi Scrummers prominentes eles sempre enfatizaram que você deve ter boas práticas técnicas para ter sucesso com um projeto Scrum. Eles não dizem quais práticas técnicas devem ser, mas você precisa delas. Afinal projetos enfrentam problemas por causa de qualidade interna pobre o tempo todo, e o fato que muitos entram abaixo da bandeira do Scrum parece ser mais pelo fato de Scrum ser popular no momento do que qualquer coisa particular no Scrum. Popularidade e Difusão Semântica tendem a andar juntos.

Então, o que fazer a respeito?

A comunidade Scrum precisa redobrar seus esforços em garantir que as pessoas entendam a importância de práticas técnicas fortes. Certamente qualquer tipo de revisão de projeto deve incluir o exame de quais práticas técnicas estão presentes. Se você estiver envolvido ou conectado a esse tipo de projeto, faça um barulho se o lado técnico estiver sendo negligenciado.

Se estiver apresentando Scrum, garanta que está prestando atenção às práticas técnicas. Tendemos a aplicar muitas do Extreme Programming e eles se encaixam muito bem. Os XPers costumam brincar que, com alguma justificativa, Scrum é apenas XP sem as práticas técnicas que a fazem funcionar. De qualquer forma, as práticas de XP são um bom ponto para se começar – e certamente serão muito melhores do que nada.

Eu sempre gosto de apontar que não são metodologias que levam ao sucesso ou fracasso. Usar um processo pode ajudar uma equipe a subir no jogo, mas no fim é a equipe que importa e que carrega a responsabilidade de fazer o que funciona para elas. Estou certo que muitos dos projetos Scrum Flácidos em andamento prejudicarão a reputação do Scrum, e provavelmente a reputação maior de Ágil. Mas já que vejo Difusão Semântica como algo inevitável não estou desproporcionadamente alarmado. Equipes que fracassam provavelmente vão fracassar seja lá qual metodologias eles – erradamente – apliquem, equipes que tem sucesso construirão suas práticas sobre boas idéias e o papel da comunidade scrum é espalhar essas boas idéias.

Muitas pessoas estão olhando para Lean como a Próxima Grande Coisa Ágil. Mas quanto mais popular lean se tornar mais vai incorrer nos mesmos problemas que Scrum está enfrentando agora mesmo. Isso não torna Lean (ou Scrum) sem valor, apenas nos lembra que Indivíduos e Interações são mais valiosos que Processos e Ferramentas.

Observações do Akita

Em termos práticos, no meu caso, já percebi que coisas de planejamento e gerenciamento como User Stories, Release Planning, Small Releases, Project Velocity, Iterations, Iteration Planning, Stand Up Meeting, são as partes que parecem ter menos resistência de implementação. A razão é que, quando uma empresa decide adotar Scrum, já é algo que veio de algum nível de cima para baixo – ou não seria implementado. E gerentes e chefes costumam entender e engolir esses conceitos mais ou menos bem, especialmente se já passaram por metodologias tradicionais de gerenciamento de projeto sem êxito. E é aqui onde a maioria erra: se as equipes ainda não tem maturidade para serem auto-gerenciável (ou seja, gerar código de qualidade de maneira independente) é obrigação da alta chefia liderar para essa direção. Isso é difícil porque muitos gerentes não são técnicos, o que os torna alienados ao problema do não uso das boas práticas técnicas.

A bagunça a que Martin Fowler se refere está no Design, Codificação e Testes. A maioria dos desenvolvedores que: 1) veio de jeitos antigos de desenvolvimento (ex. estilo “cowboy suicida”); 2) têm pouca experiência e estudo de desenvolvimento de software em geral; tem dificuldade de entender essas práticas.

A maioria dos desenvolvedores não entende Simplicidade, o famoso “fazer a coisa mais simples que funciona” ou YAGNI (You Ain’t Gonna Need it). Especialmente se são jovens, o espírito “cowboy” é difícil de domar e sempre querem fazer as coisas de forma mais complexa do que precisam. Isso leva justamente ao problema de adicionar coisas cedo demais, ou complexidade pelo prazer da complexidade. A equipe precisa de auto-policiar contra isso. Felizmente Spike Solutions não parece tão ruim hoje em dia, onde a equipe pára um instante, entende o problema e estuda alternativas de solução. Outro problema, por muitas vezes já vi pessoas confundirem Refactor com Rewrite. Rewrite em si não é um problema, mas se torna um problema se aplicado com a noção de “só porque é novo, é melhor”. Antes de mais nada, Refactoring é uma série de técnicas que tem como objetivo rejuvenescer o código, torná-lo mais gerenciável, sem modificar seu comportamento.

Isso leva ao calcanhar de aquiles da maioria dos desenvolvedores amadores: a aversão à testes. “Sou bom demais para errar, não preciso de testes.” É o desenvolvedor que efetivamente levará seu trabalho ao fracasso certo. Testar antes é uma maneira efetiva de refinamento do design e também leva à Simplicidade, fazendo apenas o que realmente se precisa. Sem bons testes, é impossível fazer um refactoring efetivo pois como você pode garantir que a mudança não levou a mudança no comportamento do código. O corolário disso é que os desenvolvedores também não praticam Refactoring, o que leva à massa de código bagunçado. A ironia disso é que até em rewrites – onde se assumiu que o novo seria melhor – acaba se tornando um “legado” bem rápido.Pior ainda, quando um bug é encontrado, raramente se criam testes para evitar a regressão ao mesmo bug. E todos já devem ter visto bugs que supostamente já estavam corrigidos retornando pouco tempo depois. Outro problema é que muitas equipes não encontraram uma boa definição para o “história finalizada” e portanto também tem dificuldades em ter e manter testes de aceitação dessas histórias. Uma das razões disso são equipes que, em vez de escreverem User Stories (“como X, quero Y por causa de Z”, definindo o que implementar, para quem e qual valor isso trás), escrevem Tarefas (“fazer X”, pulando para quem é e qual valor isso trás).

Ainda no espírito de “cowboy”, novamente, programadores sem experiência, não entendem o conceito de propriedade coletiva do código. O que acontece é que cada desenvolvedor tenta se limitar apenas ao código que ele acha que é responsabilidade dele e não se preocupa com o todo. Porém o contrário deveria acontecer: todo desenvolvedor tem que se sentir responsável por todo o código. Isso também explica mais um motivo da importância de testes unitários: sem eles é impossível ajudar em código que você não fez, também é impossível saber se seu próprio código não quebra algo que outra pessoa fez. Em resumo: isso leva a um acúmulo imensurável de “Débito Técnico” que só se vê quando já é tarde demais, tornando seu “novo sistema”, prematuramente um “legado” ingerenciável. Ainda nesse espírito, os desenvolvedores “cowboys” não integram com frequência como deveriam. Não é raro ver desenvolvedores que fazem um novo trecho de código a semana toda apenas na sua máquina e só no final da semana apenas fazem o commit no repositório e consideram terminado. Nada de criar testes, nada de rodar a suíte completa de testes. Mais um desenvolvedor criando Débito Técnico deliberadamente.

Para piorar, não é difícil encontrar equipes que sequer entendem o valor de um repositório: para eles, basta alterar direto no servidor de produção ou editar arquivos diretamente lá. É a pré-história do desenvolvimento. Um repositório de versionamento de código não é opcional: é mandatório. Tratá-lo como um santuário é a maior responsabilidade de uma equipe e isso significa que todo código no repositório deve ser sempre código sem absolutamente nenhum problema que foi acrescentado de forma deliberada (por não fazer testes, não integrar frequentemente, não refatorar onde precisa, etc). Bugs sempre vão existir e devem ser corrigidos, mas erros deliberados torna o desenvolvedor um irresponsável e um problema à toda a equipe.

Finalmente, é comum ver desenvolvedores que se acham muito espertos otimizando muito cedo no projeto, baseado apenas em “chute”, sem medições. Aliás, a maioria dos programadores que conheci tem aversão à medições tanto quanto tem aversão à testes. E otimizar sem estar baseado em métrica é a mais pura perda de tempo. Você pode fazer um certo trecho de código ficar 100 vezes mais rápido, mas se no tempo geral isso não representa um ganho nem de 0.5%, foi uma perda de tempo. Novamente, falta de experiência.

Ainda sobre os “cowboys suicidas”, normalmente eles são apegados às suas – limitadas – ferramentas, às quais estão já acostumados, tem preguiça – incapacidade, ou falta de vontade – de aprender coisas novas, e sempre tentam ir pelo caminho imediatamente – e aparentemente – mais fácil, como usar geradores automáticos de código, que geralmente geram código difícil de dar manutenção e também normalmente fora dos padrões mais modernos aceitos como boas práticas.

No final, o resultado é o mesmo: desenvolvedores inexperientes que acham que sabem tudo, ou desenvolvedores com muito tempo de casa viciados em anti-práticas e teimosos demais para aprender as boas práticas. Montar uma equipe eficiente e verdadeiramente Ágil de desenvolvimento é muito difícil. E a realidade é que simplesmente nem todo mundo serve para o trabalho. Um desenvolvedor Ágil é alguém pró-ativo, autodidata, sociável e comunicativo. E tudo isso é mais importante que sua suposta competência técnica.

PS: algumas pessoas podem achar que isso é algo direto e elas. Mas na realidade, isso é mais comum do que se imagina, já vi em muitos clientes e vou continuar vendo. Sendo justo, eu mesmo já fiz muito projeto (mais do que gostaria) que imediatamente se tornou um “legado”, um código mal testado e difícil de manter. Reclamar é fácil, fazer algo para melhorar é que é o difícil, e o desenvolvedor cowboy de ontem tem todas as condições de se tornar um bom programador amanhã, basta querer.

Fonte: akitaonrails