Vaga Analista-Desenvolvedor Pleno
Descrição da vaga: Para trabalhar com desenvolvimento java na criação de sites e
sistemas web.

Formação:
Superior em: Ciência da Computação / Sistemas de Informação e áreas
afins.

Conhecimentos requeridos:

• EJB 3, JPA, Hibernate
• Orientação a Ojetos
• Conhecer design patterns e suas aplicações (MVC, etc…)
• Desenvolvimento de aplicações web (JSP, Struts e JSF)

Conhecimentos desejáveis:

• Experiência em Oracle e MySQL
• Ter experiência com Liferay Portals
• Metodologias ágeis, como: Scrum, XP e Lean.
• Ter experiência no desenvolvimento de Portlets com JSF2
• Ter conhecimento em análise de sistemas
• Disponibilidade e vontade para aprender novas tecnologias.

Benefícios:

• Vale alimentação no valor de R$ 400,00 (mês)
• Plano de saúde – Unimed enfermaria/Nacional (sem desconto da
• mensalidade, paga somente a co-participação) não se estende para os dependentes
• Plano odontológico – Uniodonto
• Plano de previdência privada: após experiência 30,00 por mês (parte da empresa)
• Seguro de vida (sem nenhum desconto para o colaborador)
• Auxilio educação (obedecendo algumas regras da empresa)

Interessados enviar curriculum para: rh@portalunimed.com.br

Os mapas mentais, ou mind maps, em inglês, são usados há muito  tempo em tarefas relacionadas à gestão da informação e gestão estratégica de empresas. Devido à sua simplicidade e facilidade de uso, este modelo foi adotado de braços abertos pela comunidade digital.

Ele se encaixa perfeitamente ao mapeamento e planejamento de sites e blogs, desenvolvimento de softwares, acompanhamento de bugs, planejamento de layouts e definição de funcionalidades para  programas. Mapas mentais são ótimas alternativas na  fase de coletar dados, principalmente quando aplicada no planejamento de projetos. É uma ferramenta muito útil no processo de liberação de ideias, é o mapeamento da mente.

Constantemente nos deparamos com situações em que não conseguimos fazer com que nossos pensamentos se organizem de forma clara, organizada e útil. Tentamos realizar muitas coisas simultaneamente: gerar novas idéias, avaliar o seu mérito, e organizá-las.Na utilização do mapa mental, as ideias são capturadas em uma estrutura descontraída e informal. É fácil de modificar posteriormente a organização, as relações entre itens e enfatizar com base em sua importância e relevância.

Elaborado em forma de teia, onde o objetivo principal é colocado no centro como o ponto de partida,.as ideias são descritas apenas com palavras chaves e podem ser ilustradas com imagens, ícones e cores.

Sintetizam e sinalizam de forma visual os pontos chaves, é uma ferramenta poderosa de anotação de informações de forma não linear, como ocorre em um mapa de uma cidade elaborado para os turistas, onde todos os pontos de visitação estão destacados e ordenados para que se organizem e se localizem durante sua visita. Revelando como a cidade funciona no todo e como os pontos podem ser interligados entre si.

O layout visual fornece uma visão global, faz com que seja fácil de ver e compreender as relações entre os itens, por fim, com a utilização das figuras e cores, promove a memorização das informações ao estimular ambos hemisférios cerebrais.

O uso de mapas mentais não requer a capacidade de parar/pensar/organizar/avaliar. Dessa forma, pode-se focar totalmente a energia em ideias reveladoras.

Fontes:

http://www.stumbleupon.com/su/3GNzIR/www.innovationexcellence.com/blog/2012/03/15/uncork-your-brain-with-mind-maps/

http://www.idph.com.br/artigos/novaeducacao/mapasmentais.php

Assim como uma equipe de Scrum precisa de um Product Owner responsável e compromedito com o projeto, ela também irá precisar de um Scrum Master e um time tão comprometido quanto.

Neste post, vamos falar sobre a figura do Scrum Master, que é tão importante quanto o Product Owner em equipes ágeis que adotam o Scrum.

A minha intenção é focar nas caracteristicas necessárias para ser um bom Scrum Master, e não nas atribuições do seu papel.

Quem sabe abordamos os papéis do Scrum Master num post futuro.

Vamos lá…

Segundo Mike Cohn, ele define 6 caracteristicas necessárias para ser um bom Scrum Master, que são:

• Responsabilidade- O Scrum Master (SM) deve garantir a adoção do Scrum no seu time e seu uso por complento. Fica para ele a responsabilidade de cobrar e fiscalizar os processos de desenvolvimento.
  
• Humildade – O principal papel do Scrum Master é auxiliar o seu time a vencer os desafios de um processo de desenvolvimento, e em momento algum é papel dele centralizar o sucesso no progresso obtido pelo time que está liderando. Ele até pode se sentir orgulhoso dos resultados obtidos, mas deverá ser um sentido do tipo: “Olhem o que ajudei a construir”.
  
• Colaborativo - É importante o Scrum Master trabalhar de forma que haja sempre o espírito colaborativo entre os membros do seu time. A colaboração entre eles, irá ajudar a equalizar o conhecimento e facilitar o crescimento da equipe como um todo.
• Compromedito - Embora, nem sempre o Scrum Master possa focar seus esforços na gestão da equipe, ele deve sempre lembrar das metas que deverão ser alcançadas nas sprints. Deixar claro para o time qual é o “Goal”, a grande “Meta”, que foi definida pelo Product Owner, para que todos possam direcionar seus esforços para atingí-la.
• Influente - A influência geralmente se dar por meio natural diante do grupo, no qual geralmente a própria equipe já o elegeu para o papel por sua importância e influência sobre ela. Além do mais, uma pessoa que execute bem o papel do Scrum Master, poderá influenciar os outros a seguirem seu modelo de liderança e colaboração.
• Informado – Além de ser um profundo conhecedor do Scrum, será importante também ter uma boa bagagem técnica, de mercado ou ainda qualquer outra área que possa vir a ajudar o time a alcançar seu objetivo.

Segundo o Scrum Master Manifesto, que define:

1. Dedicar-se às entregas – Manter o foco na entrega da sprint é fundamental: Entregrar Software funcionando é a meta do time.
2. Fomentar a melhoria contínua – A base do ágil se sustenta neste item : Ciclo de Melhoria Contínua.
3. Apoiar a melhoria contínua - Apoiar a equipe a aprimorar sempre.
4. Delegar poder e agir como coach – Aqui um item interessante. Alguns podem achar que não faz sentindo algum, mas com certeza o Scrum Master é de certa forma um Coach para o time e para o processo.
5. Manter a equipe informada e motivada – Primordial.
6. Ser transparente e disponível para a equipe – Estar sempre disposto para tirar os impedimentos do time.
7. Ter compromisso com a excelência – Focar na qualidade do código e dos processos.
8. Atuar como guia e evangelizador – Novamente, o SM é a referência técnica para o time.
9. Ser dedicado e persistente – Nunca desistir dos desafios propostos em uma Sprint, que podem ser: Técnicos, Humano ou de Negócio.
10. Ajudar a equipe – Estar sempre disposto a colaborar.
11. Procurar conhecer antes de melhorar – Manter-se sempre informado é a meta do SM.
12. Atuar como força motriz do Agile – Usar de técnicas de Coaching para equalizar o conhecimento ágil entre os membros do time, e porque não da empresa.

Era isso pessoal, até o próximo post!!!

Fonte:

Mike Cohn – Desenvolvimento de Software com Scrum, Bookman
infoQ – www.infoq.com

Vaga de Analista Desenvolvedor Júnior

Desenvolvimento JAVA na criação sistemas web.

Área de Atuação
Área de TI – Suporte de sistemas (Corretivas e melhorias nos sistemas implantados)

Formação
Superior ou em andamento em: Ciência da Computação / Sistemas de Informação e áreas afins.

Conhecimentos requeridos

• Orientação a objetos
• Desenvolvimento de aplicações web (JSP, Struts)
• CSS

Conhecimentos desejáveis

• Oracle e MySQL
• EJB 3, JPA, Hibernate
• Conhecer framerowks
• Ter conhecimento em análise de sistemas (requisitos, documentações)
• Conhecer design patterns e suas aplicações (MVC, etc…)

Benefícios

• Vale alimentação
• Plano de saúde
• Plano odontológico
• Plano de previdência privada
• Seguro de vida
• Auxilio educação

Interessados enviar currículo para rh@portalunimed.com.br até 06/03.

Em muitas empresas que adotam o desenvolvimento ágil, o Product Owner é  reposnsável por manter a visão dos produtos, dos sistemas e de aplicações que estejam sob sua responsabilidade, ou área.

É de responsabilidade do product owner os seguintes itens:

• Manter a visão atualizada, como já dissemos;
• Promover a visão junto ao time;
• Responsável pelos requisitos e documentações;
• Participar das cerimônias de entregas;
• Participar do planejamento das iterações representando o cliente;

…

Geralmente os questionamentos ligados a visão do produto/projeto, que um Product Owner bem treinado deveria fazer são:

• Qual problema este produto/projeto resolve para o meu cliente?
• Quais as funções e benefícios a solução agregaria ao meu cliente ?
• Para quem é esta solução ?
• Que performance, segurança, escalabilidade e outras coisas, preciso entregar para o meu cliente ?
• Quais plataformas, padrões, aplicações e etc, terá que suportar?

“O resultado da reunião para criar a visão será uma lista de funcionalidades, com uma breve descrição do cenário.”

A visão poderá ser mantida em um documento, no qual descreva de forma clara e sucinta, descrevendo o seu valor para o usuário. Poderá ser um documento formal, ou uma lista de requisitos.

Ainda no documento de visão, deveríamos incluir os requisitos não funcionais, no qual incluem:  segurança, performance, qualidade, compatibilidade, entre outros itens que serão necessários para construir o sistema.

Você pode se perguntar: Preciso de todas essas informações no documento de visão ? Nãoo seria mais fácil chamar esse documento de Documento de Escopo do Projeto ?

R: O importante é você ter um documento com as informações que serão necessários para começar o projeto, o nome ou a forma como você irá formalizar essas informações, ao meu ver tanto faz, desde que você as tenha de forma clara e objetiva.

Elas serão úteis mais para frente, principalmente para decomposição da deste documento ou visão, como chamamos.

Como pode se observar, um documento de visão, é muito similar ao documento de escopo de projeto, no qual o PMBOK  adota, onde você tem uma breve descrição do projeto, os requisitos, funcionais e não funcionais e toda e qualquer informação que seja relevante ao projeto.

Calma, sei que essa declaração  é um pouco estranha e vai de contra a muitos pensamentos agilistas, mas francamente, não sejamos puritanos. Qual o problema de montar um documento bem elaborado, que será crucial para ajudar a decompor a visão de forma mais segura?  Claro que não precisamos seguir o modelo do PMBOK, mas é importantes termos bem claros quais são os objetivos do projeto, e francamente o modelo sugerido pelo PMBOK casa bem com determinados projetos.

No próximo post, vamos abordar uma forma de decompor esta visão.

Hi, in this post I’ll write about the confusion that many agile teams are doing about the role of Customers and Product Owners. I hope that you enjoy.

Let’s to the work…

In the Agile Development we see the Customer role are the principle business owner. Well, and where stays the Product Owner role ?

As you can see, this roles cause confusion in agile teams beginners, because it is difficult to distinguish to what extent do each role.

Therefore, I’ll try to show the main differences between the role of Customer and Product Owner role.

Below is a brief description of the differences:

The Customer (in site) Role:

1. Focus on the vision of the product
2. Helps the team to build the product vision
3. Participates in frequent deliveries

and more…

The Product Owner:

1. Maintain the vision of the product
2. Promote the vision
3. Responsible of the requisites and documents
4. Participates in frequent deliveries with their ideas
5. They can be a Product Manager

and more…

Well, As you can see the papers often seem confusing, but in their essence they are totally different.

Ouvi  em eventos de TI, principalmente em palestras de agilistas e em conversas de corredor, que Engenharia de Software é algo inatingível no desenvolvimento de software, pois construir um software é algo muito diferente de construir um prédio, por exemplo.

Levando a frase ao pé da letra, obviamente, é um pensamento coerente, porém o que é engenharia de software?  É burocracia?

Uma simples pesquisa no google e conseguimos diversos conceitos que pouco ajudam. Cada autor tem uma definição, uma linha de raciocínio e isso ainda é muito abstrato.

Há algum tempo, na pós-graduação (de Engenharia de Software), um professor relembrou o conceito do Pressman:

Engenharia de Software é uma tecnologia em camadas (processos,  métodos e ferramentas).

Isso ainda não diz muita coisa, porém um modelo, figura e um exemplo prático nos ajudam a consolidar os conceitos, então trago a imagem da nossa realidade aqui no Portal Unimed.

Destaco que nossos processos e técnicas são baseados em metodologias ágeis e não burocratizam nem um pouco nosso desenvolvimento. Ao contrário, ajudam a definir e a manter um ambiente de autocontrole, onde todos os envolvidos têm total consciência de todo processo.

Se na sua empresa você tem um processo definido, segue algum modelo de maturidade (ou alguma prática ágil), utiliza ferramentas de desenvolvimento e busca a qualidade de software, você utiliza a Engenharia de Software, pode acreditar, mesmo que não queira.

Então, aproveite para otimizar os processos, ferramentas e técnicas e manter o ciclo de melhoria contínua.

Neste post eu trago a minha visão do que acredito ser importante para se tornar um Product Owner mais efetivo.

Você poderá ver o post na integra, no qual detalhe 7 características que considero importante, abaixo você poderá ver um resumo do post:

Para se tornar um bom P.O. eu diria que a pessoa teria que ter a grande habilidade de lidar muito bem com as pessoas e com os requisitos de software. Também ser organizado, pois organizar backlog é uma tarefa muitas vezes dificil e que requer muita atenção do P.O.

E para finalizar: “Ouça sempre o que o seu time tem a dizer, análise as informações que chegam, e só depois tome alguma decisão. Não tenha medo de se envolver com os demais pápeis do Scrum, o quanto mais o P.O. se envolver no processo de desenvolvimento do projeto, mais ficará ciente do andamento da equipe e de suas dificuldades, participe das Dailys e retrospectivas sempre que puder.”

Gostou ? então clique aqui e veja na integra.

Apresentação realizada no TDC 2011, em Florianópolis, na trilha Agile por Alexandre Rosa, Everton Lentez e Guilherme Pinter.

É notável que a F.D.D. (Feature Driven-Development) é uma das metodologias ageis que mais se aproxima do modelo tradicional, pois concentra uma boa parte da sua energia em etapas de planejamento, onde muitas outras não possuem um foco tão explicito. A idéia é mostrar a todos, como esta metodologia proporciona uma adaptação mais suave dos modelos tradicionais aos modelos agilistas.

ITIL (Information Technology Infrastructure Library) é uma biblioteca de melhores práticas em TI, relacionadas a infraestrutura, operação e serviços em geral.

Utilizando o ITIL buscamos promover a gestão com foco no cliente e na qualidade dos serviços, por meio de um modelo baseado em processos, convergindo os recursos de TI e o negócio da empresa. Desta forma a organização tende a mudar a forma de se relacionar internamente, devido a introdução de métricas, preocupação com melhoria, transparência e qualidade.

É composto por processos que agrupam as boas práticas em áreas comuns. Desta forma está divido nas áreas descritas abaixo:

• Suporte a serviços: descreve processos de suporte utilizados no dia a dia e atividades de provisão dos Serviços de TI.
• Entrega de serviços: Cobre os processos de planejamento e entrega de Serviços em TI com qualidade, bem como o aperfeiçoamento dessa qualidade ao passar do tempo.
• Gerenciamento da Infra-estrutura: Cobre requisitos como negócio, testes, instalação, entrega e otimização das operações normais de infra.
• Planejamento para Implementação do Gerenciamento de Serviços: Foca em questões de planejamento, implementação e aperfeiçoamento dos processos do Gerenciamento de Serviços em TI.
• Gerenciamento de aplicações: Descreve como gerenciar as aplicações a partir das necessidades dos negócios.
• Perspectiva do negócio: Guia para como contribuir para o negócio da empresa.
• Gerenciamento da segurança: Planejamento e gerenciamento da segurança da informação e Serviços de TI.

Cada uma das áreas possui um livro específico, com todas as práticas recomendadas.

Como exemplo podemos detalhar o gerenciamento de serviços, que possui 2 livros, Suporte a Serviços e Entrega de Serviços. Estes agrupam os processos como segue abaixo:

Suporte a Serviços:

• Central de Serviços (Função)
• Gerenciamento de Incidentes
• Gerenciamento de Problemas
• Gerenciamento da Configuração
• Gerenciamento de Mudanças
• Gerenciamento de Liberação

Entrega de serviços:

• Gerenciamento do Nível de Serviços
• Gerenciamento Financeiro para Serviços em TI
• Gerenciamento da Capacidade
• Gerenciamento da Disponibilidade
• Gerenciamento da Continuidade dos Serviços em TI
• Gerenciamento da Segurança (com referência ao livro Gerenciamento da Segurança)

Muitas empresas de TI fornecem serviços aos seus clientes por meio da implantação de diversos sistemas, devendo assim gerenciar as versões liberadas, as mudanças, configurações e a liberação dos serviços.

As empresas tendem a coordenar todas estas práticas muitas vezes por processos mapeados internamente, que até funcionam, mas que poderiam ser melhorados e otimizados com o foco em boas práticas consolidadas pelo ITIL.

Dentre algumas práticas temos o ambiente de aceite (Acceptance Environment), conhecido popularmente como ambiente de homologação, adotado por muitas empresas.

A ITIL recomenda o uso deste ambiente antes da implantação dos sistemas em produção, e antes da liberação de manutenções e atualizações.

Muitas empresas adotam este ambiente, mas esquecem de alguns detalhes previstos entre as boas práticas como:

- O ambiente de homologação deve ser igual ao de produção, isto para evitar inconsistências em testes, devido ao comportamento diferente entre os ambientes.

- Evitar deploys constantes em produção.

- O cliente deve testar as aplicações em homologação parar posterior implantação.

- A equipe de desenvolvimento e implantação deve evitar deploys constantes antes dos testes e aprovação dos clientes.

Com estas praticas os custos de correções em produção, as falhas em sistemas críticos, a queda do nível de serviço – SLA, entre outros problemas, tendem a diminuir, e é isto um dos principais focos do ITIL.

Procurei abordar de forma breve o ITIL, trazendo o assunto para o dia à dia do profissional de TI, focando na liberação de serviços por meio de uma boa prática, o ambiente de aceite.

Em breve pretendo trazer outras práticas do ITIL.