Por Nilseu Padilha para o blog Software Shamanism
em Fevereiro 27, 2009

Padrões são uma constante em Engenharia de Software há pelo menos 14 anos. Não digo nenhuma novidade agora ao afirmar que o trabalho seminal sobre padrões foi o GoF. E que este foi inspirado no trabalho do arquiteto Christopher Alexander na década de 70. Já faz parte do evangelho.

Talvez o que escape ao “senso comum” seja a explosão de patterns através das disciplinas da Engenharia de Software. Alguns exemplos são Análise, Implementação, Modelagem de Dados, Desenvolvimento de Aplicações Corporativas, Integração de Aplicações Corporativas, Arquitetura de Software, Requisitos, Casos de Uso, Modelagem de Negócio, e Documentação.

Quando me vi às voltas da gerência de configuração pela primeira vez, decidi adotar uma abordagem mais pragmática. Ao invés de me inteirar e cair de cabeça na disciplina de gerência de configuracão como um li lateralmente (skimming) alguns livros de SCM. Depois resolvi me guiar por dois livros específicos, primeiramente o livro de Padrões de Configuração Software Configuration Patterns e depois para implantação do Subversion como servidor SCM me guiei pelo livro Pragmatic Configuration Management with Subversion, 2nd. ed. Hoje as soluções implementadas de acordo com estes dois guias estão rodando com sucesso.

Pretendo escrever um arco de 3 posts. Aqui vou explorar Padrões de Gerência de Configuração. No segundo, pretendo escolher determinados cenários e mostrar quais são os patterns adequados para resolução dos problemas. Por fim mostrarei como implementá-los em um sistema de controle de versão, mais especificamente o Subversion 1.5.

Software Configuration Management – Gerência de Configuração de Software em uma Casca de Noz

Gerência de Configuração diz respeito à configuração, identificação, controle de configuração, prestação de contas, revisão, gerenciamento de build, gerenciamento de processo e trabalho em grupo. Estas práticas definem como uma organização contrói e lança produtos bem como identifica e rastreia mudanças.

Em termos mais simples SCM é a função de rastrear e controlar mudanças em um software. Podemos exemplificar o objetivo da SCM com a seguinte pergunta: “Alguém fez alguma coisa, como posso reproduzi-la?”.

A SCM atende esta pergunta através do estabelecimento de práticas como, por exemplo, controle de revisões e baselines.

Controle de revisão trata do gerenciamento de múltiplas revisões de um determinado artefato, como documento ou arquivo de fonte. A intenção é fazer com que as mudanças em um determinado arquivo sob controle de versão (chamado de item de configuração) sejam armazenadas a medida que o usuário for atualizando o arquivo possibilitando a reprodução gradativa das mudanças.

Uma baseline é uma marcação que identifica um certo estado significativo dentro de um conjunto de mudanças realizadas em um histórico de revisões. Um estado significativo em desenvolvimento de software é a aprovação de um conjunto de revisões de um determinado grupo de itens de configuração.

Alguns conceitos importantes para a SCM são workspaces e codelines.

Uma workspace (não confundir com a workspace do IDE como o Eclipse) é um local, como um diretório na estação de trabalho, onde o desenvolvedor mantém todos artefatos necessários para a conclusão de uma tarefa. A workspace é uma cópia associada a uma versão específica dos artefatos.

Uma codeline é a progressão de um conjunto de arquivos referente às mudanças atribuídas ao software no decorrer do tempo. Cada mudança cria uma nova revisão de um determinado artefato.

Em um determinado ponto do tempo, uma codeline pode conter um conjunto de várias revisões de cada componente gerenciado como item de configuração.

Quando determinadas tarefas divergem do propósito original de uma codeline, pode haver a necessidade de se bifurcar um codeline produzindo duas concorrentes. Isto permite a evolução indepente de um determinado item de configuração. Esta operação é chamada de branch (ou ramificação, não sei como os teóricos traduzem nestes dias…). Uma mudança de propósito pode ser a aproximação da release 2 do software, enquanto o trabalho para a release 3 não pode ser retardado por questões de cronograma.

Supondo que a release foi efetuada, ocorre a necessidade de incorporar as mudanças da release 2.1 e 2.2 na release 3. Isto pode ser feito através de uma operação de merge (ou mescla) das modificações do branch da release 2 de volta à codeline principal do produto.

SCM Patterns

Padrões de Gerência de Configuração foram organizados originalmente por Stephen P. Berczuk e Brad Appleton no livro Software Configuration Management Patterns: Effective Teamwork, Practical Integration (também são catalogados no site SCM Patterns for Agility).

Patterns são boas soluções para problemas recorrentes dentro de um determinado contexto (no caso SCM). É uma espécie de reuso de idéias, a grosso modo, uma receita de bolo. Um pattern é o empacotamento de um conhecimento útil para a resolução de problemas num contexto.

Um pattern pode ser organizado dentro de um contexto mairo através de uma pattern language. Uma pattern language é a forma de disposição das soluções (isto é, os patterns individuais) em um contexto onde já há outras soluções implementadas.

Um pattern é especificado sob a forma de um template específico para o contexto de sua aplicação. Em SCM temos os seguintes componentes no template:

• Título
• Ilustração
• Contexto
• Problema
• Descrição detalhada do problema
• Solução
• Descrição detalhada da solução
• Questões em aberto

Classificação de SCM Patterns

Um SCM Pattern é classificado como um padrão de Codeline ou padrão de Workspace, indicando sua aplicabilidade mais adequada. No mapa da SCM Pattern Language podemos identificar o relacionamento dos Patterns em relação a outros para compor uma solução mais abrangente. Em destaque vermelho podemos ver os patterns referentes à codeline. Em verde, os patterns cabíveis ao contexto de workspace.

Segue uma breve descrição dos SCM Patterns e sua aplicabilidade por categoria.

Padrões de Codeline

• Mainline (Linha Principal): Minimizar merges e manter o número de linhas de código ativo gerenciável pelo desenvolvimento sobre uma Mainline.
• Active Development Line (Linha de Desenvolvimento Ativo): Manter uma codeline em rápida evolução suficientemente estável para ser usável pela criação de uma Active Development Line.
• Release Line (Linha de Release): Manter versões entregues sem que estas interfiram no desenvolvimento atual pelo estabelecimento de uma Release Line.
• Private Versions (Versões Privadas): Usar Private Versions para habilitar experimentos com mudanças complexas localmente, ao mesmo passo que seja possível usufruir das features de um sistema de controle de versão.
• Task Branch (Branch de Tarefa): Manter parte da quipe executando tarefas disruptivas sem forçar que o resto da equipe trabalhe em torno destas pelo uso de um Task Branch.
• Release Prep-Codeline (Codeline de Preparação de Release):
• Codeline Policy (Política de Codeline): Criar uma Codeline Policy para ajudar os desenvolvedores a decidir quando realizar o check-in de código para uma codeline e quais os procedimentos seguir antes de realizar o check-in em cada codeline.

Padrões de Workspace

• Private Workspace (Workspace Privada): Prevenir que problemas de integração afetem o seu desenvolvimento e que suas mudanças causem outros problemas através da Private Workspace.
• Integration Build (Build de Integração): Garantir que sua base de código senore seja construída de forma confiável pela execução periódica de um Integration Build.
• Repository (Repositório): Configurar uma nova workspace populando-a a partir de um Repository contendo tudo que você precisa.
• Private System Build (Build Privado do Sistema): Verificar se suas mudanças não irão quebrar o build pela execução de Private System Build antes de commitar mudanças para o repositório.
• Smoke Test (Teste de Fumaça): Assegurar que o sistema ainda funciona após uma mudança através da execução de um Smoke Test.
• Unit Test (Teste unitário): Verificar que o módulo ainda funciona após uma mudança pela execução de um Unit Test.
• Regression Test (Teste de Regressão): Assegurar que o código existente não se degrade a media que você faça novas melhorias pela execução de um Regression Test.
• Task Level Commit (Commit de Nível de Tarefa): Organize mudanças no código-fonte através unidades de trabalho orentadas a tarefas e submeta mudanças como um Task level Commit.
• Third Party Codeline (Codeline de Terceiros): Gerencia código de fornecedores pelo uso de uma Third Party Codeline.

Um cartão de referência dos SCM patterns pode ser encontrado (inclusive com o mapa da pattern language) aqui.

Conclusão

Aqui fiz uma breve revisão sobre alguns conceitos de SCM Patterns. Iniciei com alguns conceitos básicos sobre SCM e descorri sobre os padrões definidos pelo Appleton e pelo Berczuk. Estes padrões já apliquei com sucesso em dois grandes sistemas, um legado onde não havia política de gerência de configuração e outro grande conjunto de sistemas federados iniciado do zero. Em ambos os casos os padrões se demonstraram muito eficientes para atender tanto na manutenção de um sistema como no desenvolvimento de outro.

Fonte: Software Shamanism

Postado por Francisco Trindade
em Maio 21, 2009

Desde o advento da era industrial, nos descobrimos uma palavra incrível para tudo: “mais”. Realmente sempre funcionou. Quando nossas ruas ficaram cheias, nós contruímos mais ruas. Quando nossas cidades ficaram inseguras, nós contratamos mais policiais e compramos mais carros de polícia.

Esse é a introdução de um dos capítulos do livro que eu estou lendo atualmente, Information Anxiety, que fala sobre como viver em um mundo onde não temos tempo para absorver todos os dados que são atirados contra nós.

O que eu achei interessante é como essa frase pode ser aplicada em diferentes áreas, de policias, conforme citado acima, a desenvolvimento de software.

E é surpreendente quantas pessoas que trabalham nesse campo ainda acreditam que um projeto de software atrasado pode ser solucionado com uma simples medida: colocando-se mais pessoas no time.

É tão atraente que ninguém acredita que essa medida possa dar errado, e acabam esquecendo de alguns pequenos detalhes, como:

• tempo que leva para novos desenvolvedores entenderem o projeto e o seu domínio
• tempo que leva para novo desenvolvedores conhecerem as pessoas que estão no projeto
• o problema criado na comunicação do time com a adição de novos nodos

E freqüentemente as pessoas responsáveis por medidas como essa esquecem de olharem para o seu time para realmente tentar entender as causas raiz dos problemas que estão acontecendo em uma maneira anti-genchi-genbutsu de resolver problemas.

Em um projeto do qual participei recentemente, 4 pessoas foram adicionadas a um time de 3 pares, tentando aumentar a velocidade que o time estava entregando. Não se precisa dizer que na primeira semana nós tinhamos um time de 5 pares com 4 pessoas novas, e se alguém olhasse para a sala onde trabalhávamos, veria que em cada par havia uma pessoas tentando explicar para alguém novo como o sistema funcionava.

É fácil de entender que o time na verdade tinha metade do seu potencial, e que na primeira iteração no entregamos… adivinhem quanto… metade dos pontos!

Então, se vc está pensando em aumentar o seu time, pense de novo, e depois mais uma vez, e invista um tempo olhando como o seu time trabalha antes de tomar qualquer decisão.

Fonte: Blog Visão Ágil

Postado por Vikas Hazrati, traduzido por André Dourado em Maio 20, 2009

Recentemente, Dave Nicolette consolidou uma lista de tutoriais recomendados sobre TDD, a partir de uma discussão no Extreme Programming group. Aqui está uma sneak peak at the consolidated list categorizada, para um início rápido com Test Driven Development.

Tutoriais

• Introduction to TDD
• Test Automation Tips
• Perl in Test Automation
• TheCodeProject: Test-Driven Development in .NET
• Tutorial by Michael Schwern

Séries sobre TDD

• Hands-On TDD Tutorial Series from JavaHobby
• Evolutionary architecture and emergent design Series

Apresentações

• Intro to TDD for Windows Programming
• TDD Overview by Jeff Langr
• TDD Tutorial on slideshare.net

Audio

• Tutorial by Jean Paul Boodhoo

Aprendizado Hands-on

• TDD Problems
• TDD Randori & Fishbowl workshop materials

Recentemente Dave também adicionou uma versão draft de um livro sobre TDD, que está sendo escrito por Steve Freeman e Nat Pryce, à sua coleção. Há também uma interessante coleção de conteúdo relacionado a TDD no InfoQ. Algum conteúdo recente no InfoQ inclue:

• Manager’s Introduction to TDD
• Steve Freeman On TDD: How Do We Know When We’re Done?
• Making TDD Stick: Problems and Solutions for Adopters
• Hakan Erdogmus on TDD Misunderstandings and Adoption Issues

Fonte: InfoQ (USA)

Postado por Chris Sims, traduzido por Vinicius Assef em 19 Mai 2009 11:29 AM

Há pouco tempo, Buddha Buck perguntou na lista de Extreme Programming se existe uma média de velocidade que poderia ser considerada ‘boa’ para uma equipe de sete pessoas que realiza iterações de duas semanas. Ele sentiu que uma velocidade de oito para baixo indicaria que as estórias estariam muito grandes. A discussão em torno do tema conseguiu responder a essa e a outras questões decorrentes também.

A velocidade é usada como uma ferramenta para predizer a produtividade futura da equipe. Se todas as estórias que a equipe trabalhou forem do mesmo tamanho, no que diz respeito à quantidade de trabalho necessário para implementá-las, então poderí­amos apenas contar o número de estórias que a equipe completou por iteração. Uma determinada equipe provavelmente terminaria o mesmo número dessas "histórias do mesmo tamanho" a cada iteração, e a gerência poderia fazer planos conforme a capacidade conhecida dessa equipe.

Em muitos ambientes, as estórias não são todas do mesmo tamanho. Entretanto, as estórias recebem tamanhos relativos, frequentemente chamados de estimativas. Uma estória de tamanho dois tem o dobro do tamanho de uma estória de tamanho um. Uma estória de tamanho três, tem o triplo do tamanho, e assim por diante. É razoável esperar que as estórias de tamanho dois, em média, demorem o dobro do tempo para serem completadas, em relação às estórias de tamanho um. Para faciliar essas estimativas, os tamanhos são medidos em uma unidade chamada ‘pontos’ ou ‘story points’. Assim, podemos dizer que uma estória de cinco pontos provavelmente vai demorar cinco vezes mais que uma estória de um ponto. Na média, uma equipe estará propensa a terminar o mesmo número de pontos de esforço de trabalho em cada iteração; este número é a velocidade da equipe. Desta forma, a velocidade é a capacidade de realização da equipe. Ela mede a quantidade de trabalho uma equipe consegue produzir em cada iteração.

Steven E. Newtondiz que "Uma boa velocidade é aquela que consegue dar uma noção clara de quanto trabalho você terá pronto nas iterações seguintes."

Kent Beck apontou outro benefício de saber a velocidade da equipe:

Outra finalidade de medir a capacidade é melhorar a vazão de entrega. Se você planeja entregar menos do que pode, terá menos do que sua equipe conseguiria. Se você planejar além, também terá menos do que realmente poderia entregar.

Charlie Poole lembrou aos participantes que os desenvolvedores tendem a pensar na quantidade de trabalho que será necessária para implementar as estórias, enquanto os gerentes e clientes pensam na quantidade de valor que está sendo entregue quando as estórias estiverem terminadas. É importante notar que a estimativa da estória e a velocidade estão relacionadas com a quantidade de trabalho existente e o tempo necessário para completá-lo.

O aspecto mais básico da pergunta de Buddha foi respondido, mas a discussão continuou examinando alguns dos problemas mas comuns nessa questão. Em particular, Buddha concluiu que as estórias de sua equipe estavam grandes demais. Os participantes desse tema confirmaram que estórias menores são preferíveis às maiores.

Tim Ottinger comentou que estórias menores fornecem pontos de checagem mais frequentes e ajudam a equipe e aos patrocinadores a saberem a quantidade de trabalho já realizada em determinado momento.

Obviamente nenhuma estória deveria ser maior do que uma iteração. A maior estória da iteração corre um grande risco de não ser terminada. Você não quer se ver em uma situação onde você tem N pontos ou 0 pontos. Seria bom se você tivesse 40% dos pontos terminados no meio da iteração.

Steven Gordon também compartilhou algumas dicas.

• Se você não tem certeza de que as estórias são mesmo pequenas, então provavelmente elas são muito grandes.
   
• Se as estórias forem pequenas demais, a equipe vai notar que a sobrecarga de acompanhá-las parece um desperdí­cio.

   

• Os problemas decorrentes de estórias muito pequenas são menores do que os decorrentes das estórias muito grandes. Dessa forma, errar para menos é melhor do que para mais.
   
• Se estórias muito pequenas são o maior impedimento que uma equipe tem, comemorem juntos. Vocês são mestres em XP.

Ron Jeffries disse que ele gosta de ver as estórias de um tamanho, tal que uma dupla de programadores possa terminá-las em uma semana. Ele foi menos apaixonado com o conceito de pontos:

Eu acho que os pontos são uma bobagem e eu me arrependo de tê-los recomendado com tanta ênfase. Ele faz com que você se distraia do mais importante, que é quebrar as estórias até que elas sejam pequenas e possam ser feitas praticamente num ritmo constante.

Como sua equipe decide o tamanho que as estórias terão? Você usa a velocidade da equipe como um indicador de tamanho? Deixe um comentário e compartilhe seu pensamento.

Fonte: InfoQ

Uma paródia da Dell com a “Dança do Créu” tem sido motivo de polêmica. No marketing viral, que tenta associar a ideia de velocidade aos produtos da marca, o ‘créu-créu-créu-créu’ foi substituído pelo ‘dell-dell-dell-dell’.

Entretanto, internautas que já viram o vídeo têm se mostrado contra o viral com comentários postados em redes socias e no YouTube. Além disso, muitas critícas têm sido feitas aos responsáveis pela criação.

Eu particularmente achei a idéia engraçada e interessante. Acho que as pessoas levam tudo muito a sério. Segue o vídeo:

Postado por Vikas Hazrati, traduzido por Roberto Costa em 18 Mai 2009 03:23 PM

Há uma série de discussões e debates sobre o tamanho ideal de uma equipe para obter o máximo de produtividade. Apesar da maioria dos Agilistas concordarem que times menores são mais funcionais e produtivos comparados com times maiores, definir o tamanho ótimo da equipe continua sendo um desafio.

Jeff Sutherland compartilhou algumas estatísticas a favor de times menores onde, o custo por ponto de função de uma equipe com 7 membros era $566 e o de uma equipe com 14 membros era $2970. Em linhas similares, em resposta à postagem na InfoQ, sobre o crescimento e produtividade do time, Mishkin Berteig comentou:

Imagine que você "recebeu" um grupo de desenvolvimento de software com 100 desenvolvedores. Agora imagine que você recebeu um projeto muito importante para trabalhar com ele. O que seria melhor:

a) Colocar todos as 100 pessoas para trabalhar no projeto (com bom gerenciamento de projetos, liderança, etc), ou….

b) Encontrar as 7 pessoas mais fortes do grupo que estão desejando trabalhar no projeto (em outras palavras, as setes pessoas mais fortes que estão efetivamente interessadas no projeto) e coloque-as para trabalhar no projeto, demita as restantes, gaste o dinheiro salvo com as melhores ferramentas e ambiente que as 7 pessoas precisam e querem e gaste o resto para fazê-las felizes/confortáveis.

Pessoalmente, apesar da gravidade do cenário b), Eu apostaria definitivamente nele e não no cenário a).

Jurgen Appelo sugeriu que o tamanho ótimo de uma equipe seria apenas com 5 membros. Cinco é um número comum baseado em vários estudos sobre comunicação e estruturas de equipes.

• Scrum recomenda que o tamanho da equipe deve ser 7 variando de mais ou menos 2. Ou seja, a equipe pode variar 5 e 9

• De acordo com a Linha Cognitiva, o cérebro humano tem co-evoluído com as condições sociais e existe um limite natural na quantidade de relações sociais que uma pessoa pode manter. O estudo pode ser facilmente rotulado como a regra de 5, 15 e 100. 5 está ligado ao limite natural da memória de curto prazo, 15 é o nível natural da confiança profunda e 150 é o número de identidades que uma pessoa consegue manter na sua cabeça.

• Outro estudo relacionado à Lei de Parkinson Law, sugere que qualquer equipe com tamanho menor que 20 consegue trabalhar menos 8. Acima de 20 há um afastamento natural em subgrupos e nenhum consenso pode ser formado. Com 8, as pessoas geralmente encontram-se em situações de deadlock diante de decisões.

Além de adicionar suporte a equipes com 5 membros com um comentário na Lei de Parkinson, PMHut sugeriu o seguinte:

Quanto mais membros na equipe você tem, mais canais de comunicação você terá, e isso crescerá exponencialmente. Se você tem 3 membros na equipe, então você terá 4 canais de comunicação, se você tem 4 membros então você terá 9 canais. Eu acho que a fórmula é m-1^2.

Em minha opinião, uma equipe pequena com 4 ou 5 membros é o ideal.

Com isso, dado os estudos e fatos acima uma equipe com tamanho 5 parece satisfazer todas as condições relacionadas as recomendações do Scrum, Lei de Parkinson limite natural de memória de curto prazo e canais de comunicação favoráveis.

Entretanto, apesar da forte evidência a favor de uma equipe com 5 membros, Jurgen advertiu que ao invés de seguir a recomendação do tamanho da equipe, as equipes devem primeiro tentar se auto-organizar e gradativamente chegar a uma equipe de tamanho ideal. Segundo ele,

Quando você precisa estruturar um grande projeto, não imponha um tamanho de equipe “preferido” nas pessoas só por que isso está escrito em um livro. Tente permitir uma auto-organização para fazer esse trabalho e permita que as pessoas (dentro do seu ambiente real) percebam qual é a sua otimização. Eles querem dividir uma equipe de sete em duas equipes de três e quatro? Certeza, por que não? Eles estão juntando duas equipes em uma grande equipe de quinze membros? Legal, deixe-os ver se isso funciona.

Fonte: InfoQ

Por Alexandre Magno para o aXmagno Blog
em Maio 17, 2009

Ministrar treinamentos e poucas horas de consultoria é CASE??? Por favor gente, case é um negócio bem mais amplo do que “treinei 15 pessoas no cliente tal e depois passei uma semana dando consultoria lá”, isso está bem mais para marketing do que case. Se é para apresentar cases assim…afff, tenho um portfolio bem vasto, mas não passaria por esse papelão

Fonte: aXmagno Blog

Por Alexandre Magno para o aXmagno Blog
em Maio 17, 2009

Durante o Brazil Scrum Gathering tivemos “alguns” comentários polêmicos. Vou iniciar aqui uma sessão de curtas na qual vou focar no QUE foi falado e dar minha opinião sobre.

Scrum e auto-gerenciamento
Se você diz não acreditar em auto-gerenciamento, simplesmente VOCÊ NÃO ACREDITA EM SCRUM! Abrir mão do auto-gerenciamento é se render ao comando-controle, prática completamente abominada em ambientes Scrum. Se você diz que não acredita que profissionais possam ser auto-gerenciados, você está fugindo de uma das principais responsabilidades de um ScrumMaster: educar seu time! Entendo, delegar tarefas e pedir status é mais fácil que educar pessoas, mas por favor, se é isso que você que fazer, ESQUEÇA SCRUM e siga outro caminho.

Fonte: aXmagno Blog

O nerd de hoje é o cara rico de amanhã
O nerd de hoje é o cara lindo de amanhã
O nerd de hoje é o bom marido de amanhã
Garota, escolha já seu nerd!

Enquanto o bonitão está pegando você
O nerd está criando um software no PC
Enquanto o sarado malha na academia
O nerd está lendo as notícias do dia

Enquanto o bonitão tá na balada te chifrando
O nerd com certeza está em casa estudando
O curso superior do gostosão tá no início
E o nerd ganha em dólar no Vale do Silício

O nerd de hoje é o cara rico de amanhã
O nerd de hoje é o cara lindo de amanhã
O nerd de hoje é o bom marido de amanhã
Garota, escolha já seu nerd!

O nerd tem conserto, é só você ensinar
O penteado certo e a melhor roupa pra se usar
O saradão de hoje é o gordo de amanhã…
Parou de tomar bomba? Vai ter que usar sutiã!

O gostosão ainda sai no carro do pai
E o nerd é a atração de um workshop em Dubai
O gostosão te esquece quando vê um carro esporte
E o nerd está lá dentro com uma mulher de sorte

O nerd de hoje é o cara rico de amanhã
O nerd de hoje é o cara lindo de amanhã
O nerd de hoje é o bom marido de amanhã
Garota, escolha já seu nerd!

Imagine o nerd sem cabelo ensebado
Sem espinhas e sem colarinho abotoado
Sem o cinto social junto com tênis branco
Imagine o nerd com cinco milhões no banco!

(Letra e música: Maurício Ricardo. Arranjos e produção: Neto Castanheira)

Os Seminovos são: Neto Fog (voz), Maurício Ricardo (baixo, voz), Neto Castanheira (guitarras, produção), Tchana (guitarra base, voz), Alex Mororó (bateria).

Fonte: www.charges.com.br

É incrível como o tempo passa e alguns problemas ainda continuam, principalmente em relação ao tratamento que se dá à área de TI de uma organização cujo negócio principal não é TI.

Sem dúvida a TI passou a ter uma importância estratégica nas organizações nos dias de hoje, impulsionado pela evolução de frameworks a partir da década de 80 (ITIL, Cobit, ISO 20000, etc) e certificações que mostraram o verdadeiro papel da TI, não mais como provedor de tecnologia, mas o de prover serviços para seus clientes.

Hoje há serviços em que é praticamente impossível separar a TI do negócio, vide os sistemas bancários, como o brasileiro por exemplo, um dos mais avançados do mundo.

Mas nem tudo mudou nos departamentos de TI mundo afora, principalmente nas empresas menores.

Nos vídeos, tragicômicos, diríamos, mostram como uma cadeia de decisões erradas, que vão desde a contratação da equipe, selecionada por um gestor que desconhece completamente sobre TI, que por sua vez seleciona uma gerente com nível de preparo no mínimo dúvidoso (para ser bem gentil). Bem, o resto você vai ver.

Aproveite para ver se você consegue identificar alguns desses problemas presentes ainda na empresa onde você trabalha:

Parte 1: http://www.youtube.com/watch?v=-y7pfJRe0PM

Parte 2: http://www.youtube.com/watch?v=kb8h1Bw51qc&feature=related

Se você identificou um problema ou outro, pode não ser tão grave já que nada é perfeito, mas se o número de problemas similares encher os dedos de uma mão, já é para ficar um pouco preocupado.

Fonte: Carreira e Certificações em TI