Postado por Mark Levison, traduzido por Fernanda Stringassi de Oliveira em 22 Jul 2009 12:29 PM

Uma pergunta freqüentemente questionada é como Scrum recomenda que a equipe trate os bugs? Eles devem ser colocados no product backlog? Ou em uma lista de bugs separada? Se eles estão no backlog, o Product Owner deve definir as prioridades ou eles são automaticamente os itens mais importantes? Deve existir um sprint em separado para a correção de bugs?

Na equipe do Pascal Maugeri’s, mesmo depois de melhorar a definição de pronto e fazerem “ testes/testes unitários de forma apropriada ", eles ainda encontram bug que escapam do sprint. Ele questiona como resolver este problema.

George Dinwiddie , Agile Coach, sugere levantar a questão com a equipe durante a retrospectiva  – ele tem trabalhado com equipes que têm taxas de bug bem baixas. Mark Levison (o próprio autor deste artigo) sugeriu “Eu começaria a perguntar: Por que os bugs não foram encontrados e corrigidos no sprint onde eles ocorreram? Meu foco é reduzir o tempo necessário para descobrir (e então corrigir) problemas. Depois de tudo, se nós descobrirmos bugs na história durante o sprint em que ele foi especificado, então o PO não deveria aceitar a história como pronta. Além disso, descobertas precoces farão com que seja muito mais fácil corrigir já que o código ainda está fresco na mente da equipe de desenvolvimento. ”

Jim Schiel, CST com Artisan Consulting, coloca os bugs no product backlog para serem priorizados pelo Product Owner – “ao menos que seja um bug muito simples, você define a solução durante a reunião de planejamento do sprint e executa a solução durante o Sprint.”

Bruce Kantelis  diz que tudo isso está relacionado com o desenvolvimento da cultura de trabalho:  Nós categorizamos os bugs. Prioridade 1, que bloqueiam o usuário de trabalhar têm atenção imediata, e o trabalho é interrompido para uma correção ou reparo, já todos os outros se tornam histórias que são colocadas no topo da lista para o próximo sprint. Ao longo do tempo, as equipes percebem que atitudes e medidas de qualidade realmente impactam o trabalho do dia-a-dia e as interrupções são minimizadas. ”

Mike Cohn nos lembra que bugs encontrados dentro do sprint são melhor tratados gritando-os para toda a equipe na sala e descrevendo o bug. Se isto não der certo, um cartão descrevendo o bug pode ser incluído no quadro de tarefas. Embora existam bugs que escapam do sprint  – ele prefere adicioná-los no product backlog, deixando que o product owner os priorize. Muitas equipes ainda têm uma base de dados de bugs que precisam continuar usando. Neste caso, ele aconselha manter um backlog de bugs em separado, onde o product owner simplesmente diz quais são as prioridades dele para cada fila: por exemplo, os primeiros dois itens do product backlog, e então os seguintes bugs e finalmente os próximos dois itens do backlog.

Kevlin Henney argumenta que esta abordagem é semelhante ao tratamento do bug o como uma funcionalidade com valor negativo:

Se bugs são vistos como funcionalidades com valor negativo, eles acabam sendo gerenciados como se fossem funcionalidades. Grupos de desenvolvimento armazenam repositórios de bugs priorizados, tratam bugs como histórias, terceirizam a correção dos bugs, e assim por diante. Embora possam ser técnicas úteis ou perspectivas em lidar com projetos em fase de transição ou crise, não é uma visão a longo prazo que deva ser encorajada. Além disso, tudo como o "Manifesto para Desenvolvimento Ágil de Software" diz, "Software funcionando é a primeira medida do progresso". É um pouco desonesto passar adiante como completa e funcionando uma funcionalidade com bugs conhecidos — "Sim, está pronto… mas tem alguns pequenos bugs."

Ron Jeffries transforma todo o problema dizendo que corrigir um bug em uma funcionalidade depois dela estar terminada é sempre mais caro do que fazer certo na primeira vez.

Então quando nós desenvolvemos o software incorretamente e então o corrigimos, o cliente paga mais: ele paga o que ele pagaria antes, mais a pena de ter corrigido um bug.

O cliente deve ser realmente alertado sobre isso. Eu gosto de encorajar o cliente a priorizar todos os bugs, para garantir que ele sentirá o sofrimento de um processo de software inadequado. Eu estou certo de que ele expressará todo este sofrimento e que a equipe terá melhor chance de ter alguma idéia de que fazer bem feito é o melhor.

Você evita bugs em geral? Coloca eles no Product Backlog? Você vê os problemas que Kevlin falou?

Fonte: InfoQ

Esses vídeos já devem ter algum tempo rodando pela web, mas só hoje almoçando com um amigo, soube da existência.

Mais dois excelentes trabalhos do grupo CollegeHumor.

O primeiro vídeo é sobre uma conferência de fonts, onde cada fonte foi personificada como um personagem. Detalhe para a Comic Sans e a Futura.

Font Conference

O segundo vídeo é sobre a briga entre duas gangs de font. A gang da Helvética e a gang da Arial.

Font Fight

Mesmo com políticas estruturadas de segurança, especialista afirma que 95% das companhias que já adotaram a NFe encontram-se ameaçadas por falhas no sistema de certificação digital

Rodrigo Afonso, da COMPUTERWORLD
Publicada em 21 de julho de 2009 às 14h21

A nota fiscal eletrônica (NFe) é hoje uma realidade nas empresas que antes baseavam a documentação de suas transações financeiras em papel. Para a emissão desses documentos virtuais, as organizações precisam adquirir certificados digitais voltados a validar juridicamente a assinatura dos documentos.

Muitas companhias, no entanto, podem se deparar com problemas relacionados à proteção de suas informações fiscais, já que o tipo de certificado mais adotado, o A1, traz vulnerabilidades e, se esses dados chegarem às mãos de pessoas mal-intencionadas, podem ser utilizados para emissão de notas falsas em nome das companhias.

Segundo o especialista em segurança de informação da consultoria Epsec, Denny Roger, já existem vários casos de empresas que sofreram algum tipo de fraude desse tipo. E investigações que correm em segredo de justiça mostram que os problemas foram causados por certificados digitais utilizados indevidamente.

Roger faz uma analogia entre o início do Internet Banking no Brasil, quando as empresas tinham somente uma senha simples de acesso à conta com a situação do certificado A1. “Depois que as fraudes nas contas correntes explodiram, as instituições foram atrás de soluções. O mesmo deve acontecer com os certificados digitais para emissão das notas eletrônicas”, diz.

De acordo com o especialista, há grupos que defendem a substituição dos certificados A1 por certificados A3, instalados em um hardware ou smartcard; em tese, invioláveis. O presidente da NFe do Brasil, Marco Zanini, afirma que não há a necessidade de eliminar o certificado do tipo A1, pois ele pode ser mantido em segurança.

Bastaria, para isso, implantar, nas operações da empresa, módulos de segurança conhecidos por HSM (Hardware Security Module). Eles podem ser instalados diretamente na estrutura de servidores para assinar digitalmente e com segurança todas as notas.

Apesar disso, Zanini concorda que a maioria das corporações estão expostas a riscos. “Eu diria que, se hoje houver 10 mil empresas emitindo nota fiscal eletrônica, no Brasil, somente 500 estão seguras e utilizam a proteção adequada”, afirma.

O executivo acrescenta que seria inviável manter um certificado A3 para altos volumes de transação, já que esta versão exige senha de acesso cada vez que é utilizada. Já o gerente de certificação digital da Serasa Experian, Igor Ramos, acredita que o risco com o certificado digital A1 está muito mais relacionado à corrupção do arquivo do que à existência de fraudes. “Hoje as companhias já contam com formas eficazes de proteção”, diz.

Por outro lado, destaca, se o arquivo sofrer algum dano, causado ou não por terceiros, e não houver plano de contingência, a companhia pode ficar algum tempo sem emitir notas e deixará de fazer negócios.

Fonte: CIO

Por José Papo
para o José Papo Weblog

Na revista IEEE Software de julho/agosto de 2009, Tom DeMarco escreveu um artigo excelente de título Software Engineering: An Idea Whose Time Has Come and Gone? . Tom DeMarco ainda é um metodologista e consultor importante, mas era ainda mais famoso antigamente por ter sido um dos pais da metodologia estruturada.

No artigo ele diz que hoje discorda do que escreveu em um de seus livros muito usados na época de título “Controlling Software Projects: Management,Measurement, and Estimation”. Não posso deixar de recomendar a leitura do pequeno texto, mas vão aí algumas frases excelentes (traduzi para o português) :

” ‘Você não pode controlar o que não pode medir’. Implícita nessa minha frase está a idéia de que controle seja talvez o mais importante aspecto de um projeto de software. Mas não é. Muitos projetos foram realizados quase sem controle e produziram produtos maravilhosos, como o Google Earth ou o Wikipedia.”

“Controle estrito é algo que importa muito para projetos inúteis e importa pouco para projetos úteis. Isso significa que quanto mais você foca em controle, maior a probabilidade de seu projeto estar entregando algo de valor baixo.”

“Então, como você gerencia um projeto que não pode controlar? Bem, você gerencia as pessoas e controla o tempo e o dinheiro. Estou sugerindo um approach de gestão muito próximo de métodos ágeis. No mínimo deve ter um aspecto incremental.”

“Nos últimos 40 anos nós nos torturamos com a nossa inabilidade de terminar um projeto no prazo e no orçamento. Mas essa nunca deveria ter sido a meta suprema. A meta mais importante é a transformação, criar softwares que mudam o mundo ou transformam a maneira como uma companhia realiza seu negócio. Desenvolvimento de software é e sempre será de alguma maneira experimental. ”

Fonte: José Papo Weblog

Segundo o site “Gray’s Matter” o Microsoft Office 2010 para Web foi completamente escrito utilizando Javascript e não Silverlight:

It’s always nice to be reminded that Justice Gray doesn’t just influence individual developers, but in fact also determines the direction of major corporations. That’s the other big message – aside from the one in the post title – that Microsoft has given the industry, by showing everyone that Office 2010 has been written entirely in Javascript! That is right, Silverlight now joins the ranks of other hallowed languages/applications like J# and Visual Sourcesafe in the realm of “things that Microsoft produces but has no intention of ever actually using themselves”.

Aos 3 minutos do vídeo “Is Office 2010 the largest JavaScript app in the world?“, o PMO do projeto Office 2010 para Web é claro ao mencionar que os recursos apresentados foram desenvolvidos em Javascript:

Muitas vezes um arquiteto é confundido com um desenvolvedor sênior ou projetista especialista. Um arquiteto, entretanto, não é um projetista especialista de uma tecnologia. O arquiteto de software é apenas outro papel, com outras atribuições e outras funçoes, conforme podemos observar dentro das escolas de renome de arquitetura de software no mundo, como por exemplo o SEI SAT .

Um arquiteto é um papel generalista. Um projetista é um especialista para um determinado domínio (ex: Java EE ou .NET). A figura abaixo, adaptada do trabalho de Gerrit Muller, explora esta dicotomia.

Fonte: Arkhi

Este eBook é sobre como reduzir o “Lead Time” no desenvolvimento de software. “Lead Time” é o tempo entre a concepção da idéia e o momento em que o software começa a dar retorno.

É orientado para gerentes de projeto, gerentes de desenvolvimento, gerentes de tecnologia etc. Gerentes de produção e desenvolvedores também poderão aprender uma ou duas coisinhas também com a leitura.

“Lead Times” longos custam dinheiro e tornam nossos clientes externos e internos infelizes. Esse eBook nos sugere 12 ações que podem reduzir esse tempo substancialmente.

O eBook pode ser baixado pelo link: http://www.codemonkeyism.com/wp-content/uploads/2009/07/ebook_reduce_lead_times_early_access.pdf

Dica do Kent Beck pelo twitter:

RT potent short idea generator for reducing lead time in software development by @CodeMonkeyism http://tinyurl.com/mtxjfk

Fonte: Code Monkeyism

Publicado por Guilherme Chapiewski
em 12/07/2009 em seu Blog

Esses dias vi uma mensagem no Twitter que me fez lembrar de algo que eu já queria ter falado aqui há algum tempo:

Referring to people as “resources” leads to thinking that individuals are interchangeable code producing units.

Toda vez que alguém chama uma pessoa de “recurso” dói meu ouvido. Chega até a ser chato, mas quando alguém faz um comentário sobre “recursos” do meu lado dificilmente consigo resistir a corrigir para “pessoas”. Como a Esther Derby disse na sua mensagem, tratar pessoas como “recursos” dá a impressão que as pessoas são “commodities“, que são meros “parafusos”, sem importância individual e substituíveis por qualquer outro.

Como que alguém pode se sentir bem sabendo que é totalmente descartável e que pode ser a qualquer momento trocado por qualquer outra pessoa? Como alguém pode estar comprometido com um projeto sabendo que é totalmente substituível e que não faz diferença se quem estiver ali for ela ou qualquer outra pessoa? Como alguém pode se sentir motivado assim?

E por fim a pergunta que eu queria chegar: Que tipo de código e que tipo de produto as pessoas vão conseguir produzir nessas condições?

Desenvolvedores de software são trabalhadores do conhecimento. Ao contrário de trabalhadores “Fordistas”, que são extremamente especializados numa linha de produção e desempenham atividades repetitivas e “robóticas”, os trabalhadores do conhecimento trabalham intensivamente com o seu cérebro, analisando e interpretando informações, descobrindo novas e melhores soluções para resolver problemas e tomando decisões o tempo todo.

Por esse motivo, é essencial que essas pessoas estejam motivadas, pois isso as deixa num estado mental que estimula sua produtividade, aumentando a quantidade de trabalho que podem realizar e potencializando o uso da sua criatividade para resolver problemas.

Um projeto de software bem sucedido é construido por pessoas motivadas, que tem visão do que estão fazendo e que acreditam nessa visão.

Para saber mais:

• Porque empresas tratam as “Pessoas” como “Recursos”?
• Managing Knowledge Workers

Fonte: Blog Guilherme Chapiewski

Postado por Abel Avram, traduzido por Rony Barbosa em 13 Jul 2009 12:21 PM

Eric Nelson, um Desenvolvedor Evangelista da Microsoft e editor técnico da MSDN UK Flash, reuniu uma lista de 23 projetos abertos .NET, a maioria baseado em recomendações enviadas dos desenvolvedores Ingleses. Outros grandes projetos não foram inseridos na lista, enquanto contribuições da Microsoft incluem: ASP.NET MVC, DLR, IronRuby, IronPython, MEF.

Eric tentou incorporar apenas um framework de testes, um framework de mocking, etc. Embora existam mais de um. Sua lista contém os seguintes projetos:

1. [TEST] xUnit.net – Um dos vários frameworks de teste ótimo para auxilio de TDD.
2. [TEST] RhinoMocks mocking framework -Testes fáceis pelo fato de permitir o desenvolvedor criar implementações mock de objetos.
3. [TEST] White for automation of Windows applications – Condução programática de aplicações Windows.
4. [TEST] Gallio Automation Platform – Trabalha com muitos frameworks de teste, incluindo MSTeste, xUnit, Nunit e MbUnit.
5. [DATA] Fluent Nhibernate – Fluent Nhibernate leva você a escrever mapeamentos em código c# fortemente tipados.
6. [OOP] StructureMap Dependency Injection/Inversion of Control – Habilita uma redução de acoplamento entre classes e suas dependências.
7. [OOP] Managed Extensibility Framework – Faz a transição de aplicações que são compiladas estaticamente para dinamicamente compostas.
8. [APPFX] s#arp architecture for web applications – Base para desenvolvimento rápido de aplicações web usando ASP.NET MVC com Nhibernate.
9. [APPFX] OpenRasta REST based framework for building web applications – Simplifique expondo uma API baseada em REST para a sua aplicação.
10. [APPFX] CSLA.NET Application Framework – Um abrangente framework para desenvolvimento .NET.
11. [APPFX] Spring.NET Application Framework – Um abrangente framework para desenvolvimento de aplicações web.
12. [RUNTIME] Mono enables .NET on Linux and Mac – Use aquelas habilidades .NET intencionando Linux, BSD e OS X.
13. [UTIL] Sandcastle Help File Builder – Cria uma documentação no estilo do MSDN para assemblies .NET.
14. [HELPER] EasyHook for Windows API Hooking – Estenda código não interpretado (APIs) com código interpretado.
15. [HELPER] Json.NET for working with JSON formatted data – R/W usando o JsonReader e JsonWriter ou serialize seus objetos .NET com uma única chamada.
16. [HELPER] Excel Data Reader for Excel 97 to 2007 – Leia arquivos Excel diretamente em um dataset.
17. [HELPER] #SNMP Library – Uma interface API natural para encapsular funções SNMP.
18. [HELPER] DotNetZip Library  - Uma ótima biblioteca ZIP com algums exemplos.
19. [HELPER] Visio Automation Library  - Automate Visio para C#, Visual Basic e outros.
20. [HELPER] PHPExcel is not just about Excel! – PHP classes para r/w Excel 2007, PDF, HTML e outros.
21. [HELPER] Argotic Syndication Framework for RSS, Atom, OPML and more – Faça a leitura e escrita de conteúdo em vários formatos comuns facilmente.
22. [HELPER] NLog logging library – Escreva facilmente diagnóstico de trecho de código para sua aplicação.
23. A great directory of C# Open Source software – Um bom diretório de bibliotecas, frameworks e ferramentas.

Outros ótimos projetos enviados que não estão na lista final:

• Castle
• MvcContrib
• Subversion
• Nant
• log4net
• Lucene
• CruiseControl
• Paint.NET

Algumas contribuições substanciais da Microsoft sobre a licença MS-PL são:

• ASP.NET MVC Open Source
• .NET Dynamic Language Runtime (DLR)
• IronRuby
• IronPython
• Silverlight Toolkit
• Ajax Control Toolkit
• Managed Extensibility Framework (MEF)

MS-PL é uma licença aprovada OSI e caracterizada pelo GNU como uma licença de software livre que permite qualquer um ver o código fonte, modificá-lo e compartilhar as modificações com outros. Além disto, a licença não limita que o código rode apenar sobre Windows, abrindo possibilidades para portá-lo a outros sistemas operacionais. Dois exemplos são o Mono (.NET no Linux) e Moonlight (Silverlight no Linux). Um plug-in está sendo criado para MonoDevelop para usar ASP.NET MVC no Linux, Mac e OS X.

Fonte: InfoQ

Tivemos no ano 2000, o grande BUG chamado Y2K causado pelo fato de vários softwares e BIOS de computadores utilizarem apenas os dois últimos digitos para armazenarem o ano.

No dia 19 de Janeiro de 2008 iniciou a contagem regressiva de 30 anos para o bug Y2K38, que atingirá os sistemas operacionais UNIX-like em 2038.

Isto ocorre pelo sistema de data destes sistemas operacionais começaram a ser contados, a partir do dia 1 de Janeiro de 1970 e a capacidade da “variável” que armazena os segundos desde de 1970, não suportará o número de segundos daqui a 30 anos, já que esta informação é armazenada em uma variavel “32-bits” (é usado este número, pois é o padrão utilizado nas arquiteturas da maioria dos computadores hoje), ou seja, o número fica enorme para a capacidade suportada da “variável”.

Alguns softwares que trabalham com data até 2038 (principalmente softwares de gerenciamento de projeto) podem começar a sofrer bugs desde agora. Em Maio de 2006 a AOL teve problemas causados por esta deficiência na implementação.