Momento Revolta - Tentando reservar quarto em Pousada

Hoje o assunto não é desenvolvimento, nem tecnologia. Quero apenas desabafar sobre uma coisa absurda que me aconteceu a alguns dias. Tudo começou quando eu e minha esposa decidimos aproveitar um dos fins de semana de janeiro para ir a praia, dar uma relaxada. Depois de discutir um pouco, resolvemos que iriamos para o Guarujá. Decidido o lugar, passamos a procurar um lugar para ficar durante o fim de semana. Depois de pesquisar um pouco na internet e pegar algumas referências, decidimos pela pousada canto do forte . Entrei em contato com a pousada, confirmei a data e os valores. A pousada me enviou um e-mail com todas as informações, inclusive as informações bancárias para o depósito dos 50% para a confirmação da reserva.

Como estava dentro do esperado, parti para a próxima etapa, que era o depósito dos 50% para a confirmação da reserva. Fiz o depósito, e conforme as instruções recebidas, enviei o comprovante do depósito por fax para a pousada. Depois disso, começou o pesadelo. Até o outro dia, no período da tarde, ainda não haviam me enviado nada confirmando a reserva. Como esta demora não é muito normal, resolvi entrar em contato com a pousada para saber se eu receberia um e-mail de confirmação, algum voucher ou qualquer outra coisa informando a confirmação da reserva. Qual não foi a minha surpresa, quando a pessoa que me atendeu disse que não havia nenhuma informação sobre a minha reserva no sistema, e pior, mesmo eu tendo feito o depósito ele não poderia confirmar a reserva, pois a pousada trabalhava com no mínimo, 4 diárias para reserva. Haviamos combinado apenas 2 diárias. As minhas opções eram: completar os 50% das 4 diárias, ou ele me devolveria o valor que depositei.

Conversei com o atendente, expliquei que queria que a pousada cumprisse o combinado nos primeiros contatos, afinal, ninguém merece ter que procurar hotéis duas vezes por erro dos outros. O rapaz me disse que a gerência determinou o mínimo de 4 diárias e não haveriam exceções. Pedi para conversar com o gerente, recebi a resposta de que ele não estava na pousada, mas que eu poderia deixar o número da minha conta para a realização do estorno. Falei que gostaria de conversar com o gerente antes de qualquer coisa. Após aproximadamente uma hora, o proprietário da pousada me ligou, dizendo que estava em São Paulo e que por isso não havia me atendido anteriormente. Ele me falou que o problema foi provocado por uma funcionária, que seria demitida por este erro (como se isso fosse do meu interesse). Mais uma vez tentei argumentar, afinal, eu cumpri todas as exigências da pousada, já havia feito o depósito, todos os contatos que havia recebido foram em nome da empres e finalmente, disse que a culpa não era minha se eles erraram e mais uma vez reiterei para que ele, como proprietário, cumprisse com o combinado. Ele me disse que precisava manter o seu controle financeiro e administrativo, e era para isso que existia a política do mínimo de 4 diárias. 

Após esta conversa, me enviaram um e-mail "retificando" o que haviam me falado inicialmente, e mais uma vez dizendo que minhas opções eram o reembolso ou completar o valor para a reserva das 4 diárias. Respondi por e-mail mais uma vez (dessa vez um pouco de teimoso mesmo), que eu esperava mesmo é que a empresa cumprisse com o acordo. Deixei claro que estava me sentindo enganado com toda esta situação e que me certificaria pessoalmente que a empresa também pagasse pelo erro. Afinal, independente de a comunicação da pousada ser falha, ou os funcionários serem incompetentes, a culpa não é minha. No fim, nem se deram ao trabalho de responder ao e-mail ou fazer qualquer outro contato, apenas fizeram a devolução do valor que eu havia pago.

Depois de tudo isso, eu queria mais é o meu dinheiro de volta mesmo. É muita conversa mole, com certeza o dono da pousada não quis "perder" 2 diárias, sendo que, certamente alguém pagará as 4 diárias que ele quer. Eu achei isso tudo uma tremenda falta de respeito, fizeram todos os contatos falando uma coisa, e mesmo após receberem o MEU dinheiro não avisaram que a reserva não seria feita, eu precisei ligar para ser informado disso. E olha, que nem entrei na questão de que isso que esta pousada está fazendo é venda casada, portanto, ilegal. Recomendo fortemente que quem pensar em ir para o Guarujá, fuja dessa tal pousada canto do forte.

Foram mais dois dias pesquisando hotéis e pousadas, mas creio que valerá a pena. Encontrei outra pousada pelo mesmo valor, tão bem localizada quanto a primeira, e que aceitou fazer a reserva apenas para o fim de semana. O melhor de tudo é que o check-out desta nova pousada é até as 18 hrs da tarde, portanto não precisaremos acordar e correr para arrumar malas em pleno domingo de manhã. Poderemos fazer com calma e curtir a viagem ao máximo. Ainda não vou dizer qual é a tal pousada, se ela for boa mesmo, faço um post exclusivo na volta da viagem.

Considerações sobre "Agile vs Tradicional"

Quem acompanha a cena ágil, deve ter percebido que ultimamente tem saído muitas faíscas entre especialistas de diversas metodologias, boas práticas, modelos de processo ou seja lá qual for o nome dado a todas estas "entidades" que se propõe a dizer como desenvolver software. Temos o relatório do SEI sobre CMMI e Agile , a crítica sobre problemas de Usabilidade ao usar Agile para desenvolvimento e mais alguns que não me recordo agora. Isso sem falar nas inúmeras discussões que ocorreram nas listas de discussão que acompanho.

No meio disso tudo, acabei me deparando com o post do Bruno Pedroso no eXPresso Capital . Achei sensacional as suas colocações sobre todas essas "implicâncias". Só gostaria de complementar com o seguinte, não acredito que exista o melhor e o pior jeito de fazer alguma coisa, existe apenas o que funciona e o que não funciona. E a beleza da coisa está justamente no fato de que algo pode funcionar perfeitamente em um lugar e em outro ser um estrondoso desastre.

Agora, voltando as picuinhas, é nesses momentos que me decepciono com o ser humano, porque é ai que posso ver o nível da nossa hipocrisia. Todos condenam o preconceito, todos dizem que devemos ter a mente aberta, todos dizem que devemos estar preparados para novas possibilidades, mas quando o calo aperta, fazem justamente o contrário, se acovardam, se fecham, se escondem e se blindam em seus mundinhos. A grande verdade é que, na maioria das vezes o que vale mesmo é a "lei da conveniência". Em outras palavras, o conveniente para mim está certo, se não é conveniente, pelo menos que os outros fiquem piores que eu. 

Quando agile começou a ser visto com interesse, muitos especialistas promoviam agile dizendo que as abordagens tradicionais eram burocráticas e improdutivas. Por outro lado, quem ganhava dinheiro com as práticas tradicionais, rebatiam dizendo que agile não oferecia nenhum mecanismo de controle, não havia documentação para nada, que os processos eram bagunçados e assim por diante. Ao meu ver isso é mais ou menos como promover maconha, falando que cigarro dá cancer; ou como vender peixe, dizendo que carne vermelha tem muito colesterol. Enfim, é completamente absurdo.

Agora que agile é visto como uma realidade, a briga é pra ver qual metodologia é a melhor. Quanta besteira. A impressão que fica, é que as abordagens para desenvolvimento de software vem tornando-se meros produtos, onde o grande objetivo é ganhar o mercado do concorrente, não importa como, nem mesmo a qualidade do produto oferecido. Nessas horas, quando o produto que um especialista vende tem alguma falha, basta esconde-la apontando falhas do produto concorrente, mesmo que seja preciso inventar uma. 

Após um longo Inverno

Eu estou de volta, dei uma parada para dar conta das coisas do dia-a-dia, pois os últimos meses foram bastante corridos. Agora a correria está maior ainda, então percebi que se eu for esperar as coisas ficarem mais tranquilas, vou abandonar o blog pra sempre.

Estou fazendo este post para anunciar que a algum tempo já tenho a versão final do meu trabalho de conculsão da pós-graduação. Já fiz todas as correções solicitadas pela banca, imprimi e encadernei em capa-dura. Quem quiser ver o original, acredito que já deve se encontrar disponível na biblioteca da Fatec Sorocaba, ou estará em breve. Mas se você é uma pessoa moderna, pode baixar a versão digital do trabalho aqui.

Como agora estou voltando a ativa, em breve postarei coisas mais interessantes.

Muitas Apresentações e Fim da Pós-Graduação

As últimas semanas foram repletas de acontecimentos, até está dificil conseguir atualizar o blog.

Primeiro de tudo, finalmente terminei a minha pós-graduação. No último sábado, dia 04/10/2008, fiz a apresentação do meu trabalho de conclusão para a banca avaliadora. A banca identificou algumas coisinhas pendentes, mas nada muito grave, agora só preciso terminar de fazer algumas correções no texto e finalmente o trabalho estará finalizado.

De qualquer forma, já foi dado o conceito para o meu trabalho, fiquei com "A", que é considerado como um ótimo trabalho, porém sem exceder as expectativas da banca. Para o "E", de excede expectativas, ficou faltando um case, que infelizmente foi impossível devido a alguns acontecimentos no percurso. Assim que o trabalho estiver finalizado deixo o link para download por aqui.

Enfim, finalmente terminei a pós-graduação, depois de tanta briga, só isso já vale uma bela comemoração. Agora sou um especialista em Gestão de Tecnologia de Informação, só falta o certificado.

Seguindo com as novidades, na quarta-feira da semana passada, dia 01/10/2008, fiz uma palestra na Universidade de Sorocaba(UNISO) sobre a Utilização da tecnologia como ferramenta de desenvolvimento profissional. A palestra foi muito legal, apesar da chuva que caiu o dia todo, aproximadamente umas 80 pessoas compareceram, sendo que a sala tinha capacidade para 150 pessoas. Falei um pouco sobre o perfil dos universitários e sobre algumas das situações que normalmente enfrentam ao se formarem. Com esta pequena introdução, procurei mostrar como algumas novas tecnologias, principalmente ferramentas Web 2.0 podem ajudar estes alunos a se aperfeiçoarem profissionalmente e desenvolverem as suas carreiras. a Datasul até disponibilizou alguns brindes para o pessoal que foi assistir.

Na próxima quinta-feira, dia 16/10/2008, ministrarei outra palestra sobre este mesmo tema, mas agora para os alunos do curso técnico do Colégio Ser aqui de sorocaba. Infelizmente, por ser o primeiro Evento do gênero realizado pelo Colégio Ser, apenas os alunos do curso técnico poderão participar.

Nossa, serão 3 apresentações em menos de 20 dias, quanta correria.

TCC da pós, uma pitada de scrum e um exemplo de marketing

Hoje trago algumas novidades e um pequeno (não tão pequeno assim) desabafo no final. Primeiro de tudo, há uma boa justificativa para o meu "sumiço". Eu estava trabalhando com afinco no meu trabalho de conclusão de curso da pós-graduação, e é com orgulho que lhes digo que a coordenação do curso aprovou o meu trabalho para avaliação da banca, o que me deixa muito feliz, pois isso significa que é muito provável que em breve finalmente eu me torne um especialista em gestão de tecnologia de informação.

Em meu trabalho faço uma comparação entre as filosofias de desenvolvimento de software ágil e tradicional. O objetivo do trabalho é mostrar as diferenças entre as filosofias de desenvolvimento e identificar os cenários mais favoráveis para a adoção de cada uma das vertentes. Confesso que foi muito díficil ser imparcial na argumentação, já que durante as pesquisas quanto mais aprofundei o meu conhecimento nas práticas ágeis, mais fiquei favorável a adoção de práticas ágeis ao invés das tradicionais.

Mudando um pouco de assunto, vou fazer uma prévia dos próximos posts. Aqui na Datasul Saúde (unidade Sorocaba) houve nos últimos meses uma campanha interna muito legal, chamada "Agiliza Sorocaba". Em breve disponibilizarei um bate-papo com a Erika, que idealizou, organizou, orientou e incentivou toda a campanha. Nesse bate-papo vamos falar mais a fundo sobre isso, então essa foi só pra dar o gostinho da coisa. Enfim, como todos fomos aplicados e atingimos a meta da campanha, fomos agraciados com um passeio totalmente "di grátis" ao Hopi Hari. Muito legal não acham? Realmente, foi um prêmio muito legal, com direito a acompanhante e ajuda de custos para o lanche e tudo.

O único problema é que, como bem diz o ditado: Alegria de pobre dura pouco. Foi uma coisa impressionante, assim que descemos do ônibus começou a chuva que continuou o dia todo. Além disso, o parque estava entupido de gente, ouvi relatos de pessoas que ficaram somente meras 5(CINCO) horas inteiras na fila da montanha russa e debaixo de chuva. Nessas horas é que a gente vê o verdadeiro poder do marketing. Para qualquer ser humano normal é óbvio que o parque estava superlotado, é inadimissivel passar 8 horas em um lugar e conseguir ir apenas em apenas 3 ou 4 atrações de um parque que tem dezenas de atrações. Em um certo momento do dia, tudo o que eu queria era conseguir um lanche em menos de 2 horas e um lugar coberto, quentinho e sem chuva para comer o bendito lanche. Se fosse um parque "normal", isso já seria motivo suficiente para nunca mais voltar lá e falar mau do lugar com um megafone no próximo comício(oops, inauguração de obra) do Lula. Mas como é o Hopi Hari, o lugar mais divertido do muuuuuuunnndo, dou um desconto e só reclamo um pouco no blog mesmo. E certamente, a próxima vez que eu voltar pra lá, vou pesquisar muito para saber em qual época do ano e dia da semana o parque é mais tranquilo, porque aquele lugar mais vazio deve ser animal. O pior de tudo é isso, é bem possível que eu ainda volte pra lá, isso sim é marketing bom, você se ferra e mesmo assim quer mais.

Café com Agile - parte 3

Meus caros, finalmente chegamos a terceira e última parte do nosso Café com Agile. Se você, caro leitor ficar com alguma dúvida, envie para o Sandro ou para mim, que oportunamente iremos responder.

Tanto eu, como o Sandro já conheciamos tanto Scrum como PMI, com a diferença que o Sandro é um especialista em Gerência de Projetos e eu sou um grande entusiasta e estudioso de Scrum e Agile em geral. No início da conversa, o único objetivo era um poder aprender com o outro, eu queria conhecer mais sobre os conceitos de PMI e ele conhecer um pouco mais sobre Scrum, e nesse ponto tenho certeza que atingimos o nosso objetivo e de quebra, o papo foi até surpreendente.

Gostei muito dessa experiência, e espero que aqueles que lerem também gostem. E agora, deixando a parte "sentimental" de lado, vamos ao derradeiro final do papo.

Sandro: Em nossa última conversa, entendi que a idéia no scrum é fazer entregas constantes, mas a minha dúvida é, como é decidido a ordem em que as coisas serão desenvolvidas?
Milton: Tendo o “Product Backlog” em mãos, o “Product Owner” define o que deve ser entregue primeiro para que o projeto tenha um maior retorno financeiro
Milton: Ai, a equipe de desenvolvimento se reúne, verifica quais itens eles podem entregar no prazo combinado e começam o desenvolvimento destes itens
Milton: Nesse ponto, surge o conceito de time-box, ou seja, em scrum o prazo é fixo, a equipe trabalha em ciclos/iterações que duram de 2 a 4 semanas. Ao final de cada iteração é entregue um incremento do produto
Milton: Cada ciclo ou iteração é o que chamamos de “sprint”.
Milton: Com o incremento entregue, o “Product Owner” pode decidir por utilizar o produto em produção ou aguardar pelos próximos incrementos
Sandro: E já é apresentando ao cliente?
Milton: Sim, em alguns casos o “Product Owner” é o próprio cliente. Inclusive, é uma prática recomendável que, quando o projeto for específico para um único cliente o “Product Owner” seja uma pessoa de negócios do Cliente.
Sandro: Sim, ele seria o gerente de TI ou um analista sênior que esteja a par das regras de negócio e estratégias da empresa
Milton: Não necessariamente, pode ser até um cara de negócio mesmo
Milton: Tem uma coisa q falamos, mas não dei nome, q é o “Sprint Backlog”
Milton: O “Sprint Backlog” é a porção de coisas do “Product Backlog” que a equipe seleciona para desenvolver
Sandro: Hummm esse eu conheço, é o incremento planejado para o próximo Sprint.
Milton: Isso mesmo
Milton: Com isso observamos uma coisa muito interessante, o cliente não precisa esperar uma vida pra ver algum resultado do projeto
Milton: E o fornecedor não precisa ficar uma vida amarrando escopo, nem fazendo planejamentos de projetos enormes, com milhares de documentos e assinaturas de aprovação de escopo e mudanças
Milton: Isso porque o fornecedor foca apenas nas tarefas do “Sprint”, e o “Product Owner” foca em organizar continuamente o “Product Backlog”, medindo o quanto o projeto está dando de retorno financeiro
Sandro: Sim, isso eu visualizei , é sensacional, jogo aberto e de ajustes rápidos!
Milton: Exato
Milton: Além dessa questão sobre o "como tratar o escopo", acredito que temos mais uma diferença marcante, quer dar um palpite? hehe
Sandro: Bom, o que eu gostei muito no scrum foi que possui praticas muito democráticas. Ele permite que o especialista opine, se expresse, participe do processo. Isso muda até mesmo o pique do cara em vir trabalhar
Sandro: Além disso, ele não vê que tem que trabalhar 2000 horas em entregáveis que nem imagina ainda (em finais de semanas e feriados), mas sim 2 semanas (de segunda a sexta) em assuntos já discutidos e planejados para essas 2 semanas
Sandro: Seria isso?
Milton: Sim, você foi na veia do negócio
Milton: A primeira parte é a questão dos papéis, não existe o Gerente de Projeto Super Poderoso, cada papel tem um poder específico, de acordo com a sua função e cada papel deve contribuir com os demais para atingir os objetivos do projeto
Milton: - o Product Owner define os objetivos do produto, e o que será feito primeiro para atingir este objetivo
- o Time define o que é capaz de entregar em cada sprint, bota a mão na massa e procura melhorar o processo sempre para produzir mais
- o Scrum Master, que nem foi citado até agora e é muito importante, isola o time de interferências, remove impedimentos e faz um papel de facilitador entre o Product Owner e o Time
Milton: O segundo ponto é a questão do "tamanho" do projeto. Você deixa de trabalhar com um projeto titânico, e passa a trabalhar com vários mini-projetos, em seqüência, com isso o produto vai crescendo a cada entrega.
Milton: E acho que qualquer Gerente de Projeto concorda que é muito melhor trabalhar com um projeto de 200 horas, do que com um projeto de 20.000 horas
Sandro: Claro, muito melhor
Sandro: E a questão dos poderes de um sobre o outro? No caso do Scrum Master x Product Owner?
Sandro: Existe braço de ferro entre os dois?
Milton: Depende, pode existir, mas por questões políticas. E isso pode acontecer com qualquer tipo de função
Milton: Se os dois fizerem o seu papel e se mantiverem focados no objetivo do projeto não devem ocorrer quedas de braço no sentido político da coisa
Milton: Claro que ocorrerão conflitos, mas são conflitos saudáveis, buscando o melhor para o projeto e não benefícios individuais
Milton: É diferente de você ter, por exemplo, dois Gerentes de Projeto brigando por aquele "Recurso" que é o cara em java, que programa tudo rapidinho
Sandro: Sim, mas ai seriam 2 GPs em uma mesma empresa, se existissem 2 Scrum Master na mesma empresa poderia ter o atrito também?
Milton: Não, porque em scrum a idéia é q a equipe seja fixa. Não vai ter aquela dança de pessoas entre as equipes, porque manter as pessoas trabalhando juntas contribui para o desenvolvimento profissional delas
Milton: Ainda mais quando você possui uma equipe bem heterogenia, onde você tem pessoas com várias funções e com diferentes níveis de experiência. Em uma equipe assim todos aprendem com todos, e se tornam profissionais melhores, aumentando a maturidade e capacidade da equipe
Sandro: entendi
Milton: Bom, acho q estamos chegando ao fim do papo por hoje, mais alguma consideração?
Sandro: Acho que não, clareou pra mim ainda mais as práticas e personagens do scrum, foi show de bola

link para a Parte 1
link para a Parte 2

Café com Agile - parte 2

Esta é a segunda de 3 partes do "Café com Agile", para quem não viu a primeira parte, link para a parte 1. Se você ficou com alguma dúvida, ou quiser dar alguma sugestão é só deixar um comentário ou entrar em contato comigo ou com o Sandro. Agora sem mais delongas, a segunda parte do Café com Agile.


Milton: Mudando um pouco o rumo da nossa última conversa, vamos falar um pouquinho de projetos agora. Acho que é melhor você falar um pouco sobre como você aprendeu que os projetos devem ser gerenciados
Sandro: O PMI entende que certas áreas de conhecimento são vitais para que um projeto termine com “sucesso” (a entrega do produto do projeto), no tempo programado, no escopo acordado, no custo estimado, e atingindo as expectativas do cliente (QUALIDADE)
Sandro: São 9 as áreas de conhecimento: escopo / tempo / custo / qualidade / aquisição / comunicação / RH / riscos / integração
Milton: No fim das contas temos a trinca: Custo, Prazo e Qualidade. A idéia é ter um equilíbrio para maximizar estes 3 pontos, certo?
Sandro: Sim, imagine um triangulo: de cada lado dele uma dessas áreas
Sandro: Se você aumentar o prazo, aumentará o custo ou o escopo, é bem interessante essa visão
Milton: E ainda tem o escopo, que influencia estas 3 variáveis, certo?
Sandro: Certo
Milton: Bom, aqui já posso observar uma figura muito forte, que é o Gerente de Projetos
Milton: Ele é o cara que pode, e que deve fazer, decidir, definir, mandar e desmandar tudo relacionado ao gerenciamento do projeto
Sandro: Sim, planejamento, planejamento, planejamento
Sandro: E cada área de conhecimento possui um Plano de Ação
Milton: É o Gerente de Projetos que define o escopo com o cliente, ele vende, ele negocia, ele define cronograma, ele define as tarefas, ele faz as estimativas
Milton: Pelo menos sempre tive essa é a impressão
Milton: E ele faz isso em cada uma das 9 áreas de conhecimento
Sandro: Sim, por isso ele não pode (não deve pelo menos) botar a mão na massa, pois tudo isso gasta MUITO, mas MUITO, tempo.
Sandro: Ele tem, durante o seu dia a dia, de passar por todas essas áreas e ver o que cada uma está dizendo para ele fazer naquele dia/momento.
Sandro: Além disso, cuidar da expectativa, problemas, atrasos, etc.
Sandro: E é claro que, o bom-senso tem que prevalecer. Se tenho um projetinho, vou precisar agir no plano de aquisição / comunicação da mesma forma que um projeto normal? Ele tem que analisar isso e deixar de fora o que não será necessário.
Milton: Entendi. Eu acho que vamos voltar nessa questão do bom-senso depois, por enquanto, eu acho legal a gente voltar a questão do escopo
Milton: Até onde sei, quando se fala em PMI, normalmente é definido todo o escopo do projeto logo na fase inicial, e tudo é desenvolvido com base neste escopo
Milton: Ai, qualquer coisa fora desse escopo irá impactar diretamente no custo e prazo do projeto
Sandro: Sim, mas quando o cliente solicita uma alteração nele, essa solicitação irá para uma Comissão, onde será analisado o impacto sobre o projeto. A partir dela é que definirá se será feito sem cobrar, ou então cobrando e alterando o cronograma, etc. Negociando com o cliente em seguida.
Sandro: E fica tudo registrado, para fins de documentação, nada é boca a boca, mesmo porque é esse registro que circulará dentro da equipe do projeto
Milton: É, acho que agora é hora de começar a comparar as coisas com scrum um pouco
Milton: Talvez a maior diferença entre um projeto "tradicional" e outro que siga a filosofia agile, é a questão do escopo
Milton: Em agile não existe um escopo fortemente detalhado no início do projeto, o escopo é associado a um objetivo do negócio do cliente
Milton: Digamos que o seu cliente é uma panificadora. O escopo desse projeto pode ser definido como "Quero aumentar a minha capacidade de atendimento dos meus clientes, controlando melhor os pedidos e a produção da minha panificadora"
Milton: O escopo morre ai, você não precisa saber detalhadamente que campos existirão no cadastro de clientes, como vai ser o controle de estoque, se precisa implementar TEF nas vendas logo no início do projeto
Milton: Você não precisa disso, porque o software será desenvolvido aos poucos, em ciclos ou iterações, e os requisitos serão levantados conforme forem sendo desenvolvidos
Sandro: Mas e o prazo e custo disso?
Milton: A cada iteração ou ciclo, você desenvolve pequenos incrementos do produto, cada um destes incrementos tem prazo de entrega e custos fixos
Sandro: Definidos no inicio do projeto?
Milton: Sim
Sandro: Não visualizei ainda. Se você acorda com o cliente: serão 300 incrementos. Cada incremento custa $ XX e leva YY dias.
Sandro: Levará então XXXX dias e custara YYY. Entrego em 31/12/2008. Mais ou menos isso?
Milton: Não. Em scrum, assumimos que não há como saber "quantos incrementos" serão necessários, temos apenas uma estimativa inicial que será ajustada continuamente durante o projeto.
Milton: No scrum, essa lista é chamada de Product Backlog. Ela é mantida e priorizada pelo Product Owner(um dos papéis do scrum), que é responsável pelo retorno financeiro do projeto
Sandro: Mas então o cliente não sabe quanto lhe custará e o tempo que levara o projeto, certo? Somente valores estimados, certo?
Milton: Para estimar quantos incrementos serão necessários, você precisa ter uma lista do que tanto o produto final deve ter. Com essa lista em mãos, é possível fazer uma estimativa inicial (junto com a equipe de desenvolvimento) de quantos incrementos serão desenvolvidos até o final do projeto. Normalmente há uma limitação de custo, nesse caso a quantidade de incrementos que serão entregues será limitada e o custo e prazo de entrega do projeto podem aumentar ou diminuir.
Milton: Agora, em valores exatos, não há como saber o custo e prazo do projeto. E se parar pra pensar, mesmo no esquema que você me disse também não há como saber. Você acaba estimando e assumindo um contrato de risco
Milton: Ai, se você terminar antes, você ganha ou o cliente te paga menos, se terminar depois alguém vai ter que assumir o prejuízo
Milton: Como você nunca via querer terminar muito antes do prazo, normalmente o cliente paga o pato, concorda?
Sandro: Claro, sem dúvida, se você estiver terminando o projeto muito antes do prazo e houver outras prioridades, o projeto do cliente será deixado um pouco de lado para maximizar os lucros Sandro: Entendi, o negocio é a negociação, estando tudo transparente no início (e no contrato também) vale o bom-senso e a aceitação da forma como será projetado o produto final
Milton: Exato, a coisa começa ai, toda a forma de se negociar comercialmente já muda

Aguardem, em breve teremos a parte 3.

Link para a Parte 1
Link para a Parte 3

Café com Agile - parte 1

Há algum tempo quero escrever sobre desenvolvimento ágil, que é uma área de desenvolvimento que gosto muito. O único problema é que desenvolvimento ágil é um assunto com muito material na internet. O grande desafio é falar sobre o assunto sem cair no "mais do mesmo", apesar de não ser um especialista no assunto, eu queria criar um material diferente dos diversos artigos, apresentações e palestras que é possível encontrar na internet.

A forma que encontrei para abordar o assunto de forma mais criativa, foi através de uma conversa entre amigos, algo parecido com a série Café com Flex, que o pessoal da d-click fez sobre o Adobe Flex. É ai que surge o meu amigo Sandro, que trabalha comigo na Datasul Saúde e é especialista em Gerência de Projetos. Ele topou a idéia de fazer uma conversa envolvendo Gerência de Projetos nos moldes do PMI e Desenvolvimento Ágil com uma certa ênfase em Scrum. Eu gostei muito do resultado, acho que conseguimos criar um bom material, que vale tanto para quem quer ver alguma coisa sobre gerênca de projetos, como para quem quer conhecer mais sobre desenvolvimento ágil.

Decidimos dividir esse bate papo em 3 partes, para não ficar tão cansativa a leitura, acompanhem os próximos posts, espero que gostem.


Milton: Sandro, antes de começar o nosso bate-papo, gostaria de dizer para os nossos leitores que você é meu amigo de trabalho aqui na Datasul Saúde, atualmente atua como Analista de Suporte, e é especialista em Gerência de Projetos pela FGV, com uma forte ênfase nas práticas de gerenciamento de projetos definidas pelo PMI e mais algumas práticas complementares, estou certo ao afirmar isso?
Sandro: Sim, o curso ministrado pela FGV é diferenciado dos demais cursos voltados somente para a certificação PMP.
Sandro: Nesse MBA vimos outros temas que ajudam as boas praticas do PMI. Temas, inclusive, que a própria FGV aposta que serão incorporados ao PMBOK em futuras publicações, tais como: Marketing, Negociação, Gestão de Mudança Organizacional e Comunicação fora do âmbito do projeto
Sandro: É importante deixar claro que, a parte do MBA, existe a certificação que o PMI oferece, o PMP. Com esta certificação, eu seria um especialista do PMI.
Milton: O PMI é o Project Management Instutite, que é uma organização que tem por objetivo estudar, identificar e disseminar as melhores práticas relacionadas à gerência de projetos, certo?
Sandro: Sim, e também fomenta
Sandro: As suas boas praticas são publicadas, de tempos em tempos, um livro chamado de PMBOK (Project Managemente Body of knowlege)
Milton: Interessante, a idéia desta conversa é justamente poder falar um pouco sobre Gerência de Projetos de forma geral e também um pouco sobre Agile, então só para esclarecer, essa tal "Gerência de Projetos" trata sobre o que exatamente?
Sandro: Boas praticas que podem ser utilizadas em qualquer tipo de projeto
Milton: E estes mesmos conceitos podem ser aplicados na rotina de pessoas que executam o trabalho operacional, no dia-a-dia da empresa?
Sandro: Sim, é possível, por exemplo, a gestão da comunicação sugere a identificação de stakeholders (que são as partes interessadas em um projeto) e quando cada stakeholder tem que receber a informação, em qual mídia, etc.
Parte do que a Gestão de Comunicação aborda e recomenda, eu aplico em meu dia-a-dia, mesmo não estando em uma posição de gerencia.
Milton: Sem se prender a metodologias, podemos dizer que qualquer pessoa, independente de posição em hierarquia poderia utilizar conceitos de gerência de projetos para ajudar no desenvolvimento de suas atividades no dia-a-dia, certo?
Sandro: Sim, pelo menos eu acredito que sim.
Sandro: Um bom exemplo seria o seguinte:
Se uma empresa que está contratando um Gerente de Projetos, descobrir que a sua vida pessoal é desorganizada, sem planejamento, a contratação desse profissional pesara nesse item (em casa de ferreiro o espeto tem que ser de aço), principalmente se os projetos que ele assumir forem de milhões de reais.
Sandro: Forcei um pouco a barra, mas a idéia é de que essas práticas estejam sempre em mente.
Milton: Agora vamos falar um pouco de agile, o q você já viu ou leu sobre agile?
Sandro: Já ouvi alguns podcasts sobre Agile e também de scrum
Sandro: Posso perceber que o mercado está começando a abraçar o SCRUM, ou seja, está começando a aceitá-lo sem torcer o nariz para uma coisa nova que não vem do RUP e outras mais conhecidas
Milton: Só complementando, Agile é algo como uma "filosofia" para gestão de projetos, scrum é uma metodologia que segue os princípios de agile
Sandro: Mas é especificamente voltada para desenvolvimento de software, certo?
Milton: Agile vem do manifesto ágil, que foram alguns princípios definidos por algumas pessoas que desenvolviam software de uma forma pouco convencional para a época
Milton: Estes princípios foram os pontos de convergência que eles encontraram entre cada uma de suas metodologias
Milton: E você está certo sim, de modo geral, todas as metodologias ágeis foram concebidas para tratar projetos de software
Milton: A única exceção, talvez seja o scrum, que é visto como um "framework de gerenciamento", que pode ser aplicado a qualquer tipo de projeto
Sandro: Ou seja, esse pessoal conseguiu formar uma “opinião”, gerando princípios
Sandro: Achei esse lance do Manifesto Ágil um pouco fora do comum, pois não vemos esse tipo de manifesto em outros processos/tendências
Milton: Realmente, normalmente o que acontece é uma coisa mais TOP-DOWN né?
Milton: Exemplo: A IBM contrata um grupo de profissionais muito bons e produz um processo (RUP), e depois vende uma ferramenta baseada neste processo (Rational)
Sandro: Sim
Sandro: Mas existe um instituto que regule essas práticas?
Milton: Bom, preciso deixar uma coisa muito clara, se você entrar no site do manifesto ágil, você vai ver que lá só tem 4 frases, que representam o manifesto. Esses são os princípios seguidos por qualquer metodologia ágil
Milton: As metodologias em si, é outra história. Eu particularmente tenho um conhecimento mais aprofundado em scrum, que é mantido pela agile aliance
Milton: Até onde eu sei, é a única metodologia ágil que possui uma organização por trás, outras bastante difundidas como a extreme programming foram desenvolvidas na prática por um pequeno grupo de pessoas, e depois divulgadas
Milton: Inclusive, a extreme programming foi desenvolvida pelo Kent Beck a partir de um projeto na Chrysler
Sandro: Entendi
Sandro: Clareou agora
Sandro: Existem certificações para estas metedologias ágeis?
Milton: Não são todas as metodologias ágeis que possuem certificações. Até hoje, só vi um processo de certificação em scrum
Milton: Existe uma resistência muito grande na comunidade ágil para certificações. Principalmente pelo fato de que uma certificação simplesmente certifica o conhecimento teórico sobre o assunto
Milton: Há pouquíssimas certificações atualmente que avaliam experiência, capacidade e qualidades humanas, como postura e comportamento
Sandro: Sim, difícil mesmo
Milton: E mesmo a primeira "certificação" do scrum que é a Certified Scrum Master é muito contestada, pois para conseguir esta certificação basta assistir a um curso de 16 horas em dois dias. Claro que o curso é ótimo, mas não certifica nada além de que a pessoa assistiu ao curso
Milton: E mesmo para PMP, a única avaliação é a prova baseada no PMBok, assim como as provas da sun para certificação java, Microsoft, ITIL e tantas outras certificações que existem por ai
Sandro: Concordo, inclusive para o PMP é uma prova de 4 horas incrivelmente decoreba (o processo xyz tem uma entrada/processamento/saída, quais são as entradas e as saídas?)
Milton: Nesse ponto eu até concordo com a comunidade ágil, uma certificação até pode ser um diferencial no mercado, mas na prática é apenas uma prova de que você decorou muita coisa sobre um assunto, só disso

Link para a Parte 2

Link para a Parte 3

Visite Curitiba

Eu estou a um bom tempo sem blogar, mas é por um bom motivo. No último fim de semana, fugi um pouco do trabalho e viajei para Curitiba com a minha esposa. Foi a minha primeira visita a cidade, e gostei muito da experiência. De fato é uma cidade modelo, muito fácil de se localizar, cheia de parques, com muito verde, bem iluminada a noite, com muitas placas indicativas e um trânsito muito fluido, tanto que nem parece o trânsito de uma capital(comparando com São Paulo, lá é o céu). Claro que posso estar exagerando um pouco, mas pelo menos essa foi a minha experiência nos três dias que passei por lá.

Foi uma viagem turistica mesmo, sem maiores pretenções. Conhecemos o Jardim Botânico, com os seus enormes jardins, sua estufa inspirada no castelo de cristal e seu bosque com um pedacinho da mata nativa da região. Também fizemos o passeio de trem até morretes, atravessando a serra do mar. A ferrovia é cheia de história, foi construida há mais de 100 anos e é utilizada até hoje por trens de carga para escoar a produção paranaense até o porto de paranaguá. As paisagens da serra do mar são incríveis e é admirável imaginar que a ferrovia foi construida no tempo do império, pois ela passa por regiões onde o acesso é muito díficil.

Conhecemos a ópera de arame, que é uma sala para apresentações, e a impressão que se tem ao olhar pela primeira vez, é que toda a estrutura foi feita em arame e está sobre um lago, mas é só impressão. Aproveitamos para conhecer o Madalosso (valeu a dica Andrew), que é o maior restaurante do Brasil e o segundo maior do mundo. Segundo o tiozinho do estacionamento(que disse que o site deles está desatualizado), eles já atenderam mais de 6.000 pessoas em um único dia. A comida é muito boa e o preço também, um ótimo custo x benefício, recomendo. Durante nossas andanças, ainda demos uma passeada pelo batel, que é um bairro nobre de Curitiba e fica pertinho do centro, é um bairro muito bonito e tranquilo, tem shoppings, barzinhos, restaurantes e baladas.

Mesmo com todos estes atrativos, quero chamar atenção para uma "atração" que nem é tão conhecida assim, e foi o que mais me surpreendeu durante a viagem, que é o Museu Oscar Niemeyer. Começa que o prédio foi projetado pelo próprio Niemeyer, o que já é algo que não se vê todo dia. O prédio tem uma arquitetura muito bonita, com muito espaço, muito verde e um design único. Se todo o prédio estivesse vazio já valeria a visita pelas rampas de acesso, pela estrutura das salas, pelas possibilidades de iluminação, e pelo túnel que liga o prédio principal ao "olho" e pelo próprio "olho", que é uma enorme estrutura semelhante a um olho que fica sobre uma grande coluna no meio de um pequeno lago bem em frente ao prédio principal do museu. Como se isso não bastasse, o museu tem um acervo invejável, com muitas obras e objetos pessoais de Tarsila do Amaral, muitas exposições de obras e fotografias. O lugar é enorme, tanto que nós visitamos somente metade das salas de exposição e olhe lá. Também há salas que passam vídeos o tempo todo, um espaço para educação cultural para crianças, uma lojinha de souvenirs e ainda uma grande exposição com fotos, textos e maquetes sobre Oscar Niemeyer. E o melhor de tudo, você pode ver tudo isso por apenas R$ 4,00 hehe.

As 10 maneiras mais comuns de arruinar projetos com XP e Scrum

Povo, antes de mais nada quero me desculpar pela demora do novo post, nesta última semana o bicho pegou e não sobrou tempo para muita coisa. Agora, falando sobre o assunto do dia, na semana passada o Guilherme Chapiewski, da globo.com, postou em seu blog um resumo sobre a apresentação do Henrik Kniberg, que ocorreu na Agile 2008 Conference em Toronto/Canadá.

Na apresentação, Henrik Kniberg falou sobre "as 10 maneiras mais comuns de arruinar projetos com XP e Scrum". Lendo o resumo do Guilherme, cheguei a conclusão que, com as devidas adaptações de contexto, as tais 10 maneiras se aplicam a praticamente qualquer projeto de desenvolvimento de software, mesmo que não seja utilizada uma metodologia ágil para o desenvolvimento. Vou colocar as minhas considerações logo abaixo de cada item do resumo do Guilherme(em itálico).

Resumidamente, as 10 maneiras mais comuns de arruinar projetos com XP e Scrum são:

• Futilidades: debates homéricos sobre coisas como “vamos usar cartões ou post-its” quando o time sequer tem um Product Owner! Os problemas devem ser atacados em ordem de importância. Além disso, a aplicação do processo não precisa ser perfeita desde o início. Good enough is good enough.
  

Em outras palavras, a prioridade sempre deve ser para o que é mais importante. Quem nunca ouviu "faz o cadastro 123AABB e depois o cálculo" ou "começa a adiantar o código, e depois você vê direitinho com o cliente como vai funcionar". Nesses dois casos o mais importante está sendo deixado de lado ou postergado, este tipo de atitude invariavelmente leva a retrabalho e dor de cabeça.

• Definition of Done: muitos times não têm uma definição de pronto ou não respeitam essa definição. Isso não só é essencial como também é preciso que o cumprimento desta definição esteja dentro do controle do time.

Em scrum e xp existe um conceito muito interessante, que é a "definição de pronto". Esta definição é a referência para que os desenvolvedores possam dizer que algo está pronto. Isso evita que alguns desenvolvedores mais preguiçosos façam a programação correndo, com o famoso teste "compilou? beleza" e liberem para a equipe de qualidade.

• Velocidade: não é conhecida, usada ou é muito variável ao longo das iterações.

Métricas em desenvolvimento software ainda é algo muito complicado e as vezes polêmico, mas necessário. Para medir velocidade em scrum e xp, a métrica mais conhecida e utilizada é a de "story points", mas pode-se utilizar outras métricas, como a APF por exemplo. O ponto que quero chegar é, para poder melhorar é preciso ter uma medida de desempenho, fazendo uma rápida analogia, trabalhar sem uma métrica de velocidade é como estar em uma corrida de fórmula 1 sem cronômetro e velocímetro.

• Retrospectivas: não há retrospectivas e o time não evolui suas práticas ao longo do tempo aproveitando-se dos aprendizados obtidos nas iterações.

Aqui entra o lance do feedback, apesar de algumas pessoas acreditarem que essas reuniões são puro desperdicio de tempo, as reuniões de retrospectiva são muito importantes pra se buscar e obter feedback individual e coletivo. A equipe precisar ter um momento para analisar o ciclo, absorver novos conhecimentos e evoluir.

• Comprometimento do time: time é cobrado e sempre culpado por erros em estimativas. Isso faz com que eles sempre se comprometam com menos do que podem fazer, com medo de serem culpados novamente.

Temos que pensar que em 99,9% dos casos, ninguém gosta de errar, ninguém erra de propósito e que desenvolvedor não tem bola de cristal. Estimativa é só isso, estimativa, óbvio que estourar um prazo não é legal, mas acontece e com o passar do tempo há um refinamento nas estimativas. Exigir que os desenvolvedores sempre acertem as estimativas provoca comportamentos indesejados, como exagerar nas estimativas, trapacear na apuração dos tempos de tarefas, enrolar até dar o tempo previsto para a tarefa, etc.

• Débito técnico: é totalmente ignorado e só cresce ao longo das iterações.

Débito técnico são aquelas coisas "bizonhas" que aparecem na arquitetura de um software, que precisam ser re-estruturadas para ser possível trabalhar o código. Normalmente é o resultado do uso recorrente de marretadas. O problema é quando o software nunca é re-estruturado, nesse caso a empresa só perde dinheiro porque qualquer implementação ou manutenção fica díficil de fazer, até que se chega em um ponto onde o software precisa ser jogado fora e feito novamente a partir do zero.

• Trabalho em equipe: não há trabalho em equipe e existem tarefas fixas para determinadas pessoas, o que faz com que várias histórias sejam implementadas em paralelo.

Além do desenvolvimento em paralelo, que já faz com que a entrega de funcionalidades demore mais, a falta de trabalho em equipe cria "donos" de códigos, e isso gera muitos efeitos maléficos na organização como: códigos indecifráveis que apenas uma pessoa consegue trabalhar, a empresa fica réfem do "cara" que sabe tudo de uma coisinha só, surgem gargalos no desenvolvimento porque apenas uma pessoa consegue trabalhar com determinado assunto, não existe troca de conhecimento, etc.

• Product Backlog: não existe ou não está priorizado corretamente.

Uma vez um professor me disse a seguinte frase: "_Ahhh, muitas vezes é aquele negócio né? O último cliente que entra na sala com o pé na porta e gritando é o primeiro a ser atendido". Acho que isso ilustra perfeitamente a falta de um backlog(lista de pendências do produto) devidamente priorizado de acordo com as prioridades de negócio da empresa.

• Integrações da base de código: não existe um branch onde o código pode ser lançado em produção a qualquer momento e a gerência da base de código não é agil.

O impressionante mesmo, é ver que há empresas de desenvolvimento que já transformaram essa deficiência em política da empresa. Ilustrando com um exemplo: O cliente encontra um bug crítico no sistema e precisa de uma correção urgente, a resposta padrão é: "_Ahhh, infelizmente só poderemos estar liberando a versão que estará corrigindo o seu problema no final do mês, que é quando estaremos fechando versões".

• Sprint Backlog/quadro de tarefas: não existe, está longe do time, é muito complicado ou não é usado durante o Daily Scrum e atualizado diariamente.

Essa é exclusiva de quem trabalha com scrum e xp, mas, seria mais ou menos o mesmo que ter um project que nunca é atualizado. Nesse caso, não ter nada já é melhor.

Achei muito legal essa lista, principalmente porque ilustra a maioria dos problemas que já observei em desenvolvimento de software, seja com metodologias tradicionais, metodologias ágeis ou mesmo sem nenhuma metodologia.

O poder da MARRETA

Hoje eu quero descontrair um pouco, portanto, vamos falar do poder da MARRETA. Talvez a marreta seja o instrumento de trabalho mais poderoso que está ao alcance de qualquer desenvolvedor de software.

Aposto que qualquer um que já programou alguma coisa nessa vida pode contar um "causo" como esse: "_Eu estava fazendo um programa xyz que tinha que gravar um blabla no banco, mas tinha um cálculo antes que provocava um erro de conversão de tipo por causa da Repimboca da Parafuseta que retornava float e devia ser double. Ai eu tive que fazer uma conversão para string e depois pra number, e assim funcionou. Claro que pode dar problema em outra coisa e qualquer um que pegar o código vai me xingar até faltar folego, mas foi o que funcionou, fazer o que?"

Essas situações acontecem por "n" motivos, e não vale a pena ficar tentando descobrir a causa desses problemas na linguagem de programação, ou na ferramenta(exceto se você desenvolve a tal ferramenta). O importante mesmo, é avaliar se a marretada era indispensável, se não existe nenhuma outra alternativa, mesmo que mais cara, para o problema. Geralmente há boas razões para não implementar a solução "decente", pode ser porque o projeto está com prazo apertado, porque a gambiarra não é tão grande, porque fazer a solução decente vai ficar muito caro e também há as razões não tão boas, como o desenvolvedor estar com preguiça(por exemplo), o chefe gostar de marretadas(exemplo também).

Apesar da inegável tentação que é resolver aquele abacaxi em 5 minutos usando o poder de uma bela marretada, eu costumo pensar bem antes de me decidir por uma solução dessas. Marretadas podem gerar muitos outros problemas para os clientes, geralmente gera muitos mal cheiros no código (Refactoring -> Beck e Fowler), isso sem falar no aumento do débito técnico do projeto. Provocar todos estes fatores repetidamente impossibilita a manutenção de qualquer software em um curto período de tempo.

E ai, vai uma marretada hoje?

Desenvolvimento e UML

Ontem conversei com duas pessoas sobre UML, e percebi um fato curioso. Nas duas ocasiões a UML foi considerada como um método para documentação de desenvolvimento, o que não é uma verdade. Se me permitem, estas conversas me inspiraram a escrever o devaneio a seguir.

Claro que o mercado utiliza UML amplamente na elaboração de documentações (principalmente em empresas que trabalham com processos RUP like), mas este é um equivoco. A UML é somente mais uma ferramenta de modelagem, assim como modelos entidade-relacionamento, fluxogramas, organogramas e todos esses diagramas que se encontra por ai.

Em tradução livre, UML significa Linguagem Unificada de Modelagem, e é exatamente isso que ela é, uma linguagem de modelagem. Não há nenhum método por trás disso, nenhum processo, nenhuma dependência; trata-se apenas da definição de uma notação padrão para a construção de alguns diagramas que ajudam, e muito, na representação de conceitos inerentes ao desenvolvimento de software. Acredito que esta confusão ocorre devido a forma como esta poderosa ferramenta é utilizada no dia-a-dia das equipes de desenvolvimento.

Atualmente, observamos um movimento de empresas que possuem ou buscam um processo bem definido(CMMI/MPS.Br/RUP like). Nestes processos, normalmente há uma análise técnica, que gera um artefato, que será utilizado na decisão da aprovação do desenvolvimento. Nestes casos, a UML é muito utilizada para a documentação, que depois servirá como guia ao desenvolvimento. Atualmente existem muitas empresas em busca de uma certificação CMMI ou MPS.BR, onde a solução mais comum é fazer esta documentação técnica utilizando UML extensivamente, justamente porque a UML é provavelmente a melhor ferramenta que existe atualmente para este fim.

Em empresas e equipes ágeis, a história é um pouco diferente, principalmente porque a análise técnica é realizada somente quando a funcionalidade será implementada e a documentação formal é realizada apenas quando realmente necessária. Com isso, a análise técnica passa a ser feita apenas com o objetivo de entender o problema do cliente, para permitir o início imediato do desenvolvimento de uma solução. Nesta situação a UML passa a ser uma poderosa ferramenta de apoio, pois é capaz de facilitar a análise e entendimento do domínio do problema e a transferência de conhecimento entre os membros da equipe.

Com estes exemplos podemos perceber claramente que a UML é uma ferramenta, não um método. Muitas vezes os métodos adotados levam ao uso da UML para a confecção de documentação, mas a UML pode ser utilizada para outras tarefas além da confecção de documentos. É muito mais fácil entender um domínio através de um diagrama de classes do que lendo um texto ou conversando, assim como é muito mais simples entender um cenário através de um caso de uso. Na análise de um problema envolvendo uma equipe e um quadro branco (ou mesmo um papel de rascunho) a UML passa a ser uma ferramenta de comunicação imprescindível. E isso não a torna menos importante ou essencial como em um documento.

O início de Tudo

Se você já me conhece, pule o parágrafo abaixo porque é apenas uma apresentação sobre a minha pessoa.

Meu nome é Milton Roman de Brito, sou de Sorocaba no interior de São Paulo, casado(ainda faltam os trâmites legais, mas isso resolveremos em breve), atualmente estou trabalhando como Desenvolvedor na Datasul Saúde, que é a vertical da Datasul direcionada à área de Saúde. Trabalho com TI desde 1999, e desde 2002 trabalho ininterruptamente com desenvolvimento de software.

A idéia de montar um blog surgiu algum tempo atrás, quando comecei a acompanhar alguns outros blogs, principalmente sobre desenvolvimento de software e gestão. Por algum tempo fiquei na dúvida sobre o tema do blog, mas finalmente descobri que quero compartilhar o pouco que sei sobre desenvolvimento de software e tecnologia, para através dessa troca aprender mais e ampliar meus horizontes. Vez ou outra eu devo fugir deste tema e falar mais sobre coisas pessoais, mas o principal é compartilhar e receber feedback.

Agradeço antecipadamente a todos os meus futuros leitores, que me acompanharão nesta nova empreitada. Espero que apreciem.