Skip to content

Campanha: Pague um curso de Front-end para um desenvolvedor Back-end

Constantemente presencio discussões acaloradas entre profissionais de back-end e front-end. As discussões chegam a nível de religião. Back-end e Front-end defendem seus pontos de vistas com uma tremenda ignorância vendo importância apenas no que acreditam.

Mas essa briga é antiga. E não envolve somente essas duas funções. Quem lembra desse charge?

 

Por muito tempo o foco no desenvolvimento de softwares foi sempre no código funcional. Nós desenvolvedores fazemos de tudo para preocupar com um código de qualidade. Porém atualmente há uma nova preocupação com a experiência do usuário, afinal, o usuário não quer saber se o código foi feito com o padrão “x” ou com a tecnologia “y”, ele quer um sistema funcional e usável. Você que é desenvolvedor back-end já deve ter comentado ou escutado algo do tipo: “O usuário é burro. Não sabe de nada. Meu código é lindo e funcional”. Sim o usuário pode não saber de todas as técnicas que você utilizou no sistema mas você está fazendo o sistema para quem mesmo?

Essa preocupação com a usabilidade foi ser firmando tanto que surgiu uma nova profissão, a de Front-end developer. O Front-end é responsável por criar toda a interface do usuário e se preocupar com a experiência do usuário. Como o usuário vai se sentir ao utilizar o sistema. O usuário tem que se sentir que seu sistema é “fodaa” ao utilizá-lo. Quem tem IPhone vai entender isso que estou falando. O IOS é foi muito bem pensado em termos de usabilidade. É fácil e agradável usar um IPhone. (tirando aquele corretor ortográfico fdp****). rs

Hoje vivemos um boom de front-end. É uma profissão muito comentada nas empresas que buscam inovação. Porém as empresas mais conservadoras continuam com a mesma mentalidade passada. Principalmente as boas e velhas fábricas de softwares. Andei pensando no porque disso, e o motivo é sempre o mesmo. O bom e velho imperialismo comercial. As empresas não querem investir em uma equipe que se preocupa com isso pois terá um aumento de custo sem retorno concreto. Em resumo, foda-se a satisfação do cliente, queremos é entregar o produto. (já comentei sobre essa atitude comum em fábricas em outro post).

Por outro lado, os front-ends estão no auge e aproveitaram para subir em um pedestal. Há alguns ousados que dizem que a profissão de back-end irá acabar. hahaha.

hahaha

….hahaha

Risos para vocês. Como falei no começo do post, o assunto é tratado como religião. Sempre tem os entusiastas xiitas mais conhecidos como hypistas que vestem a camisa e não tiram mesmo se está sem lavar a 1 ano. Segurem sua bola ae. Todo mundo sabe que bala de prata não existe na nossa área.

Para finalizar, acredito que as duas profissões são importantíssimas e essenciais para o desenvolvimento de um produto de qualidade. Vamos deixar o orgulho de lado e pensar no real valor que o produto que estamos desenvolvendo tem. O cliente quer, principalmente, um sistema funcional, que atenda aos objetivos do seu negócio. E isso pra mim é a premissa para todo sistema. Mas porque não ser oferecer um sistema que além de funcional é foda de usar? Será mesmo que o valor do sistema está somente em atender com perfeição os objetivos do negócio? Por que não atender com perfeição os objetivos do negócio e além disso oferecer uma experiência diferenciada para o usuário?

Há quem diga que o Steve Jobs foi um gênio, pois ele fazia as pessoas acordarem de madrugada para entrar em uma fila para comprar um produto em lançamento. Ele soube aproveitar o melhor desse conjunto. O melhor em usabilidade com o melhor em hardware e software. Convenhamos, os produtos da Apple são excelentes, tanto em termo de sistema, quanto de usabilidade.

E vocês? O que acham? Por favor, comentem. Esse blog para mim é como se fosse uma conversa de bar onde estou expressando minhas opiniões. Espero escutar as opiniões de vocês, principalmente as contrárias.

Abraços.

 

Quantos WTF tem seu código?

Discutindo com alguns amigos sobre qualidade de software e métodos para se controlar a qualidade, escutei sobre o método de contagem de WTF (What fuck – Code Quality Measurement: WTFs/Minute).

WTF

O funcionamento é bem simples. Na revisão de código por terceiros, se conta quantos WTF por minuto o revisador irá falar.

Agora imagina essa metodologia sendo aplicada. Vejo um alto índice de processos trabalhistas por agressão ao colega de trabalho.

Por mais cômico que seja a brincadeira, o método é utilizado naturalmente sem que percebemos.

O ambiente de desenvolvimento, principalmente na linguagem java, é muito cheio de padrões de projetos e de desenvolvimento de código. Esses padrões foram criados por programadores que testaram e comprovaram que o funcionamento trazia vantagens ao projeto, seja na manutenção do código ou no desempenho do mesmo. Porém a maioria dos padrões visam o melhoramento do código para trabalho em equipes grandes findando uma manutenção duradoura. Nesse ponto bate de frente com o orgulho do programador.

Oh raça orgulhosa!!! Não é?

Qual programador que quando escuta um outro colega de equipe falando que seu código está ruim e que não passa pela cabeça pelo menos alguns xingamentos até a terceira geração de quem revisou seu código?

Em fábricas de softwares é comum existir revisão de código. E sempre percebo que a equipe que faz a revisão apresenta os resultados como se estivessem pisando em ovos, com o máximo de cuidado para não criar conflitos. Mas o que os programadores não entendem é que os padrões utilizados dependem da cultura da empresa. Uma revisão de código que apontam erros em desenvolvimento por desobedecer padrões não significa necessariamente que seu código é ruim e somente que não está seguindo os padrões da empresa. Mas como todo programador é extremamente orgulhoso,vê isso como uma injúria e tenta justificar a todo custo que a sua forma de desenvolver é melhor.

Na minha opinião, o cenário perfeito seria manter o equilíbrio entre a observância dos padrões da empresa com as formas diferentes de desenvolvimento de cada programador pois ao mesmo tempo que o programador pode estar errado em não seguir um padrão da empresa, o mesmo pode ser subaproveitado pois seguir padrões engessa o desenvolvimento e impede a inovação e melhoramento. O problema desse equilíbrio é que todo programador acha que sua forma de desenvolver é a melhor por mais que seja totalmente diferente do colega de equipe do lado que por sua vez também acha que sua forma de desenvolver é a melhor.

E você? Já sabe quantos WTFs tem no seu código? Faça um teste WTF com você mesmo olhando um código seu antigo. É divertido! rs

Somos todos Hipócritas

Não ao Jeitinho Brasileiro

Está na moda protestar contra corrupção política. Tem gente que enche a boca para falar mal de político. O povo está cansado de tanta robalheira.

Vamos refletir um pouco. Em uma democracia representativa, os políticos ao qual fazemos referência (deputados, senadores, governadores, prefeitos, vereadores…) quando abrimos a boca cheios de razão para chingá-los com todo gosto, são os que nos representam. Perae, mas esses caras não me representammmmmm! Não é a primeira coisa que pensamos?

Será mesmo que não te representa seu filho da puta hipócrita? Vou encher a minha boca pra falar de você agora!

E as vezes que você furou a fila de banco porque encontrou um amigo lá na frente? Ou as vezes que você comprou algum produto pirateado? Ou fez um “gato” na rede elétrica? Ou o “gato” da tv a cabo, o famoso tv a gato? Ou que participou de algum “esquema” para ter vantagem em algo? Você realmente nunca teve vantagem em algo que você sabia que era ilegal? Nunca mesmo? Mentiroso filho da puta!

Jeitinho Brasileiro

Poderia citar várias situações cotidianas de corrupção que acontece constantemente.

Isso é corrupção tanto quanto a que seus representantes que você chinga. Toma vergonha na tua cara!

O jeitinho brasileiro infelizmente está no sangue. Nossa educação e cultura estão enraizadas. O que vale é ser mais esperto que o outro. Ter vantagem. Mas todos sonhamos com um futuro melhor! Ingênuos.

Ninguém respeita constituição, mas todos acreditam no futuro da nação. Que País é esse!

Iniciando um projeto com Apache Wicket

O Apache Wicket é um framework web, componente-based, tem um desenvolvimento parecido com desenvolvimento java desktop com swing.

Sem mais delongas, vamos ao código.

Baixe as bibliotecas do wicket e suas dependências:

Após adicionar as bibliotecas no projeto, configure o arquivo WEB-INF/web.xml da seguinte forma:


<?xml version="1.0" encoding="ISO-8859-1"?>
   <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">
      <display-name>Teste Wicket</display-name>
      <context-param>
         <param-name>configuration</param-name>
         <param-value>development</param-value>
      </context-param>
      <filter>
         <filter-name>testewicket</filter-name>
         <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
         <init-param>
            <param-name>applicationClassName</param-name>
            <param-value>br.com.testewicket.TesteWicketApplication</param-value>
         </init-param>
      </filter>
      <filter-mapping>
         <filter-name>testewicket</filter-name>
         <url-pattern>/*</url-pattern>
      </filter-mapping>
      <welcome-file-list>
         <welcome-file>index.html</welcome-file>
      </welcome-file-list>
   </web-app>

Agora crie uma classe TesteWicketApplication.java no pacote br.com.testewicket com o conteúdo abaixo.


import org.apache.wicket.protocol.http.WebApplication;
import br.com.testewicket.view.pages.Index;

public class TesteWicketApplication extends WebApplication {

   /**
   * Constructor
   */
   public TesteWicketApplication() {
      super();
   }

   public Class getHomePage() {
      return Index.class;
   }

   @Override
   protected void init() {
      super.init();
   }

}

Essa classe serve para configurarmos o start da aplicação. É aqui que adicionamos parâmetros e configuramos o que desejamos para a inicialização da aplicação.
Lembrando que essa classe tem que estar configurada no web.xml como já fizemos.

Bom nesse momento nossa aplicação vai estar com erro de compilação pois não existe a classe Index.java. Vamos criar a mesma no pacote br.com.testewicket.view.pages com o código a seguir:

import org.apache.wicket.PageParameters;
import org.apache.wicket.markup.html.WebPage;
import org.apache.wicket.markup.html.basic.Label;
/**
* Homepage
*/
public class Index extends WebPage {

   private static final long serialVersionUID = 1L;

   public Index(final PageParameters parameters) {
      add(new Label("<code>labelid</code>", "No \"Hello World\""));
   }

}

Toda classe que extende WebPage representa uma página html da sua view. Por convenção do wicket essa pagina deve ter o mesmo nome da classe e estar no mesmo pacote. Então crie um html chamado Index.html no pacote br.com.testewicket.view.pages com o seguinte conteúdo:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
   <head>
   </head>
   <body>
      <span wicket:id="labelid"></span>
   </body>
</html>

Bom, ao executar o código o wicket vai identificar o componente na tela através do seu id (

wicket:id="labelid"

) e adicionar o valor para ele como determinado no trecho de código (

add(new Label("labelid", "No \"Hello World\""));

).

Como percebemos, a classe java faz a ligação com componentes java, no nosso caso o Label, com os elementos da tela.

No processo de renderização o Wicket renderiza a resposta na view criando o elemento ou atualizando o mesmo com as alterações feita no código java.

De forma básica é assim o funcionamento do wicket. Nos próximos posts irei entrar mais nos fundamentos teóricos do mesmo e talvez quem sabe um benchmark entre wicket e jsf. O que acham?

Abraços.

Qualidade é subjetiva, o importante é entregar!

Me incomodo de mais com o cenário atual de desenvolvimento de software brasileiro.

Você com certeza já escutou alguma dessas frases:

  • “Faz de qualquer jeito, o que importa é entregar!”
  • “Faz o que o cliente pediu mesmo não sendo o melhor.”
  • “O cliente não pediu por qualidade.”

Recentemente venho discutindo com alguns amigos sobre qualidade de software e infelizmente a percepção comum é que o interesse que rege esse conceito é único e exclusivamente Comercial.

E a preocupação com acessibilidade dos sistemas? E a preocupação com a qualidade? Se o software é seguro? Se o software aguenta uma carga de dados grande? Se o software é usual? Quem liga para essas coisas? afinal o cliente não pediu nada disso.

Agora me respondam uma pergunta. Está certo?

“Ah André mas você é muito jovem, ainda vai descobrir que não tem como fazer as duas coisas ao mesmo tempo.”

Bingo! Então devo continuar fazendo meu trabalho feliz, fazendo as coisas erradas porque assim que tem que ser🙂

NÃOOOO! Está erradoooooo!

Convenhamos, com certeza a empresa precisa de lucro para sobreviver. Mas para isso tem que fazer um trabalho porco?

Infelizmente 99% das pessoas que estão a frente das empresas não gostam do que fazem. Só ligam pro faturamento.

Empresários que só visam dinheiro, pensem comigo. Esse é um cenário ainda inexplorado no Brasil. Essa é uma oportunidade de negócio. Se você passar a ser reconhecido pelo seu trabalho bem feito de qualidade, que traz retorno de valor para o cliente, isso não será um diferencial? Claro que sim! Você inclusive vai poder cobrar a mais por isso, pelo seu trabalho de qualidade. Porque pagamos caro pelos produtos da Apple? Porque sabemos que toda a qualidade diferenciada dos produtos da Apple geram valor no final. E os seus produtos, geram valor para os clientes? ou  só “Faz o que o cliente quer pra liberar logo?”. Quantas vezes já escutamos isso não é mesmo?

Esses dias escutei que a qualidade de software é subjetiva. Se o cliente aceita o produto é porque o produto serve para o cliente. Aqui entra um outro ponto. O cliente não sabe o que quer no que diz respeito a tecnologia. O cliente sabe do negócio e quer que o sistema atende as necessidades do negócio. Se o sistema atende ao negócio, está tudo bem. Então porque tem gente que compra aparelhos da Apple? Porque não compra um ching-ling qualquer que atende as suas necessidades?

Eu sei que isso não vai mudar. Que vai continuar existindo empresas que trabalham da mesma forma. E tudo bem, sempre vai ter cliente. Mas e a empresa que faz um trabalho exepcional, cade? a Apple do desenvolvimento de software? Existe? Onde?

PMBOK 4 – Uma abordagem não muito prática.

PMBOK front page

Apesar dos títulos engraçadinhos, vamos lá continuar com a série de estudos sobre assuntos relacionados a TI.

PMBOK Versão 4 (Project Management Body of Knowledge)

O PMBOK é um livro que apresenta um conjunto de práticas de gerenciamento de projetos que constitui a base de conhecimentos do PMI (Project Management Institute). Tais conhecimentos são reconhecidos como boas práticas possibilitando a promoção de um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando o intercâmbio eficiente de informações entre os profissionais de gerência de projetos.

  • Estrutura

O guia é baseado em processos que são descritos da seguinte forma:

  1. Entradas (documentos, planos, desenhos etc.);
  2. Ferramentas e técnicas (que se aplicam às entradas);
  3. Saídas (documentos, produtos etc.)
  • O que é gerenciamento de projetos?

Segundo o próprio guia, o gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto a fim de atender aos seus requisitos. O gerenciamento de projetos é realizado através da aplicação e integração apropriadas dos 42 processos agrupados logicamente abrangendo os 5 grupos. Os 5 grupos de processos são:

  1. Iniciação;
  2. Planejamento;
  3. Execução;
  4. Monitoramento e controle e
  5. Encerramento.

Tais processos também são conhecidos por formarem o ciclo de vida do projeto.

O ciclo de vida de um projeto consiste nas fases do mesmo que geralmente são sequenciais e que às vezes se sobrepõem, cujo nome e número são determinados pelas necessidades de gerenciamento e controle da(s) organização(ões) envolvidas , a natureza do projeto em si e sua área de aplicação. Um ciclo de vida pode ser documentado com uma metodologia. O ciclo de vida pode ser definido ou moldado de acordo com aspectos exclusivos da organização, indústria ou tecnologia empregada.

O ciclo de vida oferece uma estrutura básica para o gerenciamento do projeto, independentemente do trabalho específico envolvido.

  • Processos de gerenciamento de projetos

O gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto a fim de cumprir seus requisitos. Esta aplicação de conhecimentos requer o gerenciamento eficaz de processos apropriados.

Para que um projeto seja bem-sucedido, a equipe do projeto deve:

  • Selecionar os processos apropriados necessários para cumprir os objetivos do projeto;
  • Usar uma abordagem definida que possa ser adotada para atender aos requisitos;
  • Cumprir os requisitos para atender às necessidades e expectativas das partes interessadas e
  • Obter um equilíbrio entre as demandas concorrentes de escopo, tempo, custo, qualidade, recursos e riscos, para gerar o produto, o serviço ou o resultado especificado.

Os processos do projeto também são executados pela equipe do projeto e, em geral, podem ser classificados em uma de duas categorias principais:

  • Os processos de gerenciamento de projetos garantem o fluxo eficaz do projeto ao longo de sua existência. Esses processos abrangem as ferramentas e as técnicas envolvidas na aplicação de habilidades e capacidades descritas nas Áreas de Conhecimento.
  • Os processos orientados a produtos especificam e criam o produto do projeto. Em geral, são definidos pelo ciclo de vida do projeto e variam de acordo com a área de aplicação. O escopo do projeto não pode ser definido sem algum entendimento básico de como criar o produto especificado. Por exemplo, diversas técnicas e ferramentas de construção devem ser consideradas ao determinar a complexidade geral da casa que será construída.

Os processos de gerenciamento de projetos são agrupados em cinco categorias, conhecidas como grupos de processos de gerenciamento de projetos (ou grupos de processos):

  • Grupo de processos de iniciação. São os processos realizados para definir um novo projeto ou uma nova fase de um projeto existente através da obtenção de autorização para iniciar o projeto ou a fase;
  • Grupo de processos de planejamento. Os processos realizados para definir o escopo do projeto, refinar os objetivos e desenvolver o curso de ação necessário para alcançar os objetivos para os quais o projeto foi criado;
  • Grupo de processos de execução. Os processos realizados para executar o trabalho definido no plano de gerenciamento do projeto para satisfazer as especificações do mesmo;
  • Grupo de processos de monitoramento e controle. Os processos necessários para acompanhar, revisar e regular o progresso e o desempenho do projeto, identificar todas as áreas nas quais serão necessárias mudanças no plano e iniciar as mudanças correspondentes;
  • Grupo de processos de encerramento. Os processos executados para finalizar todas as atividades de todos os grupos de processos, visando encerrar formalmente o projeto ou a fase.

Gerenciar um projeto inclui:

  1. Identificação dos requisitos;
  2. Adaptação às diferentes necessidades, preocupações e expectativas das partes
  3. interessadas à medida que o projeto é planejado e realizado;
  4. Balanceamento das restrições conflitantes do projeto que incluem, mas não se
  5. limitam a:
  • Escopo;
  • Qualidade;
  • Cronograma;
  • Orçamento;
  • Recursos e
  • Risco.
  • Áreas de conhecimento

Consiste nas seguintes áreas:

  1. Gerenciamento/Gestão de integração do projeto
  2. Gerenciamento/Gestão do escopo do projeto
  3. Gerenciamento/Gestão de tempo do projeto
  4. Gerenciamento/Gestão de custos do projeto
  5. Gerenciamento/Gestão da qualidade do projeto
  6. Gerenciamento/Gestão de recursos humanos do projeto
  7. Gerenciamento/Gestão das comunicações do projeto
  8. Gerenciamento/Gestão de riscos do projeto
  9. Gerenciamento/Gestão de aquisições do projeto
  • Referências e Fontes

PROJECT MANAGEMENT INSTITUTE, Um Guia do Conhecimento em Gerenciamento de projetos, 4ª ed. 2008

http://pt.wikipedia.org/wiki/Project_Management_Body_of_Knowledge Acessado em: 02/10/2013

http://www.pmi.org/

ITIL v.3 – Sou desenvolvedor! O que me importa saber disso?

logo-itil

Opa! Mais um item dos meus estudos sobre alguns assuntos mais falados de TI.

ITIL v.3 (Information Technology Infrastructure Library)

O ITIL é uma metodologia de gerenciamento de processos de TI criada pela secretaria de comércio do governo ingles (Office of Government Commerce, OGC), a partir de pesquisas realizadas com consultores, especialistas e doutores para desenvolver as melhores práticas para gestão de TI. Foi desenvolvido no final dos anos 80  pela CCTA (Central Computer and Telecommunications Agency) hoje OGC (Office for Government Commerce) da Inglaterra.

O ITIL é composto por módulos. Os módulos mais importantes são: IT Service Support e IT Service Delivery.

O Service Support inclue Service Desk, Incidentes, Problemas, Configuração, Gerenciamento de mudança e Liberação. Já o Service Delivery inclue nível de serviço, financeiro, capacidade, continuidade e disponibilidade de serviço.

O ITIL define objetivos e atividades, entradas e saídas de cada um dos processos encontrados na organização de TI. Porém ITIL não dá recomendações de como as atividades devem ser executadas pois as empresas são diferentes;

 

  • Estrutura

Na versão v1, a ITIL era formada por uma grande quantidade de livros cada um descrevendo uma área específica de TI. Havia aproximadamente 40 livros relacionados ao gerenciamento de infraestrutura de TI. Já no ITIL v2, foi resumida em 7 livros principais.

A biblioteca atual do ITIL v3, é composta por:

  1. Conteúdo Principal: 5 publicações do ciclo de vida;
  2. Conteúdo complementar: guia introdutório, guia de bolso, guias complementares, com a aplicação da ITIL em cenários específicos, estudos de caso,  material para treinamento, artigos e serviços de suporte via web.

 

  • Estratégias de serviço

Pontos chaves da estratégia de serviço:

  1. Definição do valor do serviço;
  2. Ativos do serviço (service assets);
  3. Análise de mercado;
  4. Tipos de provimento de serviço.

Processos dessas estratégias incluem:

  1. Gerenciamento de Estratégia para Serviços de TI;
  2. Gerenciamento de Portifólio (ou carteira) de serviços;
  3. Gerenciamento financeiro de serviços de TI;
  4. Gerenciamento de demandas;
  5. Gerenciamento de relacionamento com o negócio.

 

  • Desenho de serviço.

O Desenho de serviço engloba todos os elementos relevantes a entrega de serviços de tecnologia, ao invés de focar somente no projeto de tecnologia propriamente dita.

Com ITIL o trabalho de projetar um serviço é agregado em um simples pacote de projeto de serviço (Service Design Package – SDP). O SDP em conjunto com outras informações, são gerenciados com um catálogo de serviços.

Processos Inclusos

  1. Gerenciamento de catálogo de serviços;
  2. Gerenciamento de fornecedores;
  3. Gerenciamento do nível de serviço (Service Level Management – SLM);
  4. Gerenciamento de disponibilidade;
  5. Gerenciamento de capacidade;
  6. Gerenciamento de continuidade de serviços de TI;
  7. Gerenciamento de segurança da informação;
  8. Coordenação do Desenho do Serviço.

 

  • Transição do serviço

A transição do serviço é composto por um conjunto de processos e atividades para a transição de serviços no ambiente de produção. Deve ser encarado como um projeto de implantação, pois neste estágio do ciclo de vida precisamos gerenciar bem os recursos para implantar com sucesso um novo serviço ou uma alteração em um existente.

Processos Inclusos

  1. Gerenciamento de configurações e ativos de serviço
  2. Planejamento de transição e suporte
  3. Gerenciamento de liberação e entrega (release and deployment)
  4. Gerenciamento de mudança (Change Management)
  5. Gerenciamento de conhecimento
  6. Papéis da equipe engajada na transição do serviço.

 

  • Operação do serviço

Aqui se coordena e se realiza as atividades e processos necessários para fornecer e gerenciar serviços em níveis acordados com o usuário e clientes do negócio.

Processos inclusos

  1. Balanceamento do conflito das metas (disponibilidade vs custo, etc).
  2. Gerenciamento de eventos.
  3. Gerenciamento de incidentes.
  4. Gerenciamento de problemas.
  5. Cumprimento dos pedidos.
  6. Gerenciamento de acesso, (service desk).

 

Aqui se fecha o ciclo de vida do ITIL.

ITIL Life Cycle_2

 

 

  • E o que isso tudo tem a ver comigo desenvolvedor de sistemas?

O desenvolvimento de sistemas é um serviço de TI, portanto também é gerenciado pelas práticas do ITIL. Percebe-se claramente principalmente no ciclo de transição do serviço, onde os sistemas utilizam as disciplinas de gerência da mudança, gerência da liberação e gerência da configuração. O objetivo dessas disciplinas é garantir que as implementações tenham o menor impacto possível em ambiente de produção, através de processos e checagens formais, mantendo o registro de todas as correções em base de dados.

Ou seja, se você é desenvolvedor, tenha pelo menos uma noção de ITIL, pois as empresas que implementarem tais práticas vão precisar da colaboração dos profissionais para tal.

  • Fontes e Referências

http://www.green.com.br/bloggov/2010/10/itilvscobit/ Acessado em: 02/10/2013

http://www.profissionaisdetecnologia.com.br/blog/?p=168 Acessado em: 02/10/2013

http://manageti.blogspot.com.br/2012/08/estrutura-da-itil.html Acessado em: 02/10/2013

http://pt.wikipedia.org/wiki/ITILv3 Acessado em: 02/10/2013

http://www.diegomacedo.com.br/itil-v3-transicao-de-servico-parte-1/ Acessado em: 02/10/2013

http://www.diegomacedo.com.br/itil-v3-operacao-de-servico-parte-1/ Acessado em: 02/10/2013

%d blogueiros gostam disto: