i9Web - Consultoria em TI

Os 6 mandamentos para você organizar o seu tempo

2012-02-07T22:08:00.003-03:00

Gerir o tempo é algo útil para qualquer pessoa. Como todos sabem, é o recurso comum que temos que não é renovável e, por isso, saber aproveitá-lo bem diferencia os homens dos pirralhos.

Um lugar onde não esperava ouvir sobre gestão de tempo é no ótimo Ultimate Sales Machine, livro sobre vendas escrito por Chet Holmes. No início do livro ele fala: “não existe um bom vendedor que não seja também uma pessoa eficiente, por isso a 1ª coisa que eu preciso falar é sobre gestão de tempo”.
A grande diferença do modo como ele falou sobre gestão de tempo foi a praticidade do conteúdo. Ao invés de falar sobre métodos, ele simplesmente listou ações que funcionaram com ele e com outras pessoas que ele orientou.
Seguem os 6 mandamentos:

1- Encoste uma vez
Se você começou a fazer uma tarefa, termine-a antes de ver um email ou checar o Facebook. Isso acontece normalmente com emails: você abre o email, termina a leitura, começa a responder e pensa “hm, termino isso depois”.
O problema é que pra terminar isso depois, você vai ter que gastar tempo novamente lendo o email e vendo o que você já escreveu - ou seja, o tempo de preparação é retrabalho e aí você está desperdiçando tempo.

2- As 6 tarefas mais importantes do dia
Todo dia defina quais são “as 6 tarefas mais importantes” do dia, aquelas que tem que acontecer de qualquer maneira. A questão é: se você não finaliza 6 tarefas importantes por dia, algo está errado.
No geral, é legal considerar essas tarefas como ações que vão causar progresso na sua empresa, e não processos pequenos.

3- Defina a duração de cada tarefa
Os tempos de cada tarefa são extremamente variáveis e ter planejado o que será feito e por quanto tempo é essencial para que você saiba que o seu dia é possível (que as tarefas cabem no seu horário útil).
Por isso é legal quebrar projetos mais longos em tarefas menores para que você possa ver o avanço aos poucos, ao invés de tentar fazer tudo de uma vez só. Além de ajudar na gestão do seu tempo, a qualidade do projeto feito aos poucos tende a ser maior.

4- Defina quando, dentro do dia, você fará cada tarefa
Por questões logísticas ou mesmo de humor, definir o horário em que você fará cada tarefa é muito importante.
Além disso, saber se uma tarefa é pré-requisito de outra ajuda bastante nessa parte.

5- Faça as tarefas mais difíceis primeiro
Não importa se o seu horário de maior produtividade é de manhã, de noite ou de madrugada. A partir do ponto que você está com energia e concentração para produzir de verdade, faça primeiro os projetos mais difíceis/importantes .
Isso garante que você terá o máximo do seu poder cognitivo pra ele e também te ajuda a fugir da procrastinação.

6- Se eu não fizer isso, eu vou morrer?
Essa é uma pergunta bem extremista, mas passa bem o tom. Quanto menos tempo você tem, mais você aprende a priorizar o que é mais importante e a enxergar o que não fará diferença na sua vida.
Para garantir que você está fazendo apenas atividades úteis, sempre faça essa pergunta a si mesmo.

Fonte
Saia do Lugar

O que são essas tais de metodologias Ágeis ?

2012-01-25T09:04:00.000-03:00

Introdução

O grande filósofo e pai da da administração moderna Peter Drucker já dizia:
"... most of our assumptions about business, technology and organizations are at least 50 years old. They have outlived their time. As a result, we are teaching and practicing policies that are increasingly at odds with reality and therefore counterproductive .“
[Peter Drucker 1998]

Devido as crescentes pressões do mercado por inovação, produtividade (prazos casa vez mais cursos), flexibilidade e melhoria no desempenho/qualidade dos projetos de desenvolvimento de SW, houve o surgimento dos métodos ágeis.
O ágil surgiu dado a necessidade de melhorarmos a forma como estamos desenvolvendo SW e nosso foco principal é satisfazer o cliente.

Uma coisa é fato, nós da área de TI estamos errando e errando muito.
Apenas 32% dos projetos entregues são considerados sucesso. 24% são puro fracasso (cancelados, ou engavetados - nunca colocados em produção ou utilizados pelo cliente), 44% são desafiados (sofreram atrasos, estouraram o budget, não atendem as necessidades, estão cheios de defeitos).

	1994	1996	1998	2000	2002	2004	2006	2009
Successful	16%	27%	26%	28%	34%	29%	35%	32%
Challenged	53%	33%	46%	49%	51%	53%	46%	44%
Failed	31%	40%	28%	23%	15%	18%	19%	24%

(fonte: Standish Group - Chaos Report)

E o resultado consegue ser ainda pior, pois para os projetos considerados sucesso, apenas 20% da funcionalidade do SW é realmente útil.

É claro que a falha na execução de um projeto deve ser investigada e a causa pode ser dada decorrente de diversos motivos, mas de maneira geral esses erros ocorrem porque muitas vezes ao iniciar um projeto fazemos as seguintes suposições:

Os requisitos são 100% conhecidos no início do projeto e foram levantados e minuciosamente detalhados.

O desenvolvedor sabe como construir

Nada irá mudar ao longo do caminho

Porém existem 3 coisas com as quais temos que conviver na época em que vivemos hoje onde os Software que produzimos estão ficando cada vez mais complexos:

O cliente descobre o que ele realmente quer, ou seja, é puro desperdício (tempo e esforço) detalhar minuciosamente os requisitos no ínicio do projeto e escrevê-los sobre pedra. Muitas vezes os requisitos mudam mas não necessariamente porque o cliente quer, mas porque a necessidade exige, porque o mercado exige.

“Um processo rígido ou resistente a mudanças produz produtos medíocres. Os clientes podem até receber o que eles solicitaram primeiramente, mas é esse o produto que eles realmente querem logo quando eles o recebem? Coletando todos os requisitos no início e escrevendo-os sobre pedra, o produto é condenado a ser tão bom quanto a idéia inicial, ao invés de ser o melhor uma vez que as pessoas aprendem ou descobrem como fazer melhor.” [Jeff Sutherland]

Os desenvolvedores descobrem como construir - idéias, novas tecnologias e opções surgem no decorrer do projeto. Desta forma uma nova idéia não deveria ser mau vista pela equipe/gestor.

Muitas coisas mudam ao longo do caminho.

Ágil é uma nova forma de gestão e desenvolvimento de Software que usa uma abordagem de planejamento e execução iterativa e incremental voltado para processos empíricos (complexos, caóticos ou com muita incerteza, tem mudança ao longo do processo, não são repetitivos e são imprevisíveis) que divide o problema em produtos menores e que visa entregar software funcionando regularmente, visa a aproximação e maior colaboração do time de desenvolvimento com os experts de negócios, comunicação face-to-face, redução dos riscos associados as incertezas dos projetos, abraçar e responder as mudanças de forma mais rápida e natural e é claro a satisfação final dos clientes por meio da adoção de práticas de gestão e de engenharia de software com foco nos valores e princípios doLean e do agile, resumindo, seu principal objetivo é entregar o produto que o cliente realmente deseja e que será útil e com qualidade.

Agilidade em TI é: “a habilidade de criar e responder a mudanças, buscando a obtenção de lucro em um ambiente de negócio turbulento” (HIGHSMITH, 2004); ou ainda, a capacidade de balancear a flexibilidade e a estabilidade. HIGHSMITH (2004) enfatiza que a ausência de estrutura ou estabilidade pode levar ao caos, mas que a estrutura em demasia gera rigidez.

Vantagens (Cliente)

Foco e maximização do ROI (Retorno do Investimento) e do Valor de Negócio;

Entregas do produto + rápida, freqüentes e regulares;

Aceleração do Time-to-market o que se traduz em ganho de competitividade;

Maximização do Value-to-Makert;Foco no que é prioritário e traz mais valor para o usuário, o que se traduz em ganho de usabilidade;

Transparência e visibilidade do status do projeto;

Flexibilidade para mudanças de requisitos e prioridades além de maior agilidade na tomada de decisões;

Melhoria da Qualidade do produto final;

Produtividade;

Redução dos riscos e das indesejáveis surpresas.

Vantagens (gestor e equipes)

Escopo e objetivos claros e priorizados;

Equipes auto-gerenciáveis, maior autonomia, disciplina e regularidade;

Maximização do comprometimento;

Melhoria na comunicação. A comunicação intensa com o cliente e a gestão de suas expectativas são parte do processo;

Inspeção e Adaptação constantes do processo em busca da melhoria contínua e a redução dos desperdícios;

Antecipação dos problemas e maior agilidade na tomada de ações.

Pesquisa realizada, mostra os benefícios mais obtidos:

Outras pesquisas, disponíveis em: http://www.ambysoft.com/surveys/

E quem pensa que a metodologia ágil é novidade se engana. Este ano (2011) celebramos exatos 10 Anos que o Manifesto ágil foi criado e assinado.

Para os que ainda não o conhece, apresento-lhes o Manifesto ágil:

"Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda."

Assinado por: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, os autores acima.
Esta declaração pode ser copiada livremente em qualquer formato, mas somente integralmente através desta declaração.
www.agilemanifesto.org

Os 12 princípios do agile

Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é através de conversa face a face.

Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente.

Contínua atenção à excelência técnica e bom design aumenta a agilidade.

Simplicidade--a arte de maximizar a quantidade de trabalho não realizado--é essencial.

As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.

Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu comportamento de acordo.

Para mais informações sobre o manifesto ou sobre esse evento que reuniu as 17 pessoas que criaram esta aliança, sugiro este artigo: clique aqui

Quais são as metodologias ágeis que existem e quais as mais utilizadas?
“Desenvolvimento ágil" é o termo utilizado por diferentes metodologias e frameworks que desenvolvem software de forma iterativa e incremental.
Algumas são mais prescritivas ou menos mas as metodologias ágeis mais comuns são: Extreme Programming (XP), Scrum, Lean Development, Feature-Driven Development (FDD), Kanban, RUP e OpenUP.
Pesquisas mostram que o Scrum é de longe o framework mais utilizado por ser o mais simples e de fácil adoção e adaptação.

Mas então Scrum é o melhor framework para utilizar? Depende. Cada uma dessas metodologias tem a sua particularidade e práticas sugeridas mas muitas vezes o que vemos hoje em dia são os modelos hybridos, que são na verdade uma mescla dessas metodologias/frameworks onde as melhores práticas de cada metodologia é aplicada a um processo customizado. É preciso analisar a necessidade e a maturidade da equipe para então escolher um framework ou práticas ágeis que lhe traga o benefício esperado.

Adotar uma metodologia ágil pode trazer muitos benefícios, mas nós costumamos dizer que o ágil não é a bala de prata, ou seja, apenas aplicar por exemplo o SCRUM ou algumas de suas práticas ágeis por si só não vai resolver os seus problemas, mas evidênciar suas fraquezas para que você possa identificar e atuar sobre elas. Cabe então a equipe atuar de forma pró-ativa e desejar as mudanças para que os benefícios que o ágil pode proporcionar possa valer de verdade.

Dentre as principais causas de falha na adoção de uma metodologia ágil estão:

- Filosofia ou a cultura da empresa que conflitam com os valores e princípios do agile;
- Falta de suporte gerencial para apoiar as mudanças; É preciso desejar as mudanças;
- Falta de experiência ou treinamento insuficiente no novo processo; É preciso tornar-se capaz de trabalhar de maneira ágil;

- Boicote, falta de comprometimento da própria equipe. É preciso reconhecer que há espaço para melhorias e desejá-las;

Aplicar o ágil não é uma tarefa fácil. Exige determinação e disciplina. É UMA MUDANÇA DE COMPORTAMENTO.
Ah! mas uma boa ferramenta como o RTC ajuda, e ajuda muito!!!
Preparados? Vamos implantar o ágil?

Por
Juliana Berossa Steffen
Certified Scrum Master
Certified Scrum Product Owner
Professional Scrum Master I

Via Rational Brasil

2012-01-18T18:03:00.001-03:00

Minha atual e triste realidade! :/

Google lança Chromebook com o tema: “Skip straight to the good stuff”

2011-11-23T23:57:00.001-03:00

Google começa a vender o tão esperado Chromebook estrategicamente visando o natal.

Na página oficial, imagens de duas fabricantes estão disponíveis: Samsung e Acer.

Apostando num sistema operacional online, inova dizendo para não perder mais tempo com inicializações, para esquecer configurações, para esquecer os manuais e ir direto para a criação, compartilhamento e diversão.

“Porque tudo é mais rápido e fácil no Chromebook.”

Site oficial: http://www.google.com/chromebook/index.html

O que é a Semana Global do Empreendedorismo?

2011-11-12T19:46:00.001-03:00

A Semana Global do Empreendedorismo é um movimento internacional que acontece todos os anos, durante o mês de novembro e que envolve hoje 104 países.

Só no ano passado, 41.711 organizações e parceiros que acreditam que é possível transformar o mundo por meio do empreendedorismo realizaram 37.560 atividades inspiradoras, despertando o espírito empreendedor de 7,25 milhões de pessoas ao redor do mundo.

Em 2008, o Brasil foi um dos primeiros países a fazer parte do movimento. Desde então, realiza a maior Semana Global dentre os países participantes. Só em 2010, 594 parceiros realizaram 3.243 atividades em todo o país, impactando 2,6 milhões de participantes.

http://semanaglobal.org.br

Trabalho remoto traz inúmeros benefícios para empresas

2011-11-12T12:32:00.001-03:00

Profissionais em home office podem ser mais felizes e produtivos do que os que desempenham as funções na sede da empresa.

O telecomuting, teletrabalho ou trabalho remoto, que permite às pessoas trabalharem em diferentes locais, oferece inúmeras oportunidades para as pequenas empresas, incluindo a redução de custos e a capacidade de contratar rapidamente trabalhadores temporários. Ferramentas de telepresença, como videoconferência, tornam o trabalho remoto possível.

O governo dos Estados Unidos adotou o trabalho remoto antes de muitas companhias do setor privado. Um número crescente de empresas tem prosperado com trabalhadores remotos, fornecendo serviços por meio da web.No Brasil, não existe qualquer artigo na lei que rege as relações de trabalho que proíba a modalidade, mas muitas empresas evitam a prática, diante das dificuldades de controle da jornada de trabalho, principalmente em função do cálculo de horas extras. Razão pela qual algumas empresas proponham ao trabalhador um acordo no contrato de trabalho, registrando a flexibilidade de trabalho externo em carteira, liberando-as do pagamento de horas extras.

A seguir, listamos alguns argumentos que servirão para considerar a ideia de que oferecer trabalho remoto para os membros da equipe pode ser uma excelente alternativa.

1 - Funcionários mais produtivos

Quando podem trabalhar em casa, eles não têm as distrações do escritório, e não gastam tempo com locomoção. Vários estudos acadêmicos e pesquisas corporativas mostram que os trabalhadores remotos são muitas vezes mais felizes e mais produtivos do que aqueles que ficam na sede da empresa. Alguns trabalhadores podem precisar de supervisão, mas você pode fazer isso por meio de metas de produção em vez de monitorar horas trabalhadas por dia.

2 - Alcançar os profissionais da equipe onde quer que estejam,independentemente da localização

Geralmente, a adoção do trabalho remoto implica na construção de infraestrutura mínima adequada: software e conexão à internet apropriados. As ferramentas incluem aplicações de controle remoto, software de colaboração e software de videoconferência. Pode ser mais fácil alcançar os membros da equipe por meio da web do que caminhar pelo escritório.

Os aplicativos de controle remoto como LogMeIn, GoToMyPC ou Splashtop Remote Desktop registram o usuário em casa e controlam o computador usado para o trabalho. Os software de colaboração como o Google Apps e o Office 365 permitem que os usuários compartilhem documentos, arquivos, apresentações, e outros dados em diferentes locais, simultaneamente. E software de videoconferência – como o Cisco WebEx Meeting Center, Citrix GoToMeeting, ou o Google+ Hangouts, que é de graça – facilitam reuniões de grupo.

3 - Economia de espaço e corte de custos

O trabalhador remoto não apenas suprime a própria mesa e o PC, como também energia elétrica, lanches, água, banda larga, serviço de telefonia e muito mais. Isso permite reduzir despesas para o escritório. Mesmo se você reembolsar alguns custos, como conectividade com a internet ou o uso do telefone, ainda irá economizar na metragem quadrada do espaço da empresa.

4 - Gestão aprimorada de TI e redução de custos de manutenção

Em geral, os trabalhadores remotos fornecem sua própria conectividade e PCs. Se for necessário instalar antivírus, acesso remoto, e outros software, os custos totais devem ser muito menores em comparação com a gestão in-house. Você vai querer definir normas e talvez implementar o cumprimento delas, como a verificação de software para garantir que ninguém que se conecte à rede esteja infectado com vírus ou que tenha software desatualizados.

5- Desfrutar de serviços baseados em nuvem

Em vez de hospedagem de servidores em seus escritórios, você pode tirar vantagem de aplicações na nuvem que permitem a telepresença. As aplicações cloud podem fornecer serviço mais confiável do que seus próprios servidores. Fornecedores de cloud têm vários data centers redundantes para garantir a conectividade confiável. Obviamente, você vai precisar investigar minuciosamente a segurança disponível e as opções de backup de cada serviço.

6 - Negócio mais ágil

Se as ferramentas estão configuradas corretamente, o trabalho remoto pode tornar a empresa mais ágil, dando maior flexibilidade aos profissionais para atender às exigências do projeto. Você pode, rapidamente, encontrar e recrutar trabalhadores para projetos específicos.

7 - Mão de obra mais barata

Se você está localizado em uma área cara, pode economizar quantidades substanciais de dinheiro. Os profissionais podem viver em regiões com boa e mais barata conectividade de internet – e estarão satisfeitos com salários mais baixos do que nas grandes cidades. Além disso, muitos funcionários aceitam um salário menor em troca do trabalho remoto.

Finalmente, se você contratar profissionais por meio de contratos independentes, irá economizar ainda nos custos de folha de pagamento.

O trabalho remoto pode salvar a companhia com somas substanciais com poucas desvantagens reais se você gerenciar a segurança com cuidado. A percepção de dificuldade na supervisão de trabalhadores remotos, muitas vezes parece ser a maior barreira para implementar o trabalho remoto, mas é possível superar isso olhando para o lucro.

Fonte: ComputerWorld

Os 10 maus habitos dos desenvolvedores jsf

2011-11-07T11:41:00.001-03:00

View more presentations from Rafael Ponte

Aproveitando o assunto, é interessante também aprofundar no tema Anatomia do JSF:

View more presentations from Rafael Ponte

NINGUÉM É SUBSTITUÍVEL !!!

2011-10-17T11:42:00.001-03:00

Na sala de reunião de uma multinacional o diretor nervoso fala com sua equipe de gestores.

Agita as mãos, mostra gráficos e, olhando nos olhos de cada um ameaça: "ninguém é insubstituível"! A frase parece ecoar nas paredes da sala de reunião em meio ao silêncio. Os gestores se entreolham, alguns abaixam a cabeça. Ninguém ousa falar nada. De repente um braço se levanta e o diretor se prepara para triturar o atrevido:

- Alguma pergunta?

- Tenho sim.

E Beethoven?

- Como? - o encara o diretor confuso.

- O senhor disse que ninguém é insubstituível e quem substituiu Beethoven?

Silêncio...

O funcionário fala então:

- Ouvi essa estória esses dias, contada por um profissional que conheço e achei muito pertinente falar sobre isso. Afinal as empresas falam em descobrir talentos, reter talentos, mas, no fundo continuam achando que os profissionais são peças dentro da organização e que, quando sai um, é só encontrar outro para por no lugar. Então, pergunto: quem substituiu Beethoven? Tom Jobim? Ayrton Senna? Ghandi? Frank Sinatra? Garrincha? Santos Dumont? Monteiro Lobato? Elvis Presley? Os Beatles? Jorge Amado? Pelé? Paul Newman? Tiger Woods? Albert Einstein? Picasso? Zico? Etc.?...

O rapaz fez uma pausa e continuou:

- Todos esses talentos que marcaram a história fazendo o que gostam e o que sabem fazer bem, ou seja, fizeram seu talento brilhar. E, portanto, mostraram que são sim, insubstituíveis. Que cada ser humano tem sua contribuição a dar e seu talento direcionado para alguma coisa. Não estaria na hora dos líderes das organizações reverem seus conceitos e começarem a pensar em como desenvolver o talento da sua equipe, em focar no brilho de seus pontos fortes e não utilizar energia em reparar seus 'erros ou deficiências'?

Nova pausa e prosseguiu:

- Acredito que ninguém se lembra e nem quer saber se BEETHOVEN ERA SURDO , se PICASSO ERA INSTÁVEL , CAYMMI PREGUIÇOSO , KENNEDY EGOCÊNTRICO, ELVIS PARANÓICO... O que queremos é sentir o prazer produzido pelas sinfonias, obras de arte, discursos memoráveis e melodias inesquecíveis, resultado de seus talentos. Mas cabe aos líderes de uma organização mudar o olhar sobre a equipe e voltar seus esforços, em descobrir os PONTOS FORTES DE CADA MEMBRO. Fazer brilhar o talento de cada um em prol do sucesso de seu projeto.

Divagando o assunto, o rapaz continuava.

- Se um gerente ou coordenador, ainda está focado em 'melhorar as fraquezas' de sua equipe, corre o risco de ser aquele tipo de 'técnico de futebol', que barraria o Garrincha por ter as pernas tortas; ou Albert Einstein por ter notas baixas na escola; ou Beethoven por ser surdo. E na gestão dele o mundo teria PERDIDO todos esses talentos.

Olhou a sua a volta e reparou que o Diretor, olhava para baixo pensativo. E voltou a dizer nesses termos:

- Seguindo este raciocínio, caso pudessem mudar o curso natural, os rios seriam retos não haveria montanha, nem lagoas nem cavernas, nem homens nem mulheres, nem sexo, nem chefes nem subordinados... Apenas peças... E nunca me esqueço de quando o Zacarias dos Trapalhões que 'foi pra outras moradas'... Ao iniciar o programa seguinte, o Dedé entrou em cena e falou mais ou menos assim:"Estamos todos muito tristes com a 'partida' de nosso irmão Zacarias... e hoje, para substituí-lo, chamamos:..NINGUÉM...Pois nosso Zaca é insubstituível." - concluiu o rapaz e o silêncio foi total.

Conclusão:

PORTANTO NUNCA ESQUEÇA:

VOCÊ É UM TALENTO ÚNICO!

COM TODA CERTEZA NINGUÉM TE SUBSTITUIRÁ!

"Sou um só, mas ainda assim sou um. Não posso fazer tudo..., mas posso fazer alguma coisa. Por não poder fazer tudo, não me recusarei a fazer o pouco que posso."

"NO MUNDO SEMPRE EXISTIRÃO PESSOAS QUE VÃO TE AMAR PELO QUE VOCÊ É... E OUTRAS... QUE VÃO TE ODIAR PELO MESMO MOTIVO... ACOSTUME-SE A ISSO... COM MUITA PAZ DE ESPÍRITO..."

É bom para refletir e se valorizar!

Boa semana... INSUBSTITUÍVEL!!!!!

"Não basta fazer coisas boas; é preciso fazê-las bem"

Componente Data para JBoss Seam com RichFaces e Facelets

2011-10-14T16:20:00.001-04:00

Pessoal, tive que queimar um pouco de fosfato por esses dias para construir um componente de data para o JBoss Seam que atendesse aos seguintes requisitos:

Campo Data com Calendário permitindo o ator clicar numa data específica e navegar por entre os anos e meses de cada um;
Esse mesmo campo, deveria permitir que o usuário digitasse uma data qualquer caso assim preferisse;
Caso a data fosse digitada, essa deveria ser formatada automaticamente com uma máscara seguindo o padrão dd/MM/yyyy;
Aceitar somente números caso fosse digitado manualmente;

Bom, primeiramente utilizei o plugin MaskedInput do JQuery para trabalhar com a máscara, o download pode ser feito em http://digitalbush.com/projects/masked-input-plugin/

Seguinte o padrão do JBoss Seam com Facelets, incluí no arquivo template.xhtml a seguinte linha.

<a:loadScript src="/js/jquery.maskedinput-1.3.min.js" />

Após isso, criei o arquivo campoData.xhtml (componente) conforme o código a seguir:

<!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"
   xmlns:ui="http://java.sun.com/jsf/facelets"
   xmlns:s="http://jboss.com/products/seam/taglib"
   xmlns:f="http://java.sun.com/jsf/core"
   xmlns:h="http://java.sun.com/jsf/html"
   xmlns:rich="http://richfaces.org/rich"
   xmlns:a4j="http://richfaces.org/a4j">
 
<ui:composition>

<rich:calendar     id="#{id}"
                       value="#{value}"
                       datePattern="dd/MM/yyyy"
                       enableManualInput="true"
                       todayControlMode="hidden"
                       inputClass="calendario_#{id}"
                       showWeeksBar="false"
                       showApplyButton="false"
                       popup="true"
                       required="#{required}"
                       disabled="#{disabled}"
                       reRender="#{idDecorate}">

<a4j:support    event="oninputblur"
                           ajaxSingle="true"
                           reRender="#{idDecorate}"
                           onsubmit="if(this.value == '__/__/____'){this.value=''};"/>
</rich:calendar>

    <rich:jQuery selector=".calendario_#{id}" timing="onload" query="mask('99/99/9999')"/>

</ui:composition>
</html>

Depois criei um arquivo de componentes personalizado para minha aplicação chamado componentes-i9web.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE facelet-taglib PUBLIC
    "-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"
    "facelet-taglib_1_0.dtd">
    
<facelet-taglib>
    <namespace>http://www.i9web.com.br/componentes</namespace>    
    
    <tag>
        <tag-name>campoData</tag-name>
        <source>../layout/campoData.xhtml</source>
    </tag>        
                
</facelet-taglib>

E nas páginas onde utilizado, faço o import do componente :

<!DOCTYPE composition PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
    xmlns:s="http://jboss.com/products/seam/taglib"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:a="http://richfaces.org/a4j"
    xmlns:rich="http://richfaces.org/rich"
    xmlns:a4j="http://richfaces.org/a4j"
    xmlns:p="http://primefaces.prime.com.tr/ui" 
    xmlns:i9="http://www.i9web.com.br/componentes" 
    template="/layout/template.xhtml">

E no campo, fica assim:

    <s:decorate id="dDataNascimento" template="/layout/edit.xhtml">
                           <ui:define name="label">Data Nascimento</ui:define>
                        <i9:campoData 
                                value="#{userHome.instance.dtaNascimento}" 
                                id="dataNascimento" 
                                idDecorate="dDataNascimento" 
                                required="true"
                                requiredMessage="Obrigatório"/>
                    </s:decorate>

Lean para desenvolvimento de Software. Afinal, o que é isto?

2011-10-10T16:37:00.001-04:00

A filosofia "Lean Thinking" (ou "Pensamento Enxuto") nasceu em meados dos anos 90 com o lançamento do best seller "The Machine That Changed the World : The Story of Lean Production". Os princípios de

demanda puxada (pull systems), just-in-time, qualidade total, teoria das restrições, melhoria contínua e flexibilidade aplicados na indústria japonesa, mais precisamente na Toyota e conhecidos como Toyota Way inspiraram também a indústria de software e fez surgir a abordagem do Lean Software Development.

Mary e Tom Poppendieck (gurus de Lean voltado a TI, defensores do agile e autores do livro: "Lean Software Development - An Agile Toolkit" que mostra como os princípios Lean podem ser aplicados em abordagens de desenvolvimento de software ágil) usou a seguinte frase para definir Lean:

"What is Lean?

• Deliver continually increasing customer value
• Expending continually decreasing effort
• In the shortest possible timeframe
• With the highest possible quality
A journey, not a destination. "

E acrescentam: "Acelerar a produção do desenvolvimento de Software é geralmente uma questão de melhorar o processo ao invés de adicionar pessoas. Pare de fazer coisas que o cliente não valoriza! Vista os óculos do cliente! "
Tentando resumir em uma frase, Lean é um princípio ágil cujo foco é cortar a "gordura" do processo de software, focando na eliminação de desperdícios.

Princípios Lean aplicados ao software:

Elimine Desperdícios
Inclua a Qualidade no Processo
Crie Conhecimento
Adie Decisões e Comprometimentos
Entregue o quanto antes
Respeite as Pessoas e "Empower" a equipe
Otimize o Todo

Vamos ver os 7 princípios de Lean e como transforma-los em práticas ágeis.

Princípio #1 – Eliminar desperdícios
Desperdícios: tudo aquilo que não agrega valor para cliente final e que não são percebidos pelo cliente. Exemplo: passos extras, processo pesado e rígido, burocracia, documentação que nunca vai ser lida, que está na prateleira juntando poeira - não necessária, etc. Outro tipo de desperdício são trabalhos parcialmente prontos, tudo que começa e não termina, funcionalidades extras que não serão utilizadas, etc.

Enfim, software útil e de funcionando (de qualidade) é o que vai trazer valor ao cliente. Os sete desperdícios de software:
Inventory = Requirements / Partially done work
Extra Processing Steps = Extra processes, steps
Overproduction = Extra features
Transportation = Handoffs, tasks switching
Waiting = Waiting
Defects = Defects
Motion = Finding Information

Não se iluda, embora alguns sejam gritantes não é fácil identificar alguns tipos de desperdício. É preciso aprender a enxergar os desperdícios e existem algumas práticas e exercícios que podem ajudar, tais como: Seeing waste e Value Stream mapping.

Vejamos os tipos de desperdícios mais detalhadamente:

1 - Requisitos

Requisitos, especificados muito cedo que perdem sua credibilidade, eficácia e compromete a usabilidade do sistema.

Trabalho incompleto (“em-progresso”) - Parcialmente feitos

Trabalhos parcialmente iniciados / terminados tendem a se tornar obsoletos.

O maior problema é não ter idéia se eventualmente funcionam ou não. Enquanto os trabalhos não são integrados, não podem ser utilizados e não temos como saber quais problemas podem aparecer. Funcionalidades pela metade apenas atravancam o caminho para trabalhos que poderiam ser feitos. Tornando-se facilmente obsoleto.

Consomem recursos sem trazer retorno.

Exemplos: Documentação não codificada, código não sincronizado, código não testado, código não implantado.

2 - Processos/Passos a mais

Burocracia, atividades, métricas, etc que não geram valor e que diminui o tempo de resposta.

Você alguma vez já se perguntou, toda aquela documentação e papelada é realmente necessária?

Documentação desnecessária e documentação que são esquecidos ou perdem valor e se tornam obsoletos ou documentos que ninguém se importa em ler.

O seu cliente realmente acha que isso torna o produto dele mais eficiente?

Dica: Faça esse questionamento para descobrir quando a documentação tem valor agregado : Tem alguém esperando ou dependendo do que você esta produzindo?.

Ainda assim lembre-se: Mantenha-o enxuto, em alto-nível e documente o mais tardar possível.

3 - Funcionalidades a mais

80% das funcionalidades implementadas não são utilizadas.

20% das funcionalidades é que são realmente úteis.

Código não-utilizado introduz complexidade e a complexidade é um inimigo da manutenção. Mais código para ser mantido. Mais testes para serem realizados. Mais documentos de especificação para serem criados. Se o código não é necessário agora colocá-lo no sistema é desperdício.

4 - Troca de tarefas (Task switching, Handoffs)

Corrida de revezamento deve ser substituída pela equipe multi-funcional.

Quanto maior os handoff’s maior é a perda de conhecimento. Organizar pessoas em múltiplos projetos é outra forma de desperdício.

Quanto tempo se perde para parar uma determinada atividade e iniciar outra, relembrar onde parou, concentrar-se e finalmente produzir algo?

5 - Atrasos

Atrasos na entrega, atrasos em geral são puro desperdício e irão gerar aumento do custo do projeto.

Em muitos casos, atrasos são apenas a ponta do iceberg para problemas muito maiores.

Espera: Um dos maiores desperdícios no desenvolvimento de Software é a espera para que as coisas aconteçam. Espera para o início do projeto, pela montagem da equipe, espera pela produção de documentação extensa, espera por processo de revisão ou aprovação, espera para testar, etc. Veja, analise o que deve ser mantido, o que agrega valor e o que é puro despedício.

6 - Defeitos

Equipes ágeis se esforçam ao máximo para evitar defeitos.

“Inspecionar para prevenir defeitos é bom;

Inspecionar para encontrar defeitos é desperdício” -- Shigeo Shingo

Defeitos (Bugs) não agregam valor, não satisfazem o cliente, e custam muito muito caro.

7 - Movimento

Tempo e esforço gasto para encontrar informações.

Equipes ágeis valorizam a conversa e por isso trazem o cliente para perto, não devemos perder tempo lendo páginas e páginas de um documento para encontrar uma informação que ao mesmo tempo por estar na forma escrita muitas vezes são imprecisas e pode trazer mais dúvidas do que resolver o problema.

Princípio #2 – Qualidade embutida

Qualidade é inegociável. Entregue qualidade intrínseca e explícita aos seus clientes, se eles perceberem isso, significa que foi uma entrega de qualidade. Mary e Tom Poppendieck em seu livro identificaram duas dimensões de integridade: integridade percebida e integridade conceitual. A integridade percebida significa que a totalidade do produto alcança um equilíbrio entre as funções, usabilidade, confiabilidade, economia e isso encanta o cliente. A integridade conceitual significa que os conceitos centrais do sistema de trabalho em conjunto são facilitados e coesos. Essa última é fator crítico de sucesso para a integridade percebida.

Um produto possui integridade percebida quando o cliente o experimenta e diz: Isso! Era exatamente isso que eu queria! Software com integridade possui boas arquiteturas, possuem um alto nível de usabilidade e facilidade de uso, são fáceis de dar manutenção, de adaptar e de estender.

Dicas:

Não verificar a qualidade só no final, verificar durante todo processo e também toda equipe testa!

Quanto antes um problema é verificado mais barato ficará

Foco na prevenção, não na verificação no final do processo - Ao invés de se esforçar para gerenciar defeitos, evite-os.

"Logar" defeitos é desperdício, corrija-os imediatamente.

Práticas sugeridas para promover a qualidade:

4 quadrantes de teste
TDD - Test Driven Development
Refactoring
Integração contínua
Code review / code inspection
Standards
Testes contínuos e automatizados

Princípio #3 – Criar conhecimentos

Desenvolvimento é um exercício de descoberta, enquanto produção é um exercício de reduzir a variação. Desenvolvimento é como fazer uma nova receita, enquanto produção é como fazer um prato. Receitas são formuladas por chefes de cozinha experientes que de certa forma desenvolveram habilidades e capacidade de combinar os ingredientes disponíveis para produzir o prato desejado. Desenvolver uma receita é um processo de descoberta, até os chefes mais experientes produzem diversas variações de um novo prato, fazem iterações, experimentações, até encontrar a melhor combinação de ingredientes que resulte em um prato rápido e sabor agradável. Não se espera que os chefes obtenham uma receita perfeita de primeira; espera-se produzir diversas variações como parte do processo de aprendizagem. Desenvolvimento de software é melhor concebido se este fizer parte de um processo de aprendizado similar ao de criar uma nova receita. A melhor abordagem para melhorar o ambiente de desenvolvimento de software é pela expansão do conhecimento.

Práticas sugeridas para promover o conhecimento:

Ciclos de feedback e inspeções e adaptações;
Desenvolvimento iterativo;
Equipes pequenas e cross-functional;
Treinamentos e Mentoring;
Criação e utilização de standards, guidelines e qualquer outro artefato;
Code Reviews;
Meios de compartilhamento de informações como um Blog ou Wiki;

Princípio #4 – Adiar decisões / compromissos

O principal conceito deste princípio é diminuir as incertezas retardando as decisões até que possam serem feitas com base em acontecimentos mais firmes, previsíveis e conhecidos. Decisões tardias tendem a ser mais acertadas porque as melhores decisões são feitas baseadas em fatos, e não em suposições ou especulações. Uma estratégia chave para adiar decisões/comprometimentos quando desenvolvendo um sistema complexo e com muitas incertas é usar a capacidade e práticas que permitam abraçar as mudanças tardiamente.

Práticas sugeridas para adiar compromissos:

Iterações
Planning meetings
Behaviour/Feature Driven Development
Outros

Princípio #5 – Entregar rápido
Sem entregas rápidas não é possível colher feedback. Sem entregas rápidas não é possível aprender com erros. Velocidade na entrega garante que o cliente receberá o que ele precisa hoje e não o que ele precisava ontem.

Práticas sugeridas:

Pull System - Kanban
Iterações
Seja simples

Princípio #6 – Respeitar as pessoas

Envolver os desenvolvedores nos detalhes das decisões técnicas é fundamental para o atingimento da exelência.

Dicas:

Um ambiente que favoreça o desenvolvimento das pessoas.

Uma empresa que respeita as pessoas, assim as pessoas irão respeitar a empresa

O Software produzido é como um espelho da equipe de desenvolvimento.

Para que as pessoas possam assumir responsabilidades, se sentir motivados e atuar como uma equipe eles precisam de confiança e de respeito.

Práticas sugeridas para promover o empowering do time:

Auto-gestão
Trabalho em equipe
feedback

Princípio
#7 – Otimizar o todo

Otimizar desde o começo até o final:

Utilize Métricas
Diminua o número de métricas de desempenho individual mas valorize o desempenho da equipe.
Meça para cima:
Tempo de ciclo +Mapa de Fluxo de Valor
ROI + Modelo de Lucros e Perdas
Satisfação do Cliente + Entendimento das suas necessidades

Para tornar o seu processo ágil, pense Lean!
Mas lembre-se Lean requer uma mudança da cultura e dos hábitos organizacionais para que esta possa usufruir das melhorias de performance que um processo enxuto pode proporcionar.

É UMA MUDANÇA DE MENTALIDADE E COMPORTAMENTO !

Por : Juliana Berossa Steffen

Certified Scrum Product Owner
Certified Scrum Master
Certified Professional Scrum Master

Scrum e a Crise Mundial

2011-10-08T10:13:00.001-04:00

Scrum e a Crise Mundial

I. Introdução

O mundo enfrenta uma das piores crises financeiras de sua história. Enquanto alguns acreditam que o momento atual se assemelha à crise de 1989, que gerou repercussões relativamente brandas e o mercado não demorou a se recuperar, outros afirmam que suas consequências serão catastróficas, comparáveis às da quebra da bolsa de Nova Iorque de 1929.

O fato é que diversos países europeus, Estados Unidos e Japão já se encontram em recessão. O Fundo Monerário Internacional (FMI) recentemente divulgou um relatório onde afirma que não só o mundo demorará a sair da recessão, mas também a recuperação das economias será menos vigorosa que em crises anteriores. Deverá haver também uma fuga maciça de capitais de países emergentes como Índia e Brasil. O Fundo divulgou ainda uma previsão de que a economia mundial encolherá 1,3% em 2009.

Mesmo o Brasil, que fortaleceu sua economia e vem resistindo à recessão, tem previsão de retração dos mesmos 1,3% para este ano.

II. Investimentos em Tecnologia

Uma vez configurada a recessão mundial, as empresas em todo o mundo começaram a cortar seus orçamentos. Por consequência, os investimentos em tecnologia deverão sofrer uma queda de 3 ou 4% em 2009, em previsões das consultorias Forrester e Gartner, respectivamente. Os gastos com programas de computador deverão permanecer praticamente estáveis, já que software é visto como algo que pode ajudar as empresas a economizarem, mas os investimentos em hardware e serviços de TI fecharão o ano em queda.

Recentemente, saíram os resultados das empresas do primeiro trimestre deste ano e o cenário não é animador. A Nokia, por exemplo, teve uma redução de 90% em seu lucro quando comparado ao mesmo período do ano passado, enquanto que a Toshiba teve um prejuízo de US$ 2.5 bilhões. Ambas têm planos de cortes de milhares de empregos. Empresas como a Intel viram suas ações despencarem na bolsa. Mesmo a gigante Google, que parecia intocável e contratou como ninguém nos últimos anos, divulgou a primeira redução na história em seu lucro trimestral e eliminou centenas de empregos.

III. O Novo Cenário para Projetos

O mercado de projetos vem se reconfigurando diante da crise. Os projetos de tecnologia, em particular, sofrem um forte impacto. Neste ambiente de incertezas e constantes mudanças, os atores do mercado de projetos já encontram racionalização do uso de recursos, acesso limitado a crédito, pressões por margens menores e problemas financeiros com grande parte dos clientes, tornando o processo decisório mais longo e gerando uma notável redução na demanda por projetos.

Esta nova configuração exige que as organizações mudem sua forma de trabalhar para conseguirem sobreviver, se fazendo necessária uma verdadeira quebra de paradigma.

Essa nova forma de trabalhar deverá:

funcionar bem em ambientes que mudam rapidamente, permitindo replanejamento frequente;
focar-se em maximizar o retorno do investimento (ROI) do cliente;
ajudar a reduzir o tempo de entrada em produção ou o tempo de lançamento do produto no mercado;
evitar desperdício de esforço e tempo com subprodutos e funcionalidades que nunca serão utilizados;
sempre entregar valor para o cliente, mesmo que o projeto seja interrompido antes do seu final previsto;
priorizar a comunicação e feedback entre as pessoas do projeto, para que todos saibam o que deve ser feito e o que está sendo feito.

Scrum é um framework para desenvolvimento de projetos focado em lidar com todas estas questões. Demonstraremos neste artigo que Scrum é a melhor opção para projetos em momentos de crise.

IV.Scrum e a Crise Mundial

Imaginemos alguns personagens do mercado de projetos inseridos na crise financeira:

uma organização (ou grupo dentro da organização) prestadora de serviços em projetos que deve aumentar sua competitividade para não perder clientes, internos ou externos;
um diretor ou gerente precisando reduzir custos operacionais para sua organização sobreviver, e para isso utiliza-se de projetos internos, visando melhorar seus processos;
um cliente que precisa contratar determinados projetos, internos ou externos, mas tem que reduzir custos para torná-los viáveis.

Forneceremos importantes argumentos para ajudar estes e outros decisores e influenciadores a defenderem a escolha de Scrum em suas organizações nestes tempos turbulentos.

a. Não ao Desperdício!

Metodologias não-ágeis defendem que devem ser gerados inúmeros documentos para se obter o sucesso do projeto. Uma parte significativa do custo e tempo do projeto é gasto na geração e manutenção desses documentos. No entanto, eles dificilmente são atualizados com a frequência necessária, até mesmo porque as mudanças correm mais rapidamente do que a capacidade da equipe de mantê-los, enquanto realiza o trabalho de implementação. Assim, grande parte dessa documentação muitas vezes se torna inútil e acaba deixada de lado.

Ken Schwaber, em seu livro The Enterprise and Scrum, afirma que cerca de 50% do tempo é gasto com requisitos, arquitetura e especificação em projetos típicos, e isso tudo é feito antes de se construir qualquer funcionalidade. No entanto, 35% dos requisitos mudam e 65% das funcionalidades descritas pelos requisitos nunca ou raramente serão utilizadas. Em tempos de crise, este desperdício de tempo e esforço não é aceitável.

Scrum defende que se deve utilizar somente a documentação estritamente suficiente e necessária para ajudar no desenvolvimento do projeto. Nem mais, nem menos. Exceto por alguns artefatos próprios do framework, Scrum deixa livre para que cada grupo decida qual documentação atende a esses requisitos, que pode ser simplesmente um papel rabiscado ou um quadro-negro. É importante lembrar que o objetivo do projeto é o produto, e não a documentação.

No Scrum, a lista priorizada de funcionalidades a se implementar é chamada de Product Backlog. Essa lista é dinâmica, pois deve sempre acompanhar as necessidades do cliente, que mudam ao longo do projeto. Além disso, sempre serão feitas as funcionalidades que são de maior importância para o cliente no momento anterior ao início de cada ciclo curto de desenvolvimento, chamado de sprint. Dessa forma, o que for entregue, terá muito mais chances de ser usado pelo cliente.

b. Maior Valor Primeiro!

Em um projeto típico waterfall, o cliente só recebe o produto pronto para ser usado ao ser aprovado nos testes de aceitação, depois de inteiramente especificado, implementado e testado. De forma parecida, para projetos de TI que usam o Rational Unified Process (RUP), o cliente só começa a ter algo em mãos no final da fase de construção, mas o produto só estará realmente utilizável na fase de transição. Em tempos de crise, o cliente necessita de retorno rápido ao investimento feito, mas com metodologias não-ágeis, ele só recebe valor no final do projeto.

Diferentemente de outras metodologias, Scrum prioriza explicitamente o retorno ao investimento (ROI) do cliente. Uma das principais funções do Product Owner é maximizá-lo através da atualização e priorização frequentes do Product Backlog, de forma que os itens de maior valor para o cliente em cada momento do projeto sejam implementadas primeiro. Assim, o incremento ao produto realizado ao final de cada sprint gera retorno ao investimento, quando entregue ao cliente. As entregas frequentes garantem que isso ocorra diversas vezes ao longo do projeto.

A priorização do Product Backlog pelo maior valor permite à organização se manter competitiva ao entregar resultados para seus clientes mais rápido que a concorrência, ao colocar em produção funcionalidades que agregam maior valor a seu negócio mais rapidamente ou ao lançar produtos e novas versões mais frequentemente no mercado, de forma que acompanhem as inevitáveis mudanças.

c. Que Venham as Mudanças!

Grandes e frequentes transformações acontecem em períodos de crise. Mudam a legislação e regulamentação, mudam nas regras de negócios, surgem oportunidades de novos negócios, importantes concorrentes deixam o mercado, verbas antes disponíveis se tornam escassas, empresas enfrentam grandes prejuízos, acontecem diversas fusões e aquisições na tentativa de se salvarem empresas e há frequentes intervenções do governo para tentar minimizar os problemas.

Para as metodologias tradicionais, a mudança é vista como indesejada, arriscada e cara. Estas metodologias pretendem que os contratos protejam a empresa contra mudanças de escopo, colocando o cliente como um potencial inimigo. Assim, cada mudança deve ser negociada e seu impacto deve ser quantificado dentro do projeto. A mudança então deve ser revista, aprovada, planejada, documentada e gerenciada.

O gerenciamento da mudança é fonte de estresse em projetos que utilizam metodologias não-ágeis. O estresse no relacionamento com o cliente se estabelece nas frequentes negociações das inevitáveis mudanças solicitadas ao longo do projeto, o que acaba refletindo no relacionamento de longo prazo. O tratamento da mudança como indesejada também se transforma em estresse no dia-a-dia da equipe de desenvolvimento.

O Manifesto Ágil defende que responder às mudanças é mais importante que seguir um plano. Como um framework ágil, Scrum encara a mudança como parte natural do processo de desenvolvimento. Com a atualização frequente do Product Backlog, as novas solicitações do cliente já podem ser introduzidas no produto no sprint seguinte. Esta resposta rápida à mudança se transforma em vantagem competitiva e, assim, a crise pode se transformar em oportunidades.

d. Quem Não se Comunica...

Em um projeto waterfall típico, o cliente só é encorajado a participar na fase de análise de requisitos e muito depois, nos testes de aceitação. O cliente percebe o projeto como uma grande caixa preta, cujo conteúdo será revelado apenas no final do processo. Assim, terminado o projeto, o resultado dificilmente atenderá às suas necessidades naquele momento, já que não houve interação durante todo o processo.

Em um projeto que adota Scrum, o Product Owner está sempre contato com o cliente para levantar suas necessidades e manter o Product Backlog constantemente atualizado e priorizado. O cliente recebe frequentemente novas versões e, assim, pode mais rapidamente dar feedback para a equipe através do Product Owner. Desta forma, o cliente se sente envolvido em todo o processo, compartilhando com a equipe a responsabilidade sobre o projeto e aumentando seu grau de confiança na equipe e no processo. A relação com o cliente deixa de ser meramente comercial e passa a contemplar parceria, cumplicidade, satisfação e fidelidade. Cria-se, assim, uma relação de longo prazo com o cliente, muitas vezes capaz de superar fortes períodos de crise.

Em metodologias não-ágeis, a visibilidade no projeto é promovida para seus stakeholders principalmente através de documentação. Como já mencionamos anteriormente, a documentação dá trabalho para ser feita, não é eficiente, não se mantém atualizada e acaba sendo deixada de lado.

No Scrum, a visibilidade no projeto é constantemente promovida. Alguns exemplos podem ser citados. As reuniões diárias servem para que os membros da equipe dêem visibilidade para os outros membros ao que eles fizeram desde a reunião anterior, e ao que irão fazer até a próxima. O kanban mostra, para quem quiser ver, todas as atividades que têm que ser feitas, as que estão sendo feitas e as já terminadas. As equipes trabalharem em um mesmo ambiente estimula a constante comunicação. Os gráficos de burndown mostram a todos o progresso do projeto, seja em horas ou em pontos. As entregas frequentes mostram ao cliente o que foi produzido, que por sua vez dá seu feedback para a equipe. A reunião de revisão mostra ao Product Owner o que foi desenvolvido naquele sprint, que por sua vez também dá seu feedback. Por fim, as reuniões de retrospectiva dão visibilidade para todos ao que funcionou bem no sprint e ao que pode melhorar.

Manter comunicação aberta entre os stakeholders do projeto é a melhor forma de garantir que todos saibam o que deve ser feito e o que está sendo feito. Isso gera aumento de produtividade, essencial para se sobreviver à crise.

e. Se o Projeto For Suspenso?

Em tempos de crise, é comum a verba acabar ou o fornecedor sair do mercado no decorrer do projeto, que tem que ser interrompido. Em um projeto não-ágil, o que o cliente receberá caso isso aconteça?

Se o projeto for suspenso logo após a fase inicial de especificação, o cliente receberá uma série de documentos que para nada servirão. Caso isso ocorra no meio da implementação, ele terá em mãos funcionalidades feitas pela metade e sem testes. Mesmo que isso aconteça no meio da fase de testes, o produto entregue dificilmente será confiável. Dessa forma, se o projeto for suspenso antes de seu final previsto, a chance de o cliente não receber retorno algum do investimento realizado será grande.

Um projeto com Scrum sempre produz um incremento ao produto potencialmente entregável ao final de cada sprint. Assim, se o projeto é suspenso em qualquer momento, o cliente pode utilizar o que foi gerado em sprints anteriores, reduzindo o seu risco. Em um ambiente de incertezas, isso se torna uma importante vantagem competitiva.

f. Se Tiver Que Reduzir a Equipe?

Em períodos de crise, pode ser necessário dispensar ou realocar membros da equipe. Em projetos waterfall, os papéis dentro do projeto são muito bem definidos. Em um projeto de TI, por exemplo, o programador programa, o testador testa, o designer faz a programação gráfica etc. Assim, se o designer sair do projeto, as telas novas ficarão sem programação gráfica; se o testador sair do projeto, o projeto ficará sem testes; se o responsável pelo banco de dados sair do projeto, ninguém cuidará do banco de dados; e pior, se o gerente de projetos sair do projeto, o projeto ficará desgovernado. Assim, o sucesso de todo o projeto ficará ameaçado.

Com Scrum, a responsabilidade pela entrega é de toda a equipe, independente de papéis. Embora haja uma especialização natural, as pessoas são estimuladas a desenvolverem e utilizarem suas habilidades secundárias e, em geral, farão todo o possível para compensar a falta de membros da equipe. Assim, mesmo que com uma capacidade menor, a equipe deverá continuar garantindo as entregas.

Vale alertar que demitir membros da equipe nunca deve ser a primeira alternativa para a contenção de despesas. Ao diminuir a equipe, estará sendo reduzida a sua capacidade de entrega de valor. Consequentemente, irá diminuir a satisfação do cliente, que acabará por procurar outros fornecedores que o atendam melhor. Isso irá piorar a situação da organização, criando um ciclo vicioso de perde-perde.

V. Conclusões

Neste artigo, mostramos que Scrum é a melhor opção para projetos nesses tempos de crise. Scrum supera outras metodologias por funcionar bem em um ambiente com constantes mudanças, por entregar mais valor frequentemente para o cliente, focando-se em maximizar o retorno do seu investimento, por evitar o desperdício e por priorizar a comunicação e visibilidade ao que é importante para o bom andamento do projeto, de forma que todos saibam o que deve ser feito e o que está sendo feito em cada momento.

Oferecemos diversos argumentos para que pessoas com poder de influência ou decisão possam ajudar a decidir pelo uso de Scrum em suas organizações.

Uma vez superada a crise, as organizações que tiverem adotado Scrum estarão mais próximas do cliente, focadas em resultado, enxutas, objetivas e transparentes. Assim, para estas organizações, a crise terá funcionado como mola propulsora, de forma que, no momento da recuperação do mercado, estas organizações largarão à frente de sua concorrência.

Referências

Associated Press, 01/04/2009
IDG News Service/EUA, 14/01/2009
Jornal Valor Econômico, 17/04/2009, 22/04/2009 e 24/04/2009
Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game. Addison Wesley.
Kniberg, Hernik (2007). Scrum and XP from the Trenches. Lulu.com.
Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison Wesley.
Schwaber, Ken; Beedle, Mike (2002). Agile Software Development with Scrum. Prentice Hall.
Schwaber, Ken (2004). Agile Project Management with Scrum. Microsoft Press.
Schwaber, Ken (2007). The Enterprise and Scrum. Microsoft Press.

Sobre os Autores

Rafael Sabbagh, CSM - é Engenheiro de Computação graduado na Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) e tem MBA em Gestão Empresarial. Seu histórico inclui sete anos de experiência em gerência de projetos de TI e liderança de equipes de desenvolvimento.
Ele é Certified ScrumMaster e tem trabalhado nessa função neste último ano. Ele está cursando o Mestrado em Administração na PUC-Rio e sua dissertação é sobre o uso de Scrum e valores ágeis no Brasil. Website: http://scrumability.net

Marcos Garrido, CSPO - é Tecnólogo em Ciência da Computação graduado na Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) e tem MBA em Gestão Empresarial. Seu histórico inclui seis anos de experiência em gerência de projetos de TI e liderança de equipes de desenvolvimento.
Ele é Certified Product Owner e tem trabalhado nessa função neste último ano. Ele está cursando o Mestrado em Administração na PUC-Rio e sua dissertação é sobre percepções de clientes em projetos que utilizam Scrum no Brasil. Website: http://scrumability.net

BNDES: Dinheiro tem. Faltam empreendedores no Brasil

2011-09-30T17:35:00.000-04:00

Ao participar do Rio Info 2011, nesta terça-feira, 27/09, o vice-presidente do BNDES, José Carlos Ferraz, tocou numa ferida do setor de TIC. Disse que a instituição está apta a investir em projetos da área, mas lamentou o pouco foco em inovação por parte das companhias.

Durante a sua apresentação, Ferraz admitiu que o momento econômico mundial é grave - e a situação crítica deverá perdurar por alguns anos - mas salientou que o Brasil, depois de ter sofrido tantos problemas internos, está mais fortalecido para enfrentar uma possível recessão. "Mas temos que investir muito em inovação. O Brasil tem uma oportunidade sem igual, mas precisa saber que a disputa será muito acirrada", destacou.

Em entrevista à CDTV, do Portal Convergência Digital, o vice-presidente do BNDES ressaltou que as mudanças no Prosoft - projeto de incentivos ao software onde 327 projetos já foram beneficiados - serão para aperfeiçoar o modelo. "Posso garantir que tudo virá para melhorar. TIC é uma área prioritária", afirmou.

Mas foi bastante crítico com o setor: "Dinheiro o BNDES tem, mas faltam projetos empreendedores. Temos que inovar muito mais". Ferraz também não hesitou em afirmar que se as empresas nacionais não aproveitarem o momento, as companhias entrantes - leia-se capital internacional - vão ocupar o espaço, uma vez que há o potencial de negócios. Acompanhe a entrevista de José Carlos Ferraz à CDTV, do Convergência Digital.

Via Convergência Digital

Livro Gestão de Produtos com Scrum

2011-09-30T09:13:00.001-04:00

Quem é Product Owner raramente encontra livros e apresentações sobre a gestão de produtos, práticas e ferramentas com os métodos ágeis.
A grande maioria dos livros disponíveis são sobre o Scrum de modo geral e outros métodos ágeis, mas não focam no trabalho do PO.
Contudo, acaba de ser lançado um livro, em português, que o foco é a Gestão de Produtos com Scrum do autor Roman Pichler, é dos poucos livros que é voltado para os Product Owners.

Gestão de Produtos com Scrum - Implementando Métodos Ágeis na Criação e Desenvolvimento de Produtos
- Prefácio de Jeff Sutherland (um dos criados do Scrum)
ISBN: 8535248072
Edição: 1ªAno de Lançamento: 2011
Número de páginas: 176
Editora: Campus
Preço: R$ 48,00

Conteúdo:
1 - Entendendo o papel do Product Owner
2 - Criando a visão para o produto
3 - Trabalhando com Product Backlog
4 - Planejando o release
5 - Colaborando nas reuniões de Sprint
6 - Transição para o papel de Product Owner.

Resumo:
Neste livro, o autor apresenta exemplos reais sobre como os 'Product Owners' podem criar produtos bem-sucedidos adotando as técnicas de gerenciamento ágil de projetos. Ele descreve diversas práticas, incluindo como fazer funcionar o trabalho de descoberta ágil do produto, criar o produto mínimo comercializável e aproveitar o máximo o feedback do cliente.
É demonstrado uma comparação entre o processo ágil de criação de produtos e o processo de criação de produtos tradicional e como evitar e resolver os problemas e desafios comuns que os 'Product Owners' enfrentam no dia-a-dia.

Software pouco competitivo

2011-09-29T17:25:00.001-04:00

Grande parte das empresas brasileiras de software demora muito a perceber a mudança dos ventos

O MERCADO de software e serviços de TICs deve chegar a R$ 63 bilhões em 2011.

Software pouco competitivo

O MERCADO de software e serviços de TICs(Tecnologias da Informação e Comunicação) deve chegar a R$ 63 bilhões em 2011. E a taxa de crescimento anual, até 2020, deve ser o dobro da do aumento do PIB (Produto Interno Bruto).
Essas boas notícias (no link bit.ly/pV0ZDQ) seriam ainda melhores se não revelassem, também, que 97,3% das 75 mil empresas do setor empregam de 5 a 19 pessoas e que só 0,5% do total tem mais de 50 colaboradores. Ah, e que as margens do setor -no país- vêm diminuindo ano a ano.
Tem mais: o Brasil não está se tornando mais competitivo no mercado internacional e, depois de 20 anos tentando, exportamos apenas 5% do que exportam os indianos (veja em bit.ly/o3Ntrm). Sem falar que boa parte disso advém dos negócios internacionais das filiais nacionais de empresas globais.
As razões que levam a tal conjuntura são muitas e, como pode-se imaginar, passam pelos problemas estruturais da falta de competitividade nacional em quase tudo o que não é commodity.
É aí onde entra o título do texto: a vasta maioria das empresas nacionais de software está perigosamente perto de se tornar commodity no mercado errado. Isso significa escrever linhas de código e software genérico, manter sistemas e serviços indiferenciados que, podendo estar em qualquer lugar do planeta graças à internet, irão para onde for mais barato, desde que haja um mínimo de confiança.
Como os padrões de desenvolvimento, operação e gestão de TICs são globais, vai ser difícil ver tais coisas por aqui, face à nossa já mencionada falta de competitividade.
O risco, claro, é a comoditização da empresa nacional de software. O que é dito com todas as letras pelo BNDES (no link bit.ly/rksnsS), ao revelar que não falta dinheiro para financiar novos empreendimentos, mas projetos e propostas inovadoras.
É preciso considerar que o tipo, a forma e a celeridade dos recursos do BNDES não são os mesmos que os do mercado internacional de capital empreendedor para software e serviços. Mas o banco tem razão: estamos sofrendo, e não é de hoje, de escassez de criatividade e inovação. E, como se não bastasse, de baixa capacidade empreendedora.
A combinação desses três deficit é quase sempre fatal para qualquer novo negócio. E quase nunca vai gerar um novo negócio inovador de crescimento empreendedor -as empresas que, depois de um tempo de gestação, têm crescimento quase exponencial de receita, seguido por outro, menos agudo, de despesas.
Para ter uma ideia do que isso significa, é bom olhar (no link bit.ly/n372CN) o que acontece com a Amazon.com, que ainda está crescendo a 50% ao ano.
Quase todo negócio está no negócio de software (também) porque seus processos precisam ser codificados para serem executados e acompanhados.
Isso é ainda mais verdade nas empresas distribuídas, onde o dono não vê, o tempo todo, o balcão e o caixa. A maior parte das empresas brasileiras de software está no negócio de, sob demanda, codificar outras empresas. E é daí que vem sua comoditização e diminuição de lucratividade recente. Mas essa nem é a ameaça principal.
Software está se tornando serviço, via provedores como Salesforce.com. Mais empresas e pessoas vão usar mais software, mais sofisticado e de desenvolvimento mais complexo, porque sujeito a novos parâmetros de performance, experiência de uso, segurança e resiliência.
Ao mesmo tempo, tal "informaticidade" (veja no link bit.ly/aT96C1) vai padronizar processos e o próprio software, comoditizando não seu desenvolvimento, mas seu uso. E o resultado será menos empresas pequenas escrevendo repetidamente o "mesmo" software, a "mesma" folha ou contas a pagar.
Isso deve recriar a economia global de software -agora como serviço- numa nova escala -global- de desenvolvimento, utilização, agregação e captura de valor.
Em sua quase totalidade, as empresas brasileiras de software demoram muito a perceber a mudança dos ventos e, nessa virada, não será surpresa se, em vez de se tornarem commodity, boa parte daquelas 97,3% se torne, simplesmente, extinta.

SILVIO MEIRA, conselheiro do CDES, fundador do www.portodigital.org e cientista-chefe do www.cesar.org.br.

Publicado na Folha de S.Paulo

10 questionamentos para o futuro empreendedor

2011-09-27T22:11:00.001-04:00

Tornar-se dono do próprio negócio é o sonho de muita gente. Muitos planejam atingir esse objetivo ao longo de anos de carreira corporativa, loucos para se livrar das amarras do escritório, da imposição de chefes, das intermináveis reuniões que muitas vezes não levam a lugar algum.

Porém (e sempre existirá um porém), ser empreendedor não é necessariamente um passeio pelo bosque encantado. Trata-se, antes de tudo, de uma atividade que envolve risco, perseverança, demandando coragem, disciplina e, sobretudo, uma atitude de vida profissional absolutamente distinta daquela exigida para um emprego comum.

To be or not to be?

Cientes disso, elaboramos dez autoquestionamentos para que o futuro empresário possa confrontar seus sonhos com a concreta realidade.
Vamos lá:

1º Questionamento: Estou preparado para assumir integralmente a responsabilidade pela minha geração de renda e sustento, como resultante daquilo que é gerado pelo meu próprio negócio?

2º Questionamento: Estarei satisfeito e realizado ao abdicar do status que a minha posição corporativa garantia?

3º Questionamento: Estou preparado para viver rigorosamente dentro da minha realidade econômica, construindo um colchão de segurança financeira a partir da contenção das despesas pessoais e da redução do consumo habitual?

4º Questionamento: Tenho paciência para enfrentar uma jornada de médio a longo prazo de trabalho duro e convivência com riscos, antes de atingir solidez econômica e satisfação financeira?

5º Questionamento: Conseguirei conviver com serenidade longe do “glamour” corporativo e dos jogos de poder travados nos corredores e salas de reunião?

6º Questionamento: Estou preparado para enfrentar uma jornada diária de trabalho sem horários definidos para seu início ou término?

7º Questionamento: Estou emocionalmente maduro para pensar e decidir por conta própria, sem o apoio de chefes, colegas e consultores motivacionais?

8º Questionamento: Pretendo me tornar empreendedor pelo desejo de tornar-me rico ou pelo anseio de realizar e assumir o controle do meu próprio destino?

9º Questionamento: Serei feliz na solidão que envolve controlar o próprio destino e ser o centro das decisões vitais da minha vida empresarial?

10º Questionamento: Estou preparado para trabalhar com a mínima estrutura de suporte, assumindo com tranquilidade as tarefas que antes eram delegadas para secretárias, assistentes ou estagiários?

Por Gustavo Chierighini, da Plataforma Brasil

Texto parte da coluna da Plataforma Brasil feito para os leitores do blog Saia do Lugar.

Lean Startup substitui ou complementa o Agile?

2011-09-27T11:19:00.001-04:00

Joshua Kerievsky iniciou um intenso debate em um post recente, no blog da Industrial Logic, intitulado "Agile vs Lean Startup". Ele declara que Lean Startup é melhor que Agile e apresenta uma tabela contrastando vários aspectos das filosofias Agile e Lean Startup, reproduzida a seguir.

Agile	Lean Startup
Roadmap do Produto	Business Model Canvas
Visão do Produto	Adequação do Produto ao Mercado
Plano de Release	Mínimo Produto Viável
Sprint	Kanban
Revisão do Sprint	Pivot ou Persevere Decision
Cliente On-Site	"Saia do prédio"
Histório do Usuário	Hipótese
Backlog	Lista "Para aprender"
Definição de Pronto	Aprendizagem Validada
Vermelho-Verde-Refatore	Aprenda-Meça-Construa
Feedback do Cliente	Validação do Cliente
Teste de Aceitação	Teste de Separação
Velocidade	A A R R R (Aquisição, Ativação, Retenção, Referências, Receitas)
Objeto de Simulação	Funcionalidade Falsa
Integração Contínua	Implantação Contínua
Certified Scrum Master	Gerente de Sucesso do Cliente

Abby Fichtner do Hacker Chick Blog republicou a tabela, fazendo o seguinte comentário:

Em Agile, medimos o progresso com a Velocidade. Perguntamos "quanto software desenvolvemos esta semana?" Já o Lean Startup diz: "quem liga o quanto de software desenvolvemos na semana. O importante é saber quantas pessoas compraram o produto ou utilizaram nosso software".

O post gerou pelo menos outro post contestando a natureza de Agile vs Lean Startup, fazendo referência à tabela de Kerievsky. Todd Charon no blog Planning for Failuredesafiou a premissa básica do post original:

Não faz sentido a comparação Agile versus Lean Startup. Não faz sentido afirmar que são opostos de alguma maneira, e que se deve escolher entre os dois, ou convencer as pessoas de que o Lean Startup é superior ao Agile. Isso é mais prejudicial do que benéfico para as comunidades Agile e Lean Startup.

Charon passa a discutir cada uma das comparações na tabela e sustenta que não são conceitos antagônicos e sim complementares. Mostra-se especialmente preocupado com a percepção de que Lean Startup seja de alguma forma um substituto do Agile, o que prejudicaria a comunidade de desenvolvimento de software em geral:

Digamos que você é um agente de mudanças e está tentando introduzir Agile em uma organização waterfall, nos dias que antecederam a onda do Lean Startup. Está começando a progredir, mas ainda encontra resistências. Então de repente você se vira e exclama "Lean Startup é um caminho melhor que Agile, vamos pular para a nova tendência!". Qual a credibilidade terá? E para os que falavam "Agile é apenas uma moda passageira", quando ouvem que o Lean Startup é muito melhor, vão dizer "Eu te disse, esta moda também é passageira. Não há razão para mudar."

E se você está tentando introduzir uma abordagem Lean Startup, boa sorte ao conseguir implantar práticas de desenvolvimento sólidas. Você provavelmente vai ouvir algo como: "Não precisamos de Agile, Lean Startup é muito melhor. Não precisamos de integração contínua ou TDD, simplesmente vamos entregar." Ou mesmo, "ontem vocês estavam vendendo Agile, agora é Lean Startup. Vocês são todos uns picaretas..."

Todd Charon termina com um apelo para que se adote a perspectiva de que Agile e Lean Startup são realmente complementares e que o Lean Startup pode levar times Agile para além da nota máxima em agilidade.

Postado por Shane Hastie , traduzido por Paulo Rebelo em 26 Set 2011 no InfoQ

Lean Startup impulsiona nova onda de empreendedorismo no Brasil

2011-09-02T11:00:00.000-04:00

O software vai dominar o mundo. É o que defende o empreendedor Marc Andreessen em um recente artigo publicado no The Wall Street Journal. O executivo dá exemplos de empresas como Google, Apple, Facebook, Linkedin e Netflix que, além de sua relevância no mercado de capitais, estão tomando espaços importantes na economia, antes dominados por empresas de DNA não tecnológico. No meio desta revolução, os EUA continuam líderes devido à combinação (sem paralelo) de boas universidades, cultura de negócios pró-risco, respeito a contratos e grande quantidade de capital de risco buscando inovação e negócios confiáveis.

Apesar da liderança norte-americana, aqui no Brasil passamos por uma era de ouro de startups de tecnologia. Para aproveitar esse cenário, os empreendedores contam hoje com uma ferramenta resultado de 10 anos de aprendizado após o final da bolha de tecnologia dos anos 90. Trata-se do Lean Startup, conceito já comumente utilizado nos Estados Unidos e criado pelo norte-americano Eric Ries. De forma simplificada, pode-se dizer que é fazer startups com pouco desperdício e ciclo de aprendizado rápido, a partir de duas práticas: o desenvolvimento de clientes (customer development, criado por Steve Blank) e o uso de metodologias ágeis para desenvolvimento de software.

Considerado o aspecto mais revolucionário da prática, o customer development consiste em três passos iniciais: o primeiro é buscar um modelo de negócio no qual o produto seja adequado ao mercado; o segundo é evoluir e trabalhar o processo de venda até que ele se torne repetível e o empreendedor esteja seguro e confortável para utilizá-lo; e o terceiro é contratar gestores que sejam capazes de dar andamento ao processo de crescimento da empresa, que neste ponto busca escalar rapidamente o modelo de sucesso e se apropriar da oportunidade. Ao fim das três fases, que se “encaixam”, a empresa está pronta para executar o modelo de negócios.

Após 13 anos de experiência, passagem pelas duas bolhas e 17 tentativas com erros e acertos, chegamos a um modelo que consideramos, hoje, o mais adequado para empreender em TI. Primeiro, descobrimos que deveríamos abandonar as premissas de que sabemos qual é a necessidade do cliente e como atender essa necessidade. Com elas, utilizávamos métodos tradicionais de lançamento de produtos (como waterfall e, depois, unificado) nos quais elaborávamos cada fase do processo de forma sequencial. Para agir de maneira mais rápida e evolutiva, optamos pelos métodos ágeis, que têm no SCRUM seu principal representante. O SCRUM é uma forma empírica de criar software sem desperdícios. Com a metodologia, os projetos não têm escopo rígido e cada etapa é construída de forma evolutiva, com cliente e fornecedor atuando conjuntamente.

Porém, apesar de endereçar o espaço da solução, a adoção de metodos ágeis não ajudava a entender o problema. Precisávamos também de desenvolvimento do cliente, o que, no processo de busca do modelo de negócios, significa responder a uma série de questionamentos, como para quem vender, o que e como oferecer, quais serão as relações que teremos com os clientes, quanto eles estarão dispostos a pagar pelo serviço, quais serão os recursos de que precisaremos e quais deles serão essenciais, quais atividades serão cruciais para desenvolvimento do negócio, quem serão os parceiros e fornecedores que vamos precisar e, por fim, qual é a estrutura de custos que teremos. Após alcançar as respostas para essas perguntas, temos o modelo de negócio. Para colocá-lo em prática, usamos o SCRUM.

A soma de tudo isso é a prática de Lean Startup que, associada ao uso de ferramentas open source e cloud computing, é considerada atualmente a melhor forma de estruturar um novo negócio de tecnologia. Os modelos de open source e de cloud computing democratizaram o espaço de competição, eliminando a necessidade de investimentos na infraestrutura computacional e dando uma adaptabilidade fluida a esta estrutura, que se adapta perfeitamente ao negócio.

Sem esquecer, é claro, a evolução das pessoas. Isso porque o sucesso não depende apenas do empreendedor, é fundamental que haja um alinhamento de interesses do time como um todo. É importante estimular constantemente a equipe, tornando-a parceira, inclusive com divisão dos lucros. Outro ponto a ser destacado é o DNA do empreendedor, que deve combinar adaptabilidade com resiliência. É preciso muito esforço, leitura e conversas. A máxima “a verdade está fora do escritório” é uma realidade. Se quiser empreender, converse com muitas pessoas e ouça opiniões para criar um negócio com “robustez”, que possa ser transformado em outro se necessário. É a troca do “plano A” pelo “plano que funcione”, como aconselha Ash Maurya.

Por fim, sugiro algumas referências teóricas para candidatos a empreendedores. Os livros “The four steps to epiphany”, de Steve Gary Blank; “Running Lean”, de Ash Maurya; e “Business Model Generation”, de Alexander Ostwalder, são bases importantes, além do “The Lean Startup”, de Eric Ries, que será lançado em setembro deste ano. Apresentações de Steve Blank no slideshare e blogs como www.businessmodelalchemist.com, www.startuplessonslearned.com e theleanstartup.com também podem ajudar. Boa sorte em seu novo negócio!

* Fernando de la Riva é sócio-fundador e diretor-presidente da Concrete Solutions, consultoria global de tecnologia da informação especializada no desenvolvimento de negócios digitais. Foi CEO de transição e COO da Teknoland do Brasil e fundador da Atness Computing Services, empresa que foi adquirida pela Teknoland RTT, companhia espanhola de TI e internet do Grupo Terra/Telefônica. Bacharel em Engenharia da Computação pela PUC-RJ, pós-graduado em gestão empresarial pela COPPEAD, MBA pela Columbia Business School e mestrado pela London Business School.

Via SEGS

Outras boas fontes sobre o assunto pode ser encontradas nos links a seguir:

Comportamentos da geração Y impedem crescimento profissional

2011-08-31T09:05:00.001-04:00

A geração Y, nascida a partir de 1978, mudou a dinâmica do mercado de trabalho -- que ficou mais antenado e flexível.

Algumas características desses jovens profissionais, contudo, não agradam a todos e até prejudicam a carreira de quem não sabe lidar com elas, afirmam consultores.

"O mercado aceita [alguns comportamentos do jovem] porque não há mão de obra qualificada", afirma o "coach" Alexandre Prates.

O mercado de trabalho aquecido e mais competitivo faz com que integrantes da geração Y não percebam que, se não mudarem alguns aspectos, podem colocar a carreira em risco, destaca o consultor.

Comportamentos como dinamismo em excesso, urgência em crescer e pressa em atingir resultados são considerados positivos, se bem dosados.

"Tem muito jovem com potencial, mas com muita ânsia de crescer, o que o faz atropelar os acontecimentos", considera Marisa da Silva, consultora de carreira da Career Center.

Sem limites, jovens profissionais deixam de fechar ciclos nas empresas. "O mundo corporativo tem um tempo diferente, e eles precisam entender que é preciso um tempo para chegarem lá, que não é em um click", afirma Alexandra Morgado, gerente de treinamento e desenvolvimento da Personal Service, de consultoria.

SEM HISTÓRIA
Dentre as características que podem barrar a carreira da geração Y, segundo especialistas consultados, está o ímpeto em ocupar os melhores cargos no menor espaço de tempo possível. "Com isso, eles não têm crescimento sustentável e não adquirem conhecimento prático e concreto do negócio", afirma Silva.

O "foco excessivo" na carreira, afirma Prates, também é fator que prejudica os jovens profissionais. "Falta comprometimento nessa geração. Ela não se apaixona pela empresa e pelo trabalho."

A dificuldade em lidar com os próprios fracassos profissionais pode impedir ascensões mais seguras. "Isso é falta de vivência profissional, de criar uma história em uma empresa", avalia Morgado.

"Com maturidade e vivência, ele consegue tomar decisões, ser mais autoconfiante e se frustrar menos", enfatiza Morgado.

Via CAMILA MENDONÇA da Folha.com

Um dia na terra do Kanban

2011-08-23T19:22:00.001-04:00

Essas tirinhas foram postadas pelo Henrik Kniberg, autor do livro “Scrum e XP direto das Trincheiras“, em seu blog.

É uma historinha bem humorada do dia a dia de negociações com nossos Product Owners.

Tentei fazer uma tradução livre para o português. O post original pode ser visto em:One day in Kanban land

Via André Dourado – Ad Systems

Google apresenta projeto na Feira do Empreendedor de MT

2011-08-19T11:42:00.001-04:00

Realizada em parceria com o Sebrae, a ferramenta Conecte seu Negócio permite ao empresário criar site com baixo custo

Da Agência Sebrae de Notícias

Produzir, vender, atender e divulgar o negócio são atividades cotidianas na vida do empreendedor. Com tantas atribuições, é comum faltar tempo e dinheiro para cada uma das fases do processo e, via de regra, a mais afetada é a divulgação. O Google criou a ferramenta “Conecte seu Negócio” para que o empresário construa seu primeiro site. Rodrigo Furtado, gerente de Marketing da empresa no Brasil, falou na Feira do Empreendedor na quinta-feira (18/8) da ferramenta, que no país conta com parceria do Sebrae.
O “Conecte seu Negócio” já foi lançado em 15 países. A participação na Feira do Empreendedor em Mato Grosso é o primeiro de um circuito de seis eventos que o Google vai participar ainda este ano no Brasil. Por meio da ferramenta, o empreendedor pode ter o registro do domínio, a produção do site e a hospedagem por um ano ao valor de R$ 29,95. Para celebrar a parceria, mil sites gratuitos estão sendo oferecidos exclusivamente aos participantes da Feira do Empreendedor de Mato Grosso.
Lançada há apenas um mês no Brasil, a ferramenta digital ainda não disponibiliza estatísticas, mas os resultados estão além das expectativas, segundo Furtado. Mais informações sobre o produto podem ser obtidas neste site. "O sistema é tão simples que o empresário pode criar o site de sua casa, no seu próprio computador”, explica.
Com expectativa de receber 20 mil visitantes, a Feira do Empreendedor 2011 é realizada pelo Sebrae em Mato Grosso no Centro de Eventos do Pantanal, em Cuiabá, até o próximo domingo (21/8).

Acesse: http://www.conecteseunegocio.com.br/

Via Pequenas Empresas & Grandes Negócios

10 licoes sobre como falar com um investidor

2011-08-15T10:28:00.000-04:00

10 licoes sobre como falar com um investidor

View more presentations from Felipe Matos

Scrum no desenvolvimento de sites e ações de Marketing Digital

2011-08-15T09:26:00.000-04:00

Metodologia ágil de gerenciamento de projetos é implementada por web designers e analistas de redes sociais

Quadro de tarefas do Scrum

Scrum é um método de gerenciamento de projetos muito usado atualmente pela TI de diversas empresas para o desenvolvimento de softwares, mas que tem um recente crescimento em áreas como Web Design e Marketing Digital(mídias sociais).

A metodologia ágil Scrum atua no sentido deaumentar o ROI (retorno sobre investimento ou relação custo-benefício) de um projeto. Através dele, é possível dividir as etapas de construção de um Web Site, por exemplo, priorizando as entregasde acordo com o valor agregado que a parte finalizada trará ao cliente, elevando sua satisfação.

Nos métodos gerenciais tradicionais como o PMBOK/PMI, o escopo (conjunto de funcionalidades do produto) é fechado, muitas vezes pela força de um contrato. A flexibilidade fica com a qualidade (mais rápido = pior qualidade e mais bugs), custo (mudança no projeto = preço mais caro) e prazo (novas funções = adiamentos e atrasos constantes).

Já no Scrum, o escopo é flexível, pois parte-se da ideia de que o cliente não é capaz de definir tudo o que deseja antes de começar a usar um software ou site. Ao final de uma sprint (trabalho que dura de 1 a 4 semanas) é entregue uma parte de um portal, por exemplo. Isto permite que o cliente dê um melhor feedbackpara os deselvolvedores, que, por sua vez podem entregar as funcionalidades que mais vão agregar valor ao projeto.

No final, muitas das funções pensadas inicialmente não serão implementadas, porque ao longo do projeto foram preteridas, perdendo importância. Outras surgirão e serão priorizadas, pois, no momento, incrementam mais o ROI. Desde o início de um projeto, o cliente já recebe partes do produto, que vai sofrendo um processo de melhoria contínua ao longo das sprints.

Do início ao fim, o que se vê é software, produto concreto, e não papel, levantamento de requisitos, burocracia. Esta é a filosofia do Manifesto Ágil.

Equipe multidisciplinar e auto-organizada

A equipe de um projeto Scrum deve ser composta por um grupo multidisciplinar de profissionais, que, a partir datroca de experiências e conhecimentos, podem crescer juntos com o desenvolvimento do produto.

Cabe ao Scrum Master ajudar a equipe a trabalhar. Ele não é o chefe tradicional, que dá ordens, manda e delega tarefas. O Scrum Master organiza as reuniões de planejamento (Sprint Planning) e revisão (retrospective e Sprint review), além do feedback diário (stand-up daily meeting). O próprio time distribui as tarefas e escolhe a maneira de executá-la (pair programming ou individualmente).

Já o Product Owner (dono do produto) é a figura responsável por aprovar ou rejeitar as entregas de partes de um site ao final de uma sprint. O PO quebra o projeto em histórias (stories ou épicos) e as prioriza, de acordo com a visão do negócio em que está inserido o projeto. E o Scrum Master, junto com a equipe, divide uma história em tarefas. Tudo para elevar o valor agregado do produto (website, aplicativo mobile ou software).

Ainda vou falar muito de métodos ágeis de gerenciamento de projetos como XP (eXtreme Programming), Scrum e Kanban. Termino aqui com a lista dos quatro pilares do Manifesto Ágil:

Indivíduos e interação entre eles mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Via Arturo Ilha

Adoção de Scrum: rigidez em excesso?

2011-08-11T10:37:00.001-04:00

Excelente artigo de Vikas Hazrati que coloca em questão a rigidez dos processos e responsabilidades dos papéis do Scrum, levando-nos a perguntar se é o framework em si que é rígido quanto a isso ou se é quem o implanta, principalmente em equipes inexperientes no mundo Agile, que é rígido?

O Scrum é visto como uma metodologia de desenvolvimento de software flexível e adaptável, que foca na melhoria do processo de desenvolvimento e à qual houve vários casos de sucesso atribuídos. Contudo, muitas equipes continuam a sentir um grau de inflexibilidade e rigidez. O problema seria do Scrum ou da maneira como vem sendo adotado?

Terry Bunio, na sua carta ao Scrum conta como se encantou inicialmente com os processos e procedimentos do Scrum. Aos poucos, no entanto, percebeu que a rigidez do framework não dava a liberdade necessária para o sucesso dos seus projetos.

Eu precisava de um processo ao qual pudesse adicionar tarefas e requisitos durante o sprint quando isso fizesse sentido. Não queria estar limitado pela duração das retrospectivas, se achasse que havia mais para ser discutido… não gostava de ser chamado de Scrum Master. O papel parecia diminuir o meu valor como gerente de projetos, tornando-me apenas um guardião do processo, ao invés de um membro importante. Sentia-me como se não fizesse mais parte da equipe.

Marek Blotny, demonstrou sentimento similar sobre as práticas dos standups diários. Blotny diz não gostar da ideia de membros da equipe ficarem “parados” aguardando a sua vez de falar. Isso acaba, de acordo com ele, com o compartilhamento espontâneo de conhecimento. Blotny também menciona que às vezes o limite de 15 minutos atrapalha. De acordo com ele, se uma boa discussão estiver acontecendo e toda a equipe estiver envolvida, a discussão deveria continuar.

Se me perguntassem se faz sentido impor uma estrutura rígida como as reuniões diárias, responderia que definitivamente não. Pode haver reuniões diárias úteis e efetivas que incentivam o trabalho em equipe – ou uma estrutura rígida em que se que seguem as regras estritamente.

Rod Claar diz que, embora o Scrum seja flexível, as equipes que o adotam pela primeira vez tendem a torná-lo mais rígido na tentativa de acertar com o Scrum já na primeira tentativa. Rachel Davies também destaca essa tendência:

Fico alarmada quando ouço falar de Scrum Masters ou de equipes tentando utilizar “Scrum como manda o manual”. Scrum é o ponto de partida da jornada de uma equipe pelo processo ágil de desenvolvimento; utilizá-lo não é o objetivo final. O Scrum é usado para entregar incrementos do produto. Nunca virão investigar se o trabalho de sua equipe está em conformidade com o Scrum.

Geoffrey Wiseman adiciona que a rigidez no processo e a agilidade não são necessariamente coisas opostas. O processo pode definir que não deve haver interferência depois que um sprint é iniciado. O sprint pode ser visto como padrão para planejamentos e implementações, mas é definitivamente aberto e flexível.

Este seria um caminho difícil de seguir? Talvez sim. Alguns vão argumentar que, se não é possível conviver com essas limitações, não se deveria utilizar o processo. Mas acredito que, na prática, um sprint pode sim sobreviver a uma realocação momentânea de recursos.

As consequências da rigidez do processo são tão fortes quanto a equipe quiser que sejam. Embora inserir algumas limitações possa impedir que todo o processo acabe no caos, ser rígido demais, ignorando condições práticas, é prejudicial tanto para a equipe quanto para o projeto

Via Vikas Hazrati, traduzido por Alex Chiaranda em InfoQ

PhoneGap chega à versão 1.0, expandindo o desenvolvimento multiplataforma para mobile

2011-08-11T09:53:00.000-04:00

Durante o evento PhoneGap Day, no final de julho, em Portland (EUA), foi anunciada a versão 1.0 do PhoneGap, um framework de código aberto para desenvolvimento de aplicações móveis com suporte a sete das principais plataformas mobile no mercado e suas lojas virtuais.

O PhoneGap possibilita criar e publicar aplicações para iOS, Android, Symbian, Windows Mobile, WebOS, BlackBerry OS e Bada (e em breve Windows Phone), através de tecnologias como HTML, CSS e JavaScript. O framework cria uma aplicação nativa para o dispositivo móvel, permitindo acesso a recursos nativos como GPS ou acelerômetro.

Baixado cerca de 40 mil vezes por mês, o PhoneGap já contabilizou mais de 600 mil downloads. Entre os destaques deste release em relação a versões beta já em uso, estão:

Aumento de estabilidade da API e uma arquitetura “plugável” pemitindo a criação de extensões a API quando necessário.
Compatibilidade com a API de acesso a dados definida pelo W3C
API de manipulação de contatos
Ferramentas para depuração remota

Além destes destaques, o framework disponibiliza uma API unificada para desenvolvimento de aplicações em todas as plataformas suportadas. Entre os recursos oferecidos via APIs, estão:

geolocalização, permitindo consulta instantânea e notificação quando a posição é alterada.
recursos multimídia, permitindo captura e reprodução de áudio, vídeo e fotos
integração com o sistema notificações e o sistema de avisos do dispositivo
storage, simulando um banco de dados SQL ou utilizando o próprio SQLite quando disponível
local storage, que facilita o armazenamento local de configurações ou poucos dados, no estilo "chave=valor"
acesso a informações sobre o dispositivo, como estado da conexão, modelo e eventos do ciclo de vida da aplicação.

A release 1.0 também inclui uma nova forma de implementação que tornará mais fácil a adição de novas plataformas em futuras versões.

O PhoneGap já está sendo utilizada por grandes empresas. A Adobe, por exemplo, integrou o framework ao DreamWeaver, tornando possível criar aplicações PhoneGap e testar em emuladores iOS e Android diretamente a partir do editor. Também existe um acordo entre a Apple e equipe do PhoneGap, que permite a publicação de aplicações desenvolvidas com o framework na Apple App Store.

Para as próximas versões, está planejado o suporte a outras plataformas e novas APIs, para acesso a funcionalidades como calendário, websockets e criptografia, entre outras. Mais detalhes sobre o projeto e os planos da equipe podem ser conferidos no roadmap.

Via Rodrigo Urubatan em InfoQ

Lei reduz imposto para contratar programador

2011-08-10T15:33:00.001-04:00

Uma nova regra apresentada pelo governo federal no início do mês pretende reduzir os impostos de quatro setores que contratam funcionários em regime CLT. O plano promete aumentar a formalidade e deixar o setor de TI mais competitivo. O plano Brasil Maior atende reivindicações de companhias que dizem concentrar mais de 70% dos custos somente com folha de salários.

Até dezembro de 2012, alguns setores podem gastar menos para manter profissionais com carteira assinada. O projeto pretende desonerar a carga tributária sobre a folha de pagamento de empresas na área calçadista, têxtil, de móveis e de software. Esta medida entra em vigor dentro de 90 dias e valerá até dezembro de 2012. Segundo Nelson Barbosa, secretário-executivo do Ministério da Fazenda, a desoneração para os quatro setores funcionará como um projeto-piloto.

O Plano Brasil Maior, anunciado no dia 02 de agosto pela presidenta Dilma Rousseff, isentará a alíquota de INSS em troca de uma contribuição de 2,5% sobre o faturamento das empresas. Em entrevista ao INFO Online, Antonio Carlos Rego Gil, presidente da Brasscom (Associação Brasileira de Empresas de Tecnologia da Informação e Comunicação), os profissionais e empresas da área de TI esperam desde sempre receber incentivos e tornar o setor competitivo.

Após a apresentação do plano, pode haver um aumento na formalidade de profissionais da área de TI. Se isso acontecer, haverá maior arrecadação de imposto de renda. “O plano barateia a contratação da mão de obra das empresas, que representa 70% dos custos na área de TI. Os encargos sobre a folha de pagamento tornam a mão de obra brasileira uma das mais caras do mundo”, diz Gil.

Ainda segundo o presidente da associação, o alto custo para a contratação inviabiliza tornar o Brasil um pólo de exportação de TI e também afeta a produtividade. Diante deste cenário, algumas empresas contratam profissionais fora do regime CLT.

“Cerca de 50% da força de trabalho de TI no Brasil carrega algum grau informalidade. As empresas contratam profissionais com registro de PJ e também regimes flex de contratação”, comenta o presidente da associação.

“Isso prejudica quem contrata funcionários com carteira assinada, pois as empresas formadas por profissionais autônomos competem em vantagem e desigualdade ética". Vale lembrar que os profissionais em regime ‘freelance’ não recebem a totalidade de seus direitos trabalhistas.

Segundo o presidente da Brasscom, as empresas menores não inovam nem investem na produção devido ao alto custo e concorrência desleal. “As empresas que contratam por PJ, ou que usam formas não ortodoxas de pagamento, não conseguem linhas de crédito e isso restringe o crescimento destas companhias brasileiras”.

“A recepção do projeto pelo setor de TI foi muito positivo”, afirma Gil. Em informe publicitário divulgado no jornal Folha de S. Paulo do dia 04 de agosto de 2011, a Brascomm diz que era preciso corrigir o problema agudo da informalidade no setor e afirma que o plano é uma revolução no setor de software e serviços de TI.

Gil lembra que o incentivo vai além da desoneração. "Há também oportunidade de treinamento de oito milhões de pessoas em todos os níveis técnicos a custos reduzidos por meio do programa "Pronatec. Além disso, o governo federal oferecerá 75 mil bolsas de estudo em universidades no exterior para alunos do ensino superior ao pós-doutorado por meio do programa "Ciência Sem Fronteiras".

A Brasscom acredita na criação de 750 mil vagas de emprego até 2020. "Esta meta pode ser ultrapassada pois o mercado brasileiro é grande e o país é muito bom em TI", diz Gil. Para exemplificar, o presidente da associação cita como exemplos bem sucedidos os sistemas bancários, a tecnologia usada na agricultura, em pesquisas de petróleo e também urnas eleitorais. "Especificamente no caso da urna eleitoral, não há sistema similar no mundo todo", completa.

"O mercado brasileiro cresce de 10 a 15% ao ano. A falta de profissionais e o custo da mão de obra na área de TI dificultam as exportações. Além disso, ainda temos como aliado ao problema a taxa cambial do dólar ou supervalorização do Real. Em 2010, comercializamos 2,4 bilhões de dólares na área de TI", diz Gil. Ainda segundo o presidente da Brasscom, "é uma meta pessimista porque podemos exportar muito mais”.