Por IDG News Service/EUA
Publicada em 30 de março de 2009 às 10h02
Atualizada em 30 de março de 2009 às 10h03

Boston – “Open Cloud Manifesto” defende que “desafios da adoção da cloud computing sejam solucionados a partir de padrões abertos”.

Vazou na internet o “Open Cloud Manifesto”, um documento que define padrões de interoperabilidade para a “cloud computing”, conceito que determina que uma parte importante dos dados e aplicativos de um usuário fica instalada e é acessada pela internet e não no desktop. Após o vazamento, dezenas de empresas de tecnologia decidiram assinar e publicar o manifesto oficialmente.

Com apenas seis páginas, o documento contém seis princípios básicos. O primeiro pede para que fornecedores de tecnologia “garantam que os desafios da adoção da cloud computing (segurança, integração, portabilidade, interoperabilidade, administração e monitoração) sejam solucionados através de padrões abertos”.

Outros princípios dizem que os desenvolvedores “não devem usar suas posições no mercado para amarrar clientes em suas plataformas exclusivas”, “criar novos padrões ou modificar padrões existentes”, “se concentrar nas necessidades dos clientes” e tentar trabalhar em harmonia.

Entre as empresas que apoiam o Open Cloud Manifesto estão a IBM, Sun, VMware, Cisco, EMC, SAP, AMD, Elastra, Akamai, Novell, Rackspace, RightScale, GoGrid, entre outras. Já a Amazon, conhecida pelo seu sistema, o Elastic Cloud Computing (EC2), e a Microsoft, que deve lançar o sistema Azure de cloud computing ainda neste ano, decidiram não participar da iniciativa.

Uma porta-voz da Amazon disse que a empresa só ficou sabendo do manifesto recentemente e está avaliando “as ideias, padrões e práticas” sugeridas. Já Steven Martin, um funcionário da Microsoft, criticou pesadamente o documento, afirmando que o manifesto “é falho e foi concebido secretamente

Analistas ouvidos pela reportagem do IDG News Service consideram o manifesto uma boa iniciativa, mas demonstraram ceticismo. “O documento vai na direção certa”, disse Stephen O’Grady. “Você poderia esperar alguns anos (para discutir o assunto), quando os clientes estariam presos a algum tipo de solução. Ou você pode tentar abordar esses problemas agora.”

Segundo O’Grady, problemas com a dependência de consumidores a um sistema específico e interoperabilidade são muito mais importantes na cloud computing. Na computação “tradicional”, os clientes escolhem hardware, sistemas operacionais, bancos de dados e ferramentas de desenvolvimento separadamente. Na nuvem, porém, esses programas costumam estar integrados, muitas vezes com aplicativos proprietários. “Quando você funde todas essas peças, você remove várias escolhas. Os clientes costumam ter problemas com isso”, disse O’Grady.

Para John Willis, um analista e blogueiro, o manifesto tem a função de, pelo menos, envolver os fornecedores de tecnologia com padrões abertos e interoperabilidade. “Se essas empresas vão assinar esse documento, então o mercado terá como fiscalizar se as iniciativas estão sendo cumpridas.”

Chris Kanaracus, editor do IDG News Service, em Boston

Fonte: IDG Now

Por Fábio Akita em Março 30, 2009

Durante o Encontro de TI que teve esse sábado, tive a chance de trocar idéias com o Guilherme Chapiewski. Caímos no assunto de Net Negative Producing Programmer (NNPP). Eu li sobre esse termo pela primeira vez no artigo do Jay Fields. Depois dele outros bloggers exploraram mais o assunto como o Kris Kemper. Tem também um paper do G. Gordon Schulmeyer explorando em mais detalhes ainda. De qualquer forma, o resumo da ópera é o seguinte:

“Retirar um elemento tecnicamente ruim de uma equipe pode ser mais produtivo do que adicionar um elemento melhor capacitado.”

Ou seja, descobriu que você tem um programador ruim: demita-o, o mais rápido possível! Não há outra solução. Muitos gerentes consideram que programadores ruins ou medíocres, na pior das hipóteses, são apenas mais lentos do que os programadores bons. Mas essa é uma concepção absurdamente errada: um único programador ruim causa prejuízos irreparáveis a um projeto, ou seja, ele não é apenas lento, ele literalmente dá marcha a ré na equipe. O resultado nem sempre é óbvio. A maioria deles é um acumulador de Dívidas Técnicas. Ou seja, a mantenabilidade e extensibilidade são profundamente comprometidas.

Uma coisa é fato: é muito difícil descobrir um programador ruim, principalmente se você, o gerente, não é um programador também. Pior: você precisa ser um bom programador para conseguir descobrir o ruim. Numa equipe razoavelmente balanceada, com programadores pelo menos pouco acima da média e apenas um ou dois elementos ruins, fica mais fácil separar o joio do trigo: a própria equipe vai começar a expurgar a maçã podre de seu meio (se forem espertos). Isso é uma faca de dois gumes, porque agora se você, no papel do programador, acha que seu colega é o ruim, quem garante que os outros não acham que você é quem é o ruim? Se você é um programador, é bom que você garanta o seu. Eu costumo separar “codificadores” de “desenvolvedores”. Ambos são programadores, mas o primeiro grupo é aquele tipo que bate o cartão na entrada, faz apenas o que mandam, vai embora no mesmo horário todo dia e não se preocupa com mais nada. O segundo grupo são os verdadeiros artistas, os que entendem que software é arte e que, como tal, exige dedicação, estudo constante, simplesmente não existe limites de horário comercial. Como eu costumo exemplificar: é a diferença do pintor de paredes para um Da Vinci.

Um gerente precisa ter muita consciência disso: toda equipe de desenvolvimento de software precisa de Líderes Técnicos Sênior. Dica: procure nas comunidades Open Source, você terá melhores chances de encontrar os melhores programadores lá. Não procure em instituições de ensino e, principalmente, desconfie de qualquer programador que mostre primeiro os certificados que tem. Gostei do que o Kris Kemper mencionou no seu blog de como a ThoughtWorks faz para contratar: o candidato passa por uma bateria de testes. Não basta apenas uma ou duas entrevistas: ele precisa passar por vários sêniors da empresa, precisa demonstrar código que será revisado por outros sêniors, ou seja, precisa realmente merecer estar lá. Precisa demonstrar experiência (seguindo Malcolm Gladwell, em Outliers, eu diria que só se deve contratar programadores pertos de atingir as 10 mil horas de experiência, a menos para cargos com tarefas menos importantes), precisa demonstrar desembaraço e excelente capacidade de comunicação, precisa mostrar código, e código bem feito, código que não passaria vergonha na frente de um Martin Fowler.

Agora, eu já vi situações muito ruins, onde uma equipe inteira tem apenas NNPPs. Nesses casos, não há o que fazer: dissolva a equipe inteira. Tome muito cuidado para não cair na tentação do Custo Perdido. Muitos pensam assim: “mas eu já investi tanto tempo e recursos nessa equipe, seria um desperdício jogar tudo isso fora.” Nada disso, ruim é mantê-los criando mais e mais dívida técnica que depois é você quem terá que arcar. Custa mais barato dissolver a equipe, formar uma nova melhor e recomeçar o projeto do zero se for preciso. Você vai parar por 6 meses, mas pelo menos não vai falir daqui 2 anos.

Outra coisa que todo gerente sempre erra: resultado imediato vs. resultado de longo prazo. Isso é uma constante em todas as empresas que já passei: o gerente adora o programador cowboy, aquele sujeito que resolve todos os problemas que ele joga. Todos os cowboys são adeptos do POG, ou a “Programação Orientada a Gambiarra”. Seria engraçado se não fosse trágico: isso não só existe, como é praticamente a norma na maioria das equipes de software. Eu arriscaria dizer que pelo menos 4 em cada 5 programadores faz POG diariamente.

Por isso, se você é Gerente, suspeite de resultados mágicos, comportamentos inesperados do software, erros constantes que são corrigidos instantaneamente. Sabe aquele comportamento? Hoje estourou um problema, você manda um e-mail para a equipe, ela responde na hora seguinte dizendo “agora está tudo ok”. E isso se repete todos os dias. É um sinal fortíssimo de POG. Programadores cowboy são “codificadores” que acham que são “desenvolvedores”, ou seja, um pintor de paredes insano que acha que é Van Gogh. Esse é o tipo mais perigoso porque o pintor de parede sabe das suas limitações e nunca vai dizer que é um pintor de quadros, mas o cowboy não, ele realmente acredita que é o Van Gogh! E o pior, paradoxalmente, os gerentes os adoram porque eles resolvem todos os problemas!

Agora vem a parte chocante: os gerentes adoram os cowboys porque eles resolvem todos os problemas que eles mesmos criaram! Ou seja, ainda não caiu a ficha que o mérito todo atribuído ao cowboy é gerado pelos problemas que ele mesmo criou! Se você é desse tipo de gerente e se agora você entendeu que tem cowboys, demita-os também. Existe até aquele dilema: “mas eu não posso mandar ele embora, só ele sabe como o sistema funciona!” Exatamente, esse é um motivo até ainda mais forte para mandá-lo embora: ele é, literalmente, um grande Single Point of Failure (SPOF). Desenvolvedores de verdade não escondem as coisas, não mascaram resultados, não enrolam o processo. Quer um sintoma? Você tem algum software cujo código-fonte reside apenas na máquina do seu programador? Cuidado: você acabou de encontrar um cowboy.

Outro motivador: quando você troca um programador ruim por outro realmente bom, não está trocando 6 por meia dúzia, está efetivamente trocando 1 por 10, como já dizia o bom e velho Frederick Brooks em The Mythical Man Month. Há 30 anos já sabemos que um bom programador pode ser 10 vezes melhor (não apenas mais rápido, mas um programador que faz código de qualidade, o que torna fácil sua manutenção, sua extensão e inclusive o repasse de conhecimento a outros programadores).

E nos dias de hoje, existem vários sintomas que denunciam cowboys que devem ser demitidos: seu programador torce o nariz quando se menciona Pair Programming ? Ele desdenha Propriedade Coletiva de Código e prefere manter alguns códigos ainda escondidos? Ele acha que teste é algo opcional e que pode fazer depois? Pior, ele defende o uso de práticas ou tecnologias sem saber explicar, tecnicamente, por que está usando? Tudo isso é sintoma. Se seu programador tem pelo menos 1 deles, já é motivo mais do que suficiente para deixar os papéis da demissão preparados e a começar a entrevistar novos candidatos.

Aliás, parece que estou brincando quando falo em “demitir”, mas estou falando sério. Outra coisa que é muito importante para uma empresa é a rotatividade das pessoas. Quando as mesmas pessoas ficam juntas por períodos muito longos de tempo (anos), eles se acostumam uns com os outros e passam a fazer vistas grossas com mais frequência, drasticamente derrubando a qualidade do serviço. Uma meta que deveria ser adotada anualmente é de renovar, uns 10% a 20% do pessoal todo ano! Mantenha os verdadeiros desenvolvedores, mas demita os NNPPs, a menos, claro, que você tenha dinheiro para jogar fora.

Update 30/03: Esqueci de mencionar mais algumas coisas. Respondendo até a algumas coisas nos comentários. Como eu já havia falado na minha apresentação do Matando a Média o mercado como um todo balisa todo mundo por baixo. Por isso um bom programador, mesmo sendo até 10 vezes melhor que um ruim, nunca ganha 10 vezes mais. Às vezes a diferença mal chega a 10%, o que realmente é triste. Claro que quando eu digo “demita”, é sério, mas é uma provocação. Dadas as leis brasileiras que protegem o profissional ruim, isso realmente fica difícil. Portanto, o pragmático seria: demita sempre que puder e, mais importante, contrate com muito esmero. É sempre melhor demorar mais e contratar alguém realmente bom do que assumir que alguém pode ter “potencial” apenas por credencial.

Uma coisa importante: Não estou falando contra os novatos, júniores e recém-formados, não confundam. Existem muitos garotos com muito potencial, especialmente aqueles que sabem que estão em início de carreira e querem aprender, se esforçam para aprender, mudam de rota quando recebem feedback, sabem pelo menos começar a argumentar suas posições. Um cowboy pode ser tanto um recém-formado quanto alguém com 20 anos de carreira, não importa. Os bons júniores devem ser bem cuidados e receber o coaching adequado para que não peguem o caminho dos cowboys.

Outra coisa: “quero ser um bom programador, mas meu chefe me pressiona para entregar tudo antes, inclusive incentiva a fazer POG.” Bom, vamos lá: em aviação existe uma coisa chamada Catch-22. Algumas décadas atrás muitos aviões caíram porque o piloto tomava decisões erradas e o co-piloto, mesmo sabendo disso, precisava ficar calado por causa da hierarquia (alguém de ranking menor não deve contrariar alguém de ranking maior). Em sabendo disso o mundo da aviação evoluiu e agora existe um procedimento chamado PACE (Probing, Alerting, Challenging, and Emergency Warning). Ou seja, se o co-piloto sabe que o piloto está errado, existe um procedimento para ele avaliar a situação, alertar o piloto, se ele não entender desafiá-lo e se ele ainda não entender, o co-piloto deve avisar a torre de comando e tomar o controle da aeronave. Isso diminuiu drasticamente os acidentes aéreos. Um bom programador deve dizer NÃO a um chefe que está empurrando a equipe precipício abaixo. Se a empresa pune esse tipo de iniciativa, então essa empresa não é boa para você. Não estou falando da criancice de bypassar o chefe e fazer fofoca ao chefe do chefe, mas sim de encará-lo homem a homem e discutir o problema realisticamente. Veja um trecho do documento do PACE :

For the actual announcement of change of command on the flight deck, the Co-pilot could use a phrase such as _“Captain (Jones), I must take over control of the airplane. (Jerry), take your hands off the controls.
NOW!”_ This use of a personal first name or a nickname can very effective to break the perceptual narrowing of the Captain. A third crew member, if present, can use terminology such as, _“Captain (Jones),
you must give control of the airplane to (Barry) immediately.”_

Fonte: Akita on Rails

Postado por Chris Sims, traduzido por Ricardo Yasuda em 27 Mar 2009 01:08 PM

A noção do Scrum de ‘backlog’ é uma lista priorizada de user stories para o time implementar. Isso funciona bem para organizar no que o time deve trabalhar no curto prazo, isto é, durante o planejamento do sprint. No Orlando Scrum Gathering, Jeff Patton descreveu o mapeamento de estórias. Este é um jeito de organizar estórias que fornecem conteúdo mais rico e pode ajudar no planejamento de release.

O tópico de mapeamento de estórias não é novo para Jeff. Ele escreveu sobre isso em 2005 e novamente em 2008. Durante o espaço aberto no Orlando Scrum Gathering de 2009, ele compartilhou seu último pensamento sobre a prática.

Apesar de que um mapa de estórias não necessariamente seja um substituto de um product backlog, ele é útil para compará-los e contrastá-los. O product backlog é essencialmente unidimensional. User stories são organizadas da mais alta para a mais baixa prioridade. Um mapa de estórias é bidimensional, indicando a prioridade das estórias, assim como sua relação com as outras e com os objetivos maiores dos usuários. O mapa ajuda o time a entender como estórias se ajustam para formar um produto lançável.

O processo começa com a identificação dos usuários do sistema, e as atividades que eles farão. No artigo do Jeff de 2005, ele deu o exemplo de um software para uma loja. As atividades principais dos usuários eram:

• Criar ordem de compra para fornecedor
• Receber carregamento do fornecedor
• Criar etiquetas para os itens
• Vender itens
• Retornar itens
• Analisar vendas

Mike Cohn refere-se a essas atividades como ‘épicos’. Jeff os referencia como ‘a espinha dorsal’ do mapa de estórias. Eles descrevem, num alto nível, tudo o que o usuário precisa que o sistema faça. Essas atividades são registradas em cartões e arranjadas da esquerda para a direita na ordem que elas naturalmente ocorrem. Jeff recomenda usar a ordem que você usaria se fosse descrever o processo do negócio para alguém não familiar com ele.

Abaixo de cada atividade dessas, organize as user stories associadas, colocando as mais importantes acima das menos importantes. Agora a espinha dorsal tem costelas. Cada estória está associada com uma atividade de usuário, e tem uma prioridade. Um plano de release pode ser visualmente representado desenhando uma linha horizontal da esquerda para a direita. Estórias acima da linha estão no release, e as abaixo não estão. Na verdade, vários releases podem ser planejados deste jeito, dividindo o mapa em ‘raias’ horizontais.

Que ferramentas ou técnicas você usa para planejar releases e ficar a par dos contextos em que as suas estórias existem? Deixe um comentário e compartilhe.

Fonte: InfoQ

Para conseguir a liberação do budget necessário à iniciativa, executivos devem mapear os recursos profissionais que possuem, identificar os desafios da área para os próximos anos e classificar os riscos que a companhia pode correr se o programa não for aceito

Patrícia Lisboa, repórter da CIO
Publicada em 27 de março de 2009 às 09h36

A falta de profissionais capacitados em TI, as mudanças relativas à dinâmica mais competitiva devido à crise econômica e a necessidade de reter talentos – para a sucessão executiva ou mesmo para a implementação de projetos estratégicos – têm levado grandes empresas a investir no desenvolvimento interno de seus colaboradores.

Alvo de políticas globais de Recursos Humanos, essas iniciativas cresceram bastante com as instabilidades financeiras mundiais. “As companhias mais competitivas estão apostando alto na capacitação de seus funcionários para o período de retomada da economia”, conta Fernando Feitoza, superintendente comercial da Across , consultoria especializada em desenvolvimento organizacional com foco em gestão de pessoas.

De acordo com o especialista, normalmente, essas políticas são instituídas pela área de RH e têm como foco todos os segmentos de negócio. No entanto, quando se trata da retenção de talentos e treinamento de equipes, a área de TI deve receber atenção especial.

Dados da IDC mostram que, de 2006 até 2009, serão gerados na América Latina pelo menos 630 mil empregos em tecnologia, metade delas no Brasil (47%). Segundo a consultoria, apenas para desenvolvimento de software, o País existem 15 mil vagas abertas.

Um dos reflexos diretos dessa demanda é a alta rotatividade de colaboradores altamente capacitados na área de tecnologia. Um problema que afeta os CIOs, os quais precisam liderar as iniciativas formais de treinamento e desenvolvimento de suas equipes.

Para conseguir a liberação do budget para ações relacionadas à capacitação, Feitoza aponta que os líderes de TI precisam estar preocupados com três questões específicas:

• Mapeie os recursos: para identificar o perfil de cada membro da equipe e os talentos mais promissores. Assim, poderá ter a visão completa do tipo de profissional que mais necessita e quais colaboradores merecem mais atenção;

• Identifique os desafios da área para os próximos anos: e tente adaptá-los à equipe que possui hoje. Dessa forma, conseguirá enxergar as habilidades que devem ser mais desenvolvidas nos funcionários, individualmente;

• Classifique os riscos: que a companhia corre se a iniciativa proposta não for implementada. Mostre, no papel, como o treinamento dos profissionais que formam a equipe de TI trará benefícios ao negócio.

Fonte: CIO

Postado por Chris Sims, traduzido por Felipe Rodrigues em 25 Mar 2009 12:11 PM

Um gráfico burn-down registra o tamanho do backlog do Sprint ao longo do Sprint. Durante a retrospectiva do sprint, o gráfico burn-down pode fornecer dados valiosos sobre como foi o sprint. Mike Sutton usa anotações para capturar mais dados no gráfico burn-down, tornando-o ainda mais útil durante a retrospectiva.

Durante um sprint, o gráfico burn-down mantém o time e qualquer um que olhar para ele, informado sobre o tamanho do backlog do sprint atual e qual a velocidade do time. Idealmente, o gráfico deve cair de forma que atingirá o ‘zero de trabalho restante’ antes ou exatamente no final do sprint.

Uma linha de tempo na retrospectiva é uma ferramenta que ajuda ao time reconstruir o principais acontecimentos do sprint. Uma abordagem comum é marcar uma linha de tempo na parede ou quadro branco e pedir que os membros do time coloquem notas na linha de tempo para os eventos que ocorreram. As notas podem dizer coisas como: "Mike juntou-se ao time.", "O build foi quebrado", "O build foi finalmente corrigido", "A grande demonstração para um cliente foi bem!", "Um grande bug foi reportado." e assim por diante.

Mike Sutton descreveu como ele está capturando informações de linha de tempo, conforme as coisas acontecem, no gráfico burn-down do time. Quando um membro do time relata um impedimento na stand-up meeting diária, o impedimento é registrado em um post-it. O post-it é então posicionado no gráfico burn-down, próximo ao ponto que representa aquele dia na linha. O post-it inclui uma curta descrição do impedimento e qualquer contexto relevante. Quando o impedimento é resolvido, a data de resolução é adicionada ao post-it. O post-it permanece no gráfico. Quando o time faz sua retrospectiva do sprint, eles podem facilmente referenciar o gráfico burn-down anotado para ajuda-lo a lembrar dos principais acontecimentos do sprint.

Que tipos de dados seu time coleta e usa durante as retrospectivas? Que ferramentas você usa para coletar os dados? Deixe um comentários e compartilhe.

Fonte: InfoQ

Escrito por Luciano Félix em 7 Outubro, 2008

O Sprint Backlog consiste simplesmente na lista de tarefas que serão desenvolvidas pela equipe para que ao fim de cada sprint possamos entregar incrementos de software funcionais. A criação do Sprint Backlog acontece na segunda parte do Sprint Planning com o envolvimento de toda a equipe. Dar atenção a esse processo é fundamental para que equipe tenha um entendimento melhor do que deve ser feito e planejar melhor o dia-a-dia da sprint, porém muitas equipes ainda pecam na hora de criar sua lista de tarefas, espero que estas dicas possam ajudar.

1. Envolva toda a equipe no processo – Nunca é demais repetir, o envolvimento de toda a equipe no processo de descoberta do Sprint Backlog é importantíssimo. Numa equipe multidisciplinar todos poderão contribuir com atividades sob as diversas perspectivas que cada um tem sobre item a ser desenvolvido, gerando um Sprint Backlog muito mais rico do que se apenas os programadores participassem, ou apenas o guru técnico, etc.

2. Discuta como o item será implementado – A lista de tarefas é apenas um dos outputs da segunda parte do Sprint Planning, antes de escrever as tarefas em post-its é necessário que a equipe discuta de verdade como cada item será definido. A maior parte da reunião dever ser dedicada ao entendimento de como a equipe irá atacar o problema, definir um design básico da solução, verificar o código existente, discutir possibilidades de arquitetura, etc. Esse entendimento geral do problema e da possível solução farão com que as tarefas identificadas expressem realmente o trabalho que será feito.

3. Tenha uma Definição de Pronto – Ter a “Definição de Pronto” disponível e visível a todos é muito, muito importante, essa definição servirá como um guia para o que deve ser feito, lembrando a todo mundo quais são os critérios de aceitação gerais para todos os itens do Product Backlog.

4. Identifique todo o tipo de tarefa – Muitas equipes se concentram muito em tarefas de codificação, mas só codificar não é suficiente para entregar software funcionando de verdade. Todos os tipos de tarefas devem ser contemplados no Sprint Backlog, atividades de modelagem, codificação, aprendizado, tarefas de banco de dados, todos os tipos de teste possíveis, etc. A “Definição de Pronto” ajudará a equipe a pensar nos vários aspectos do trabalho. Trabalhando desse forma a equipe entenderá muito melhor qual a real carga da sprint.

5. Reveja o compromisso para a sprint - Após a identificação das tarefas, a equipe terá um entendimento melhor sobre o real esforço necessário, nesse momento o compromisso para a sprint deve ser reanalisado. OSelected Product Backlog realmente cabe na Sprint ? caso não, existem algumas alternativas. O item de menor prioridade pode ser removido ou quebrado em itens menores, estudar as técnicas de divisão deUser Stories são muito úteis nesse caso. O importante é que agora a equipe possa se comprometer de fato com o escopo da sprint.

6. Não use tempo demais - Respeite o time-box. Estipule o tempo da reunião e não ultrapasse, faça a equipe se concentrar e trabalhar intensamente na discussão dos itens , assim as tarefas serão descobertas mais facilmente. Nem sempre a equipe conseguirá identificar tudo o que será realizado durante a sprint, mas isso não é um problema, o entendimento geral é mais importante.

7. Evolua o sprint backlog durante a sprint – No dia-a-dia da sprint a equipe terá um entendimento ainda melhor sobre cada item sendo desenvolvido, novas idéias podem aparecer, idéias antigas podem ser descartadas, o Sprint Backlog deve acompanhar essa mudanças. O Daily Scrum é um momento excelente para criar novas tarefas e descartar tarefas que se mostraram desnecessárias.

Fonte: Código Ágil

São Paulo – Estudo global realizado pela IDC revela que mais da metade dos entrevistados planejam acelerar a adoção do Linux este ano.

Por Redação do COMPUTERWORLD
24 de março de 2009 – 07h11

A IDC concluiu na última semana um estudo global, realizado com o patrocínio da Novell, que revelou um aumento nas aquisições de Linux ocorridas em virtude da recessão econômica global. Quanto mais as empresas procuram cortar custos e agregar valor, mais são atraídas pela economia que o Linux pode oferecer.

Mais da metade dos executivos de TI pesquisados planejam acelerar a adoção do sistema operacional em 2009. Além disso, mais de 72% deles disseram que estão avaliando seriamente ou já decidiram aumentar a adoção do Linux no servidor em 2009, com mais de 68% reivindicando o mesmo para o desktop. O estudo foi feito com cerca de 300 executivos de TI de setores como manufatura, serviços financeiros, varejo e agências governamentais de todo o mundo.

A pesquisa revelou os principais fatores do crescente interesse em Linux. A principal razão que motivou os executivos a migrarem para Linux foi econômica e relacionada à redução contínua de custos de suporte. Como resultado, mais de 40% dos participantes da pesquisa disseram que planejam implantar fluxos de trabalho adicionais em Linux nos próximos 12 ou 24 meses e 49% indicaram que o Linux será sua principal plataforma nos próximos cinco anos. Notavelmente, entretanto, aqueles que continuam hesitantes em adotar Linux citaram falta de suporte de aplicação e fraca interoperabilidade com Windows e outros ambientes como sua principal preocupação.

Outras constatações da pesquisa:

- 67% dos pesquisados afirmaram que interoperabilidade e gerenciamento entre Linux e Windows são dois dos fatores mais importantes na escolha do sistema operacional.

- o setor de varejo mostrou o maior potencial de aceleração na adoção de Linux já que 63% dos pesquisados planejam um aumento no desktop e 69% consideram o mesmo no servidor. A área governamental ficou para trás.

- quase 50% dos pesquisados planejam acelerar a adoção de Linux no desktop, especialmente para funções de escritório básicas, usuários técnicos de estações de trabalho e educação superior/K-12.

- aproximadamente metade dos entrevistados afirmou que sua migração para a virtualização está acelerando suas adoções de Linux. 88% deles planejam avaliar, implantar ou aumentar a utilização do uso de software de virtualização no sistema operacional Linux nos próximos 12 ou 24 meses.

- do ponto de vista regional, Ásia e Pacífico são as que mais adotam Linux: 73% dos entrevistados disseram que gostariam de aumentar a implantação de Linux no servidor e 70% nos desktops. Nas Américas, 66% dos entrevistados afirmaram que estão avaliando ou já decidiram ampliar a adoção de Linux no desktop e 67% no servidor.

- a crise econômica teve seu maior impacto nas Américas, nos serviços financeiros e governo. Mais de 62% dos entrevistados disseram que seus orçamentos sofreram cortes ou que estão apenas investindo no que é necessário.

“A crise tende a acelerar o uso de tecnologias emergentes, aumentar a adoção de soluções eficientes e punir soluções que não apresentam custo competitivo”, afirmou Al Gillen, vice-presidente de software e sistema do IDC. “Esta pesquisa confirma que usuários de Linux o enxergam favoravelmente, e essa percepção coloca o Linux em uma posição competitiva para emergir dessa recessão como uma solução mais fortalecida”.

A pesquisa foi realizada em fevereiro de 2009. Foram entrevistados mais de 300 profissionais de TI que supervisionam as compras de Linux e outros sistemas operacionais para saber suas opiniões. Para participar, as organizações deveriam ter mais de 100 funcionários. Dentre os participantes, 55% tinham Linux como sistema de servidor em uso, 39% Unix e 97% Windows. Os pesquisados tinham os cargos de CIOs, vice-presidentes, diretores, gerentes, funcionários e consultores de TI. Os entrevistados foram pré-avaliados por analistas locais e responderam a pesquisa pela internet.

Um white paper da IDC com o resumo dos resultados da pesquisa pode ser acessado em www.novell.com/idc

Fonte: Computerworld

Por Eduardo Miranda, Software Development Engineer da Microsoft
Abril 05, 2007

Outro dia na hora do almoço tivemos uma discussão animada sobre documentação de código. Que tipo de documentação é necessária para que um novo desenvolvedor tenha capacidade e segurança para fazer modificações em seu código-fonte?

Um dos meus colegas colocou a sua posição: Em uma situação ideal todo o código-fonte e design de um sistema deveriam ser tão claros e simples de entender que não existiria a necessidade de documentação nenhuma (Lembre-se que estamos falando somente de documentação de código-fonte e/ou design).

Lógico que houve reações contrárias. É muito difícil pegar um monte de código-fonte e sair “entendendo” ele. Alguma documentação facilita bastante este processo.

Pode ser, mas do ponto de vista de uma situação ideal, um código-fonte bem escrito, seguindo práticas básicas como separação de responsabilidade, alta coesão e ortogonalidade deveria ser bem fácil de entender. Posso parecer maluco, mas prefiro ler um trecho de código-fonte bem escrito do que ler a descrição em português do que aquele código faz (outros concordaram comigo no almoço, então não sou o único maluco :0).

Como não estamos ainda no mundo ideal, acho que o desenvolvedor deve se preocupar em manter o próximo coitado bem informado para um bom começo. Sempre utilizando as tags de documentação no próprio código-fonte. Segue a minha lista:

Classes

• Uma descrição breve da classe na tag summary é o suficiente.
• Os namespaces e padrões de nomenclatura devem estar bem definidos, isto ajuda bastante, por exemplo, se todas as entidades do sistema estiverem em MySystem.Entities, fica fácil de imaginar o que é a classe MySystem.Entities.Invoice

Métodos

• No mínimo, preencher as tags summary , param (para cada parâmetro) e returns (se o método tiver retorno) – Estas tags são importantes pois apareceção no intellisense quando você utilizar o método
• Se o método levanta erros preencher a tag exception.
• Se existirem testes unitários é desnecessário dar exemplos na tag example, pois testes unitários são os melhores exemplos de como utilizar uma classe e seus métodos.
• Se o código-fonte não estiver disponível para o usuário é interessante dar mais detalhes do método na tag remarks
• Ao longo do código só coloque comentários se o trecho for complicado

Para mim isto é mais do suficiente para documentar o código. O importante é fazer tudo isto no próprio código, utilizando as tags. Desta forma você só terá um artefato para atualizar e pode usar o moribundo NDoc ou o recém nascido SandCastle para gerar um help já formatado direto do código-fonte.

Decisões de design também podem ser documentadas em um documento simples de design, quais as decisões polêmicas que foram tomadas, design patterns utilizados. Tudo simples e rápido. Não deixe este documento ficar grande.

E você, tem alguma opinião a respeito? Deixe seu comentário.

Fonte: Console.Write(this.Opinion)

Para consultor, nem sempre a posição de gestor representa a melhor opção para os executivos que, em muitos casos, têm saído da diretoria de TI para cargos menos estratégicos e mais técnicos

Patrícia Lisboa, repórter da CIO Brasil
Publicada em 19 de março de 2009 às 08h00

Trabalhar como analista de sistemas, coordenador de área, gerente de núcleo e, então, enfim, seguir para a liderança da TI, reportando-se diretamente ao alto comando da companhia e participando da tomada de decisões estratégicas. Essa parece ser a trajetória ideal para um profissional de tecnologia, certo? Nem sempre.

De acordo com Fernando Feitoza, superintendente comercial da Across – consultoria especializada em desenvolvimento organizacional com foco em gestão de pessoas – muitas vezes os profissionais que iniciam suas carreiras em áreas técnicas são seduzidos pelos benefícios e pelo status trazidos por um cargo de gestão.

“Em postos de CIO, por exemplo, há casos de executivos que, ao analisar mais profundamente seus desejos e aspirações profissionais, percebem que gostariam de ter permanecido na área técnica”, conta Feitoza.

O consultor explica que isso acontece devido a pressões do próprio mercado e até pela falta de autoconhecimento dos profissionais. “Quando estão envolvidos em projetos interessantes e têm a chance de prosperar na área em que atuam é muito difícil que consigam avaliar que esse próximo passo não vai ao encontro de suas vontades mais legítimas”, complementa ele.

Segundo Feitoza, a sensação de insatisfação dos executivos quanto aos rumos de suas carreiras só é percebida quando esses profissionais atingem certa maturidade e passam a analisar as escolhas feitas ao longo da vida. “No entanto, mesmo que não seja fácil, é possível voltar atrás e conseguir uma posição técnica tão bem remunerada e reconhecida como o cargo de gestor”, garante o consultor.

Ele ressalta que, para tanto, o executivo precisa passar por um processo de recolocação profissional e estar disposto a aceitar propostas iniciais com salário inferior ao pago para um CIO.

“Além disso, e até mais importante, o profissional precisa estar atualizado quanto às tendências do segmento”, afirma Feitoza, que analisa: “Depois que se mostrar um especialista, certamente conseguirá atingir o mesmo patamar financeiro que ocupava como executivo.”

Para concluir, o consultor defende que quanto antes o profissional conhecer suas reais aspirações, mais rapidamente atingirá seus objetivos. Para chegar a essa decisão, ele dá as seguintes dicas:

• Preste atenção aos feedbacks: tanto para a vida profissional quanto pessoal, ouvir opinião dos outros é muito importante e pode revelar faces da nossa própria personalidade que não enxergamos ou tentamos, inconscientemente, esconder;

• Lembre-se de seus sonhos de juventude: faça esse exercício e tente adequar seus antigos anseios às suas atuais necessidades e angústias;

• Compare seus objetivos individuais com os da empresa na qual está inserido: e descubra se ambos estão trabalhando na mesma direção. Assim é possível mensurar se o problema profissional é com a companhia em si ou, realmente, com a função desempenhada;

• Busque o autoconhecimento: por meio de coaching, terapia, ou qualquer outro meio, esse é a única forma de conhecer seus reais objetivos.

Fonte: CIO

Postado por Vikas Hazrati, traduzido por Flávia Castro de Oliveira em 19 Mar 2009 02:14 PM

Muitas organizações que tem embarcado na adoção do caminho Ágil, tem que enfrentar o desafio do mapeamento dos papéis do desenvolvimento de software para os três papéis que o Scrum fornece. Os Papéis tradicionais como o Gerente de Produto, Gerente de Projeto, Analista de Negócios, Designer, DBA etc. não mapeiam os papéis definidos pelo Scrum. Em uma série de visões, Mike Cottmeyer tenta efetivamente mapear os papéis para o Scrum.

Mike sugeriu que os papéis relacionados ao ‘Scrum Master’ e ao ‘Scrum Team’ são relativamente fáceis de preencher.

O Gerente de Projeto poderá se encaixar no papel de um Scrum Master, entretanto, isso envolve uma mudança de mentalidade. De acordo com ele

Os Scrum Masters são facilitadores de processos e dão suporte para o time. Os Gerentes de Projeto são normalmente responsáveis por gerenciar o time e garantir que o tempo, custo e o escopo sejam equilibrados. [...]

Os Scrum Masters não tem autoridade sobre o time. Os Scrum Masters atuam mais como serventes do time… O Gerente de Projeto é mais como um chefe.

Do mesmo modo o ‘Scrum Team’ deve envolver todos que estão envolvidos no levantamento pesado de construção do produto.

O time de desenvolvimento, os caras da base de dados e o QA podem provavelmente ser trabalhados muito bem no papel de Membro do Time. Estas pessoas tem responsabilidade direta pelo design, construção e teste do código.

Uma vez que os papéis acima são mapeados há ainda muitos papéis como Analista de Negócios, Analistas de Sistemas, especialistas em Experiência de Usuários, etc, que precisam ser mapeados para os papéis do Scrum. De acordo com Mike, todos esses papéis poderiam potencialmente deslizar para o papel de um Product Owner.

O Product Owner é o Gerente de Projeto, o Analista de Negócios, o Designer do Sistema, o Arquiteto com Experiência de Usuário e cada grupo de Negócios… todos transformados em um. O papel é deve realmente ser onipotente e onipresente.

No entanto, Mike reconhece que este é um grande papel em si. Então, ele sugeriu que em vez de uma pessoa só preencher todos esses papéis, poderia ser um Time do Product Owner onde muitas pessoas coordenassem juntas. O time poderia incluir

• Gerente de Produto – Trabalha com os stakeholders, identifica requerimentos e ajusta as prioridades.
• Gerente de Projeto – Mantém uma visão geral de todos os objetivos. Gerencia recursos, investimentos, dependências externas etc.
• Analista de Negócio – Responsável por documentar os critérios de aceitação e documentar as conversações em torno da estória de usuário. Principal ponto de contato para o esclarecimento dos requerimentos durante o sprint.
• Designer - Prepara alguns screenshots, wireframes, etc.

Ele representa a configuração como esta figura abaixo

Assim, em vez de trabalhar isoladamente, o Product Owner interage com vários outros papéis e ajuda a trazer seus conhecimentos coletivos e expertise para definir o contexto correto e fornecer coordenação.

Assim, agrupando papéis eficientemente, os papeis tradicionais podem caber nos três papéis sugeridos pelo Scrum. A chave é mapeá-los no lugar correto onde eles adicionariam valor para o time inteiro.

Fonte: InfoQ