Published on EMPREL 43 ANOS (http://antigoemprel.emprel.gov.br)

Início > Áreas > DNC

By admin
Created 20/09/2010 - 18:00

DSI - Diretoria de Soluções em Tecnologia da Informação

Página inicial da DSI - Diretoria de Soluções em Tecnologia da Informação.

 

Missão da DSI:

Propor, normatizar, desenvolver, implementar e manter soluções em Tecnologia da Informação e Comunicação - TIC, observando a metodologia de desenvolvimento de sistemas adotada na EMPREL, o acordo de nível de serviço (ANS), com foco no atendimento às necessidades de seus usuários.

Visão de Futuro da DSI:

Ser reconhecida como área de referência, na EMPREL, para a proposição e gerenciamento de soluções em Tecnologia da Informação e Comunicação - TIC, no âmbito da Prefeitura da Cidade do Recife - PCR.

Avanços Importantes e Notícias

Esta seção apresentará os avanços importantes e as notícias de interesse da DNC.
 

Agradecimento

Agradeço em nome da Emprel ao esforço e dedicação do colega Henrique, valeu!!!! Muito boa sorte na nova jornada e sentiremos muito a sua falta!!!

Capacitações a vista!!!

Estamos na fase final de cotações para a contratação de capacitações para o levantamento de requisitos e scrum. Ambos com foco no novo processo de desenvolvimento de sistemas. Além destas contratações, caminhamos com um acordo de cooperação com Serpro, ATI e Exército Brasileiro e, por meio deste instrumento, estamos bucando viabilizar a apresentação da metodologia e framework de desenvolvimento Ágil do Serpro.  Para futuro, a disciplina de Teste de Sistemas está em nossa meta!!! Teríamos alguém com conhecimento interno que se dispusesse a abordar o tema?

Faz sentido medir indivíduos num time Ágil?

A resposta para a pergunta feita no título do artigo – segundo a minha opinião – é não. Claro que não !

Antes de discutirmos o porque dessa afirmação, acho importante estudarmos as origens das atuais medições individuais aplicadas pelos níveis gerenciais nos times de desenvolvimento de software.

Há muitos e muitos anos atrás eu já trabalhei em fábrica – uma de verdade, era de móveis de escritório :) – e lá era responsável por um setor de produção, o de corte de madeira. Era a primeira etapa da linha de produção. Além de liderar este setor e operar a máquina mais cara da empresa, eu fazia parte da equipe de PCP (Planejamento e Controle de Produção) da companhia.

Porque estou citando isso? Porque lá eu vivi de perto a implantação de um processo de linha de produção e de medição x análise da cadeia produtiva. É claro, que nossa indústria de desenvolvimento de software, quando decidiu aplicar os conceitos de fábrica de software tinha que trazer também vários dos processos de medição, análise e avaliação de desempenho utilizados na indústria convencional.

Funcionava mais ou menos assim:

  1. As peças saiam em lote de uma máquina (por exemplo a minha) e iam para uma área de pulmão até que aquele lote fosse pego pela equipe da próxima máquina;
  2. O tempo que um lote ficava parado no pulmão, era medido;
  3. Assim que os operários da próxima máquina registravam a entrada do lote o tempo começava a contar e na liberação do lote tínhamos o tempo gasto nas peças;
  4. Sempre que aconteciam paradas ou problemas (como a regulagem mal-feita de um centro de usinagem, por ex.), eram registradas as ocorrências pelo supervisor de linha;
  5. Esse fluxo era executado para cada máquina da linha de montagem. Se não me falha a memória tínhamos cerca de 8 etapas na linha;”

Ora, este processo funcionava e ao final conseguíamos ter números importantes para melhorar nosso planejamento e controle da produção, como:

  • Tempo médio para produção de um lote, para cada modelo de móvel que fabricávamos;
  • Tempo médio para regulagem de cada máquina da linha, em cada turno de trabalho;
  • Tempo médio de fabricação em cada etapa da linha;
  • Ocorrências de manutenção, erros e outros pontos que paravam ou atrasavam a produção;
  • Número de horas necessárias para fabricação de cada modelo, em cada etapa e em cada turno da fábrica;
  • Finalmente, o valor gasto na produção de cada modelo, baseado é claro no número de horas e atividades gastas pelos operários;

Você percebe algumas semelhanças com indicadores de medição individuais que temos hoje em nosso mercado? Na indústria não eram medidos os times ou então a média do trabalho. Para se chegar aos números médios era necessário medir individualmente. Muitas vezes, não importava se o operário conseguia fazer uma peça de qualidade no tempo viável para entrega de um lote. Importava mais se ele estava dentro do tempo médio da produção. Já vi inclusive esses indicadores serem utilizados para demitir gente que não estava dentro da média !

Para a indústria convencional e suas linhas de produção, essa abordagem funciona de fato. Faz muito sentido esse tipo de medição e indicadores de produção. Infelizmente não é a mesma coisa para desenvolvimento de software. Os indicadores e a forma como eles são captados devem seguir outra abordagem.

Acabamos por implantar esse mesmo modelo de medições e análise e avaliações pessoais utilizado na indústria convencional e empurrando-o a força no desenvolvimento de software. O que utilizamos hoje nada mais é do que uma tentativa de medir a “produtividade” das pessoas num ambiente de desenvolvimento. Neste sentido, eu não acredito que medições individuais devam fazer parte de uma equipe ágil.

Tanto as medições individuais quanto os modelos de premiação / punição devem ser coletivos. Acho que este é um dos pontos positivos de se trabalhar num ambiente ágil.

Quais então são indicadores que fazem sentido numa equipe que trabalha sob cultura ágil? Vamos ver alguns:

  1. Quantidade média de horas/pontos que o time atinge numa iteração;
  2. Taxa de velocidade na implementação;
  3. Número geral de erros entregues;
  4. Metas alcançadas em cada iteração;
  5. Satisfação do cliente /product owner (isso pode ser feito com uma pesquisa, por ex.);

Notem que estamos medindo indicadores do mesmo jeito, só que de uma forma mais superficial. Em resumo, não interessa o que cada um esteja fazendo de forma separada e sim o que o time conseguiu fazer de fato.

Então, você pode me perguntar: ” Mas isso vai deixar as pessoas acomodadas, pois ninguém estará medindo ou gerenciando o seu trabalho? “. Temos que fugir ao máximo do micro-gerenciamento e da ilusão do comando-controle se quisermos alcançar o objetivo de um time auto-gerenciável. O Scrum mesmo nos oferece alguns mecanismos para “medir” individualmente o desempenho de cada membro do time:

  • Reuniões diárias;
  • Sprints Reviews;
  • Sprints Retrospectives;

E quanto a avaliação de desempenho individual, muitas vezes utilizada pelas empresas para aplicação de promoções de cargos e salários, também há outros mecanismos que podem ser aplicados. Pessoalmente eu nunca concordei com o formato  de avaliação de desempenho utilizado pelo mercado. Como podemos medir o desempenho isolado de uma pessoa se ela depende de outras para realizar o seu trabalho?

Esse sistema individual que temos hoje é responsável por promoções descabidas e por muitas vezes entregar o valor do trabalho de muitos para apenas uma pessoa. Então, se você ainda quer utilizar um modelo de avaliação, mas quer começar a pensar em como deixa-lo mais aderente a cultura ágil, faça o seguinte:

  • Utilize os indicadores globais das equipes e projetos onde o profissional participou. Não é difícil traçar uma linha de atuação com essa abordagem;
  • Para medir individualmente, nada melhor do que a velha “avaliação 360″. Neste modelo o profissional é avaliado por pessoas que trabalham com ele no dia-a-dia. Pessoalmente, acredito que essa seja uma das melhores formas de se avaliar alguém, principalmente os gestores.

O que falei foi apenas sobre indicadores de performance para profissionais / times. Ainda existem muitas outras formas de se avaliar e medir os projetos. São abordagens diferentes, medidas de forma diferente e que apresentam números diferentes, ok?

Métricas e indicadores são muito importantes, principalmente para empresas de serviços de software ou “fábricas de software”. Os clientes exigem esses números e a alta cúpula de executivos precisam disso para basear suas decisões. Agora, não dá para falar de cultura ágil e continuar medindo as pessoas da mesma forma que fazemos na indústria convencional.

Existem muitas empresas que medem tantos indicadores quanto possível e geram relatórios e books de gestão de centenas de páginas. Tudo desperdício, porque ninguém consegue analisar aquilo para tomar uma decisão na hora necessário. Os números devem ser os mais simples e diretos possíveis para possibilitar ao executivo ou mesmo ao time a tomada de decisões em tempo hábil. Para completar, indicador bom é aquele que reflete a cultura que está sendo aplicada pela empresa no projeto.

Grande abraço

André Nascimento

Araç Giydirme [1] adı üstünde araçların üzerine yapılan reklam uygulamasıdır. Araç Giydirme [1] kelimesi halk arasında Araç Üstü Reklam veya Araba Giydirme olarakta kullanılır. Araç Giydirme [1]; Cast Folyo diye isimlendirilen yapışkanlı PVC ile yapılır. Bu yapışkanlı PVC Cast Folyo’nun kalınlığı 0.11 – 0.13mm. aralığındadır. Cast Folyo’nun çok ince olmasının sebebi;

Araç Giydirme [1] işlemi yapılırken, Aracın cam kanallarının içine ve oluklara rahatça esneterek yapışması içindir. Bu işlem profesyonel Araç Giydirme [1] Ustaları tarafından yapılmalıdır.

Grupo de trabalho - PRAE

Metodologia e Produtividade precisam se aliar, desenvolvimento rápido e com qualidade precisa de método, mas é fundamental uma arquitetura de software que facilite o trabalho dos desenvolvedores. Este grupo tem a difícil missão de iniciar uma padronização de ferramentas, grande sonho para aqueles que ao trocarem de projetos se deparam com uma arquitetura completamente diferente e o dano inevitável à Produtividade! Padronizar é a meta, definir os passos até lá é a tarefas destes colegas.

Grupo de trabalho - PRME

Criado Grupo de Trabalho para revisão da MEDS. O projeto está sendo gerenciado pelo Redmine e tem o acompanhamento da DNC. Realizadas as primeiras reuniões o Grupo optou pela montagem de uma metodologia baseada no desenvolvimento ágil de sistemas, denominada  Ágil MEDS, que deverá ter suas bases definidas em 30 dias (final de setembro/2010). Após as definições macros, iniciaremos dois pilotos com a nova metodologia, sendo um de manutenção e outro de criação. Estes pilotos nos permitirão avaliar e corrigir os problemas encontrados para a posterior disseminação para outros projetos. Outro fato importante!!!! os pilotos serão projetos que a Emprel realmente estará entregando aos seus clientes.

Grupos de trabalho publicam andamento das atividades

Todos os desenvolvedores da DNC devem acompanhar os trabalhos de revisão de MEDS e da ARDS. Visite o site dos projetos PRAE e PRME no Redmine!!! caso não tenha acesso, procure Petrônio e conheça o que estamos pensando para o futuro destas importantes ferramentas de trabalho. PARTICIPE !!!

Araç Giydirme [1] adı üstünde araçların üzerine yapılan reklam uygulamasıdır. Araç Giydirme [1] kelimesi halk arasında Araç Üstü Reklam veya Araba Giydirme olarakta kullanılır. Araç Giydirme [1]; Cast Folyo diye isimlendirilen yapışkanlı PVC ile yapılır. Bu yapışkanlı PVC Cast Folyo’nun kalınlığı 0.11 – 0.13mm. aralığındadır. Cast Folyo’nun çok ince olmasının sebebi;

Araç Giydirme [1] işlemi yapılırken, Aracın cam kanallarının içine ve oluklara rahatça esneterek yapışması içindir. Bu işlem profesyonel Araç Giydirme [1] Ustaları tarafından yapılmalıdır.

Mais material para leitura!!!

A Emprel disponibilizará revistas técnicas para a DNC!!!! estaremos providenciando assinaturas e definindo como nossos técnicos terão acesso a mais esta possibilidade de se atualizar nas mais novas tecnologias de desenvolvimento de sistemas!!!!

O seu Scrum está funcionando?

Publicado por: Diego Cox

Descubra o que está dando certo e o que deve ser aprimorado no processo do Scrum dentro da sua corporação

Voltando a falar um pouco de Scrum, encontei uma checklist completa para você verificar como anda o processo dentro da sua empresa.

Sempre vale a pena avaliar quais os pontos estão funcionando bem e quais devem ser aprimorados.

O Scrum é uma metodologia iterativa que deve ser implementada aos poucos para evitar choques culturais, mas é importante chegar rapidamente a um ponto de maturidade para o processo não sofrer uma involução e começar a andar para trás.

Check Rápido

Preenchendo os requisitos abaixo, não é necessário preencher o resto do teste, o Scrum está mostrando os resultados esperados dentro da sua empresa.

( ) Entregando software funcional e testado a cada 2-4 semanas

( ) Entregando as funcionalidades de maior valor para o negócio

( ) O processo está em constante evolução

Check Completo

Caracteristicas fundamentais do Scrum, caso elas não estejam implementadas e funcionais não é possível garantir que o Scrum esteja funcionando da forma correta

( ) A função do Product Owner (PO) está claramente definida

  • ( ) O PO está priorizando as demandas coerentemente
  • ( ) O PO tem o conhecimento claro das prioridades do cliente
  • ( ) O PO tem contato direto com o time
  • ( ) O PO tem contato direto com os steakholders
  • ( ) O PO escreve histórias claras

( ) O time possui um Sprint Backlog

  • ( ) Claramente Visível
  • ( ) Atualizado diariamente
  • ( ) Administrado exclusivamente pelo time

( ) Daily Meeting acontecendo diariamente

  • ( ) O time todo participa
  • ( ) Problemas e impedimentos são revelados e resolvidos

( ) Demonstração de funcionalidades nos Reviews

  • ( ) O time demonstra software funcionando e testado
  • ( ) Feedback do PO para o time

( ) Possui a definição de feito

  • ( ) A definição de feito é revista a cada iteração
  • ( ) O time respeita a definição de feito

( ) A Retrospectiva é feita ao final de cada Sprint

  • ( ) Resultados concretos nas melhorias propostas
  • ( ) Algumas propostas já foram implementadas
  • ( ) Participação de todo o time + PO

( ) O PO possui um Backlog do Produto (Product Backlog)

  • ( ) dois ou três sprints pré priorizados a partir do valor de negócio
  • ( ) dois ou três sprints com as complexidades estimadas
  • ( ) As estimativas são feitas pelo time
  • ( ) Os itens Top cabem em um sprint
  • ( ) O PO entende todas as histórias do backlog

( ) Reuniões de Sprint Planning

  • ( ) O PO participa
  • ( ) O PO define a data fim do sprint
  • ( ) Todo time participa
  • ( ) O Sprint Backlog sempre é definido
  • ( ) O time acredita no backlog comprometido
  • ( ) O PO fica satisfeito com o comprometido

( ) Iterações “Time-Boxed”

  • ( ) Os sprints demoram no máximo 4 semanas e no mínimo 2 semanas
  • ( ) O sprint sempre termina na data estipulada
  • ( ) O time não perde o foco nem é afetado por acontecimentos ou demandas externas
  • ( ) O time sempre entrega o que foi comprometido
  • ( ) Raramente um Sprint é cancelado e reiniciado

( ) O time trabalha – fisicamente – junto

  • ( ) O time tem no máximo 9 e no mínimo 5 membros

Check Adicional

Algum pontos não obrigatórios, mas recomendados para o bom funcionamento do Scrum.

( ) O time tem as especialidades necessárias para finalizar os itens do backlog

( ) Os membros dos times não estão limitados a especialidades específicas

( ) O PO tem a visão do produto em sintonia com o Backlog do produto

( ) O Backlog e a Visão do produto estão claramente visíveis

( ) Todos no time participam das estimativas

( ) O PO está sempre disponível durante as estimativas

( ) A estimativa do grau de complexidade são definidos pelo time

( ) Todo o time tem conhecimento dos três principais impedimentos

  • ( ) O Scrum Master (SM) tem estratégias para resolver os principais impedimentos
  • ( ) O foco principal do SM é resolver impedimentos
  • ( ) Os impedimentos são escalados para a gerência quando não resolvidos

( ) O time tem um Scrum Master (SM)

  • ( ) O SM trabalha – fisicamente – perto do seu time

( ) Histórias do Backlog são quebradas em tarefas quando entram no Sprint

  • ( ) As tarefas são estimadas
  • ( ) As tarefas são atualizadas e acompanhadas diariamente

( ) A velocidade está sendo mensurada (número de pontos por Sprint)

  • ( ) As histórias priorizadas no Sprint Planning já estão estimadas
  • ( ) O PO utiliza a velocidade mensurada para planejar entregas
  • ( ) A velocidade mensurada inclui apenas histórias feitas

( ) O time tem um gráfico burndown

  • ( ) Visível a todos
  • ( ) Atualizado diariamente

( ) O Daily meeting é feito diariamente, no mesmo horário e local

  • ( ) O PO sempre participa
  • ( ) O tempo máximo de duração é de 15 minutos
  • ( ) Todo o time participa
  • ( ) Todos dizem o que fizeram
  • ( ) Todos dizem o que irão fazer
  • ( ) Todos dizem o que está impedindo

Expandindo o Scrum para toda a empresa

Algun intens importantes para empresas que trabalham com mais de um time, PO e SM

( ) Existe um Product Developer ( para empresas com vários PO’s)

( ) Times dependentes realizam o Scrum of Scrum

( ) Times dependentes participam do Sprint Planning de outros times

Indicadores de Sucesso

( ) Todos os envolvidos estão satisfeitos com a metodologia

( ) Todos os envolvidos estão satisfeitos com os resultados

( ) Horas extras são raras e voluntárias

( ) O processo está gerando discussões, críticas e novos experimentos

O teste proposto não tem pontuação – é uma checklist -, quantos mais itens estiverem implementados, mais o Scrum estará funcionando dentro da sua corporação, esse check deve ser feito periodicamente e os itens que não estiverem implementados devem ser revisto com atenção. O check original foi publicado aqui [2], eu apenas traduzi e inclui alguns itens que considero importante para o sucesso do processo.

 

Ponto para João Tiago!!!

Uma das necessidades básicas no desenvolvimento rápido de sistemas é o processo de integração contínua. Em nossas reuniões técnicas com a equipe de metodologia, sempre falamos desta como sendo uma das prioridades para a DNC no novo processo de desenvolvimento de software. Nosso colega João Tiago instalou o Hudson (http://hudson-ci.org/ [3]) e já temos um servidor de integração contínua funcionando!!!! Parabéns João, certamente com este passo, somado à migração do CVS para SVN, teremos projetos muito mais avançados e compatíveis com as melhores práticas de desenvolvimento de sistemas. Com certeza João nos apresentará este avanço com mais detalhes no próximo Café Tecnológico, abordando até que ponto este servidor atenderá às nossas necessidades futuras. Preparar a infraestrutura para o novo processo de desenvolvimento é fundamental!!!  Parabéns!!!

Reunião de final de Sprint

Realizamos, com título de Café Tecnológico, uma das reuniões previstas no modelo ágil de desenvolvimento de sistemas. A avaliação foi positiva e incorporaremos esta atividade aos nossos projetos.

Araç Giydirme [1] adı üstünde araçların üzerine yapılan reklam uygulamasıdır. Araç Giydirme [1] kelimesi halk arasında Araç Üstü Reklam veya Araba Giydirme olarakta kullanılır. Araç Giydirme [1]; Cast Folyo diye isimlendirilen yapışkanlı PVC ile yapılır. Bu yapışkanlı PVC Cast Folyo’nun kalınlığı 0.11 – 0.13mm. aralığındadır. Cast Folyo’nun çok ince olmasının sebebi;

Araç Giydirme [1] işlemi yapılırken, Aracın cam kanallarının içine ve oluklara rahatça esneterek yapışması içindir. Bu işlem profesyonel Araç Giydirme [1] Ustaları tarafından yapılmalıdır.

Vamos iniciar a migração do CVS para o SVN

A atualização do gerenciador de versões dos sistemas é o primeiro passo para a revisão das tecnologias utilizadas pela DNC. Este processo nos possibilitará uma utilização mais facilitada das ferramentas mais modernas de desenvolvimento, permitindo dar mais um passo na mesma direção de projetos como o RedMine, integração contínua, Maven e outras que batem à nossa porta! 

Desenvolver Software - nosso maior desafio!

Como podemos melhorar nosso processo de desenvolvimento? Precisamos apresentar novos e melhores sistemas para a Administração Municipal e, neste sentido, estamos com duas iniciativas em curso que darão um novo formato ao processo de desevolvimento na Emprel. Apoiados nos princípios do manifesto ágil (http://www.manifestoagil.com.br/ [4]) criamos dois grupos de trabalho. O primeiro será responsável pela proposição de uma nova metodologia de desenvolvimento e o segundo tratará da arquitetura de software necessária para abrigar o novo processo com a maior produtividade possível. Os dois projetos estão sendo gerenciados por mim e Adilson e todas as informações estão sendo atualizadas no Redmine, estando acessível a todos os desenvovedores que desejarem. Neste site estaremos atualizando as infomações mais relevantes e postando o progresso e as diiculdades que venhamos a encontrar nesta caminhada. A contribuição de todos é bem vinda... e o grande desafio é trazer os nossos usuários para dentro do processo!!!
 

Seu Comprometimento é fundamental !!!

Araç Giydirme [1] adı üstünde araçların üzerine yapılan reklam uygulamasıdır. Araç Giydirme [1] kelimesi halk arasında Araç Üstü Reklam veya Araba Giydirme olarakta kullanılır. Araç Giydirme [1]; Cast Folyo diye isimlendirilen yapışkanlı PVC ile yapılır. Bu yapışkanlı PVC Cast Folyo’nun kalınlığı 0.11 – 0.13mm. aralığındadır. Cast Folyo’nun çok ince olmasının sebebi;

Araç Giydirme [1] işlemi yapılırken, Aracın cam kanallarının içine ve oluklara rahatça esneterek yapışması içindir. Bu işlem profesyonel Araç Giydirme [1] Ustaları tarafından yapılmalıdır.

Documentos que estamos lendo

Seguem os documentos para download:

es_final_19.pdf [5] Scrum - Um modelo ágil para Gestão de projetos de Software 579k versão 1 06/09/2010 22:11 Emprel DNC
Metodologias Ageis.pdf [6] Análise das metodologias ágeis 139k versão 2 31/08/2010 09:34 Emprel DNC
ScrumeXPdiretodasTrincheiras.pdf [7] Livro prático de Scrum 3259k versão 2 31/08/2010 09:16 Emprel DNC
scrum-na-globocom-derrubando-mitos-falandoemagile2008-.pdf [8] A experiência na Globo.com 1940k versão 2 31/08/2010 09:38 Emprel DNC

 

2013.12.13 Presidente apresenta realizações 2013 e a nova Logomarca da Emprel

2013.11.19_Emprel participa do curso da W3C em Recife

Vídeo Apresentações

Seguem os vídeos para download:

Quadro_do_Scrum_(HQ).mp4 [9] Montagem do quadro do Scrum 12132k versão 1 31/08/2010 09:58 Emprel DNC
Scrum_Curso_Completo_(HQ).mp4 [10]   6500k versão 1 31/08/2010 11:56 Emprel DNC
scrum_em_menos_de_10_minutos_(revisado)_(HQ).mp4 [11] Conceitos básicos de Scrum 14888k versão 1 31/08/2010 12:23 Emprel DNC

 

Elaborado com Drupal
Desenvolvido pela

  Rua Vinte e Um de Abril, 3.370, Torrões, Recife-PE, CEP: 50.761-350 - PABX: (81) 3355.7000

 
Source URL: http://antigoemprel.emprel.gov.br/emprel/areas/dnc

Links:
[1] http://www.besdijital.com
[2] http://www.crisp.se/scrum/checklist
[3] http://hudson-ci.org/
[4] http://www.manifestoagil.com.br/
[5] http://antigoemprel.emprel.gov.br/files/es_final_19.pdf
[6] http://antigoemprel.emprel.gov.br/files/Metodologias Ageis.pdf
[7] http://antigoemprel.emprel.gov.br/files/ScrumeXPdiretodasTrincheiras.pdf
[8] http://antigoemprel.emprel.gov.br/files/scrum-na-globocom-derrubando-mitos-falandoemagile2008-.pdf
[9] http://antigoemprel.emprel.gov.br/files/Quadro_do_Scrum_(HQ).mp4
[10] http://antigoemprel.emprel.gov.br/files/Scrum_Curso_Completo_(HQ).mp4
[11] http://antigoemprel.emprel.gov.br/../../../../files/scrum_em_menos_de_10_minutos_%28revisado%29_%28HQ%29.mp4