Milton Roman

Quem ganha mais ao usar SCRUM?

2010-07-27T19:01:00.001-03:00

Uma vez, um amigo meu me fez a seguinte afirmação:

"O mais legal do SCRUM é a parte para trabalhar com a equipe."

Sei que deixei a afirmação bem fora do contexto da conversa que tivemos, mas acredito que representa o que muita gente pensa sobre o SCRUM, principalmente quando tem uma primeira impressão. É claro que SCRUM ajuda muito as pessoas a trabalharem juntas, mas está muito longe de ser apenas isso.

Em minha opinição SCRUM é sobre aumentar a eficácia de projetos, e consequentemente de negócios. Melhorar e facilitar o processo de trabalho das equipes é apenas um dos meios através do qual se atinge este objetivo. Ai você se pergunta, WHAT? Vou tentar explicar.

Antes da explicação em si, permita-me diferenciar Eficácia de Eficiência. Eficácia é fazer a coisa certa; já Eficiência é conseguir o melhor custo x benefício para se fazer algo. Portanto, no SCRUM sempre procuramos fazer A COISA CERTA, tenha isso sempre em mente. Muito bem, como?

Quando se inicia um projeto usando SCRUM, as primeiras tarefas do Product Owner são definir a Visão do Projeto e fazer um Backlog Inicial priorizado pelo ROI que cada item pode proporcionar ao Projeto. Já o Time, segue a premissa que sempre deve ser entregue um incremento do produto com qualidade ao fim do Sprint, e isso vale desde o primeiro Sprint. Já o ScrumMaster, tem como principais funções remover impedimentos da equipe, mitigar os riscos do projeto e facilitar a comunicação entre os envolvidos.

Em outras palavras, o Product Owner dever garantir que sejam trabalhados os itens que provavelmente trarão maior retorno ao Projeto seguindo uma idéia original. O Time sempre deve entregar algo que o cliente veja e entenda que possui algum valor e não somente documentações ou frameworks que serão usados como base para o desenvolvimento. Já o ScrumMaster, usando uma metafora, deve manter as engrenagens lubrificadas, para que tudo funcione bem. Trabalhando desta forma, o cliente logo vislumbrará o produto e poderá dar feedbacks rápidos para que a rota do projeto seja corrigida, ou mesmo que o projeto seja cancelado, quando e se necessário.

Todas estas premissas existem apenas para que o projeto seja executado da forma mais eficaz possível. Perceba, que até aqui, em nenhum momento falei sobre equipe. A idéia é sempre trabalhar no que pode trazer um melhor retorno para o projeto e se alguma decisão não foi boa o suficiente, é importante descobrir o mais rápido possível e não apenas no fim do projeto, quando tudo já estará perdido.

Claro que o SCRUM também facilita o trabalho com equipes, mas repito, este é apenas um meio para atingir ao objetivo. Espero ter deixado isso um pouco mais claro, pois muitas vezes vejo as pessoas na contra-mão deste pensamento.

Algumas considerações sobre Liderança

2010-07-05T18:17:00.004-03:00

Propositadamente, não falei muita coisa relacionada a trabalho ou estudo no último post, principalmente porque queria ter um post só para isso. A questão é, o "De Volta a Ativa" vale só para o blog, porque na realidade nunca sai da ativa hehe. Para quem não sabe, atualmente estou atuando como líder de uma equipe de desenvolvimento, e isso faz pouco mais de um ano atualmente. Para pessoas que, como eu, tem uma formação quase que exclusivamente técnica, este provavelmente é um dos maiores desafios que se pode encontrar na vida profissional.

Hoje em dia acredito que provavelmente o pior e o melhor em uma posição de liderança é justamente trabalhar com pessoas. Controverso não?

Neste pouco tempo como líder aprendi muito, principalmente sobre atitudes e postura, e acho que vale a pena deixar meus dois centavos sobre as lições que aprendi. Primeiro dicas que acho serem uteis para qualquer profissional.

Entender o objetivo que deve ser alcançado quando te pedem para executar uma tarefa é fundamental, nem sempre dar o seu melhor é o melhor, como diria Roberto Justus, as vezes, menos é mais.

Antes de criticar algo, tenha em mente que tudo tem uma explicação. Certifique-se que esta explicação não é aceitável antes de criticar. Tenha certeza que a sua informação é verdadeira, a sua credibilidade depende disso.

Quando uma decisão depende exclusivamente de você, sempre há pelo menos duas opões, que normalmente se dividem em fazer o fácil e fazer o certo.

De nada adianta prometer algo que você não sinta um mínimo de segurança de que conseguirá cumprir.

Como bem demonstra Ricardo Semler em seu "Você está Louco", o mundo é feito de pessoas e não de cargos e regras. NUNCA ignore este fato.

Saber trabalhar em equipe não é mais opcional no mundo de hoje.

Você (independente de quem seja) sempre será medido por seus resultados. Sempre terá que provar o seu valor para o mundo.

Quanto mais você se mostra capaz, maior será a capacidade de suportar pressão e responsabilidade exigidas.

E agora algumas dicas para líderes, ou aspirantes.

A vida de um líder está longe de ser fácil.

Você sempre será alvo de críticas, por mais que se esforce. Tenha em mente que não serão as críticas que definirão os seus resultados, mas você pode aprender muito com elas.

Um líder não se faz apenas pelo cargo atribuido pela empresa, ou por quem quer que seja, mas sim por suas atitudes.

Deixar o seu objetivo o mais claro possível ao passar uma tarefa é primordial, certifique-se que entenderam o que você quer e o que você espera.

Seja útil, de nada adianta um líder que só serve para cobrar e encher o saco. O nome disso é capataz.

Você não é Deus, não conseguirá produzir o mesmo que uma equipe de 5 pessoas sozinho. Você precisa e depende da sua equipe para atingir seu objetivo. NUNCA ignore este fato também.

O seu resultado não depende exclusivamente do seu trabalho, você certamente não levará os louros do sucesso sozinho, mas apesar disso, pode levar toda a culpa pelo fracasso.

Criar um ambiente onde as pessoas se sintam estimuladas a serem dedicadas e criativas é muito díficil, complicado e dá uma tremenda dor de cabeça.

Por outro lado, desanimar alguém é muito fácil.

Ficar desanimado por alguns dias com alguma situação específica também é muito fácil, díficil é não puxar a equipe inteira com você. O problema é que a equipe não volta ao normal depois de alguns dias. Na maioria das vezes o problema não é tão grande assim, mas acaba ficando por causa da sua postura.

Pessoas não são robos, logo, não pensam como você, não agem como você, nem resolvem um problema da mesma forma que você e muitas vezes não fazem exatamente o que você pede(mesmo quando você faz uso do poder de sua posição, dando uma ordem direta). O resultado que vão te apresentar não será previsivel, você será surpreendido muitas vezes, e quando isso acontecer você pode....

Se surpreender com uma solução muito mais eficiente que a que você tinha proposto ou com uma performance muito superior que a que você estava esperando...
Se surpreender com uma pessoa enroscada em algo absurdamente básico e não conseguir fazer a tarefa.

Isso é apenas a minha opinião, e acredito que ainda vou aprender muita coisa. Também acredito que devo mudar de opinião sobre muita coisa, porém, gosto de compartilhar minha opinião, e se for esperar saber tudo sobre tudo para depois escrever, este será um blog postumo e olhe lá.

De volta a Ativa

2010-06-28T14:49:00.003-03:00

Bom pessoal, estou voltando o blog a ativa. Neste último ano aconteceram muitas coisas, mas muitas coisas mesmo. A minha idéia é voltar a postar coisas aqui no blog mais frequentemente, porém, o meu tempo está muito, mas muito escasso mesmo, então para conseguir isso pretendo fazer posts menores.

A minha idéia para este blog desde o início era compartilhar conhecimento e em alguns momentos, acontecimentos da minha vida. Sempre gostei de poder compartilhar o que aprendo, por mais que todo mundo já saiba antes de mim hehehe. Um blog é uma ótima ferramenta para isso. E quem já sabe o que estou falando, não perde tempo e vai cuidar de outras coisas.

No último ano aconteceram muitas coisas, vou tentar resumir. Continuo dando aulas. Já ministrei as disciplinas de Engenharia de Software, Programação Orientada a Objetos e mais recentemente Programação Estruturada. Gosto muito de dar aulas, é muito recompensador ver um aluno te perguntar "Professor, vale a pena comprar uma vídeo aula pra aprender Java?", sendo que o resto da turma ainda está aprendendo o que é um "While".

A Yasmin nasceu em 18/10/2009, e agora já é a menininha de 8 meses mais linda do mundo(ao menos para o pai coruja aqui). Já está aprontando todas, espirra na colher cheia de comida, faz xixi no trocador, sorri pra todo mundo, se mata de dar risada brincando as 23 horas da noite(para desespero do pai e da mãe), faz manha pra ir no colo, pescoceia a casa inteira quando a mãe vai dar aula, vai pra escolinha sem nem olhar pra trás, se encanta com árvores, agarra o pai pelo nariz, lança brinquedinhos no chão, etc, etc... Eu poderia ficar o dia todo aqui falando dela. Para os nerds de plantão, agora que sou pai sei como o Cel. Hughes do Fullmetal Alchemist se sente.

Bom... tem mais coisas que tenho feito.... mas continuo no próximo post.... abraços pessoal.

Afinal, o que é a Vida?

2009-07-21T01:49:00.001-03:00

Algum tempo atrás acabei me deparando com uma situação diferente, que me levou a divagar um pouco sobre a vida do ser humano neste planetinha chamado Terra.

É curioso como a vida começa e se desenrola, já pensou sobre isso? O ser humano surge de apenas uma celulazinha, só uma. Essa celula começa a se dividir e crescer, logo se torma um conjuntinho de células de tamanho microscópico. O conjuntinho de células continua crescendo, tomando forma, até que podemos dizer que ele é promovido a embrião. O embrião continua crescendo, se desenvolvendo, até que é promovido novamente e se torna um feto. O feto continua se desenvolvendo, crescendo, até que finalmente o útero se torna pequeno demais e acaba expulsando o feto.

A partir deste ponto, o feto vem ao mundo como recém-nascido, mas nem por isso deixa de se desenvolver. É muita coisa nova, muita coisa para aprender. O recém-nascido ou bebê precisa aprender a se comunicar pra sobreviver, primeiro chorando, depois com gestos. Também precisa desenvolver seus sentidos para sobreviver. Precisa aprender a engatinhar, andar, falar, se vestir, comer por conta própria, ir ao banheiro e resolver todas as suas necessidades fisiológicas.

Depois dessa maratona de desenvolvimento e aprendizado sobre o próprio corpo, o bebê entra na infância, onde também começa a aprender a se relacionar com outros seres humanos. É nesse ponto que a criança entra na escola, para aprender o básico do conhecimento humano, e esse conhecimento não é apenas o que os professores ensinam. A criança aprende sobre amigos, aprende sobre seus sentimentos, aprende a se comportar em momentos díficeis, aprende a competir, aprende valores e mais muitas outras coisas que vão definir muito de suas ações durante sua vida.

Depois da infância vem a adolescência, uma etapa incrível e terrível ao mesmo tempo, onde o mundo começa a se mostrar muito mais cinza em alguns momentos e brilhante em outros. Responsabilidades surgem, as pressões aumentam, as emoções e sentimentos são mais intensos, há muitas novas experiências e muitos caminhos. E isso só acaba quando finalmente a mente se desenvolve a tal ponto em que o adolescente pode ser considerado um adulto.

Diz-se que a partir da idade adulta é só ladeira abaixo, afinal, após pouco tempo de vida adulta a pessoa começa a perceber os primeiros sinais de que o corpo não é eterno. Não acredito que este seja o início do fim, o corpo pode até começar a definhar lentamente, mas por outro lado, a alma sempre está em busca de novos horizontes. Na vida adulta o individuo aprende mais sobre suas limitações, aprende o que realmente é importante e vale a pena na vida.

Ainda não sei muito mais sobre o resto desta caminhada pois estão no meio dela, mas tenho certeza de que ainda aprenderei muitas coisas. Também estou certo de que terei muitas emoções e alegrias nesta vida. E terei também algumas frustrações e decepções.

Este post, apesar de grande, é a minha primeira entre muitas homenagens a uma nova vida que está a caminho, que é a da minha filhota Yasmin, a quem já amo muito. E também é uma homenagem a minha mulher, Cristiane, que tem passado um cortado durante toda a gravidez, e mesmo assim sempre está me apoiando quando preciso. Vocês são as mulheres da minha vida.

Finalmente, para os amigos que ainda não sabem, mesmo que não leiam aqui ficarão sabendo em breve. Os amigos que já sabem, não fiquem tristes se não contei antes, essa é uma nova grande maratona e eu levei um tempo para me tocar da magnitude deste acontecimento para a minha vida.

Processo de Certificação Scrum

2009-03-11T21:53:00.005-03:00

O processo de certificação em Scrum é um pouco diferente das certificações que vemos no mercado atualmente. Para esclarecer um pouco melhor este processo, vou colocar abaixo uma interpretação minha do processo de certificação. A descrição oficial, está aqui.

No primeiro nível de certificação, que seriam os treinamentos de Certified Scrum Master e Certified Scrum Product Owner, a pessoa apenas recebe o treinamento de um Trainer aprovado pela Scrum Aliance. Este treinamento atesta que o participante possui conhecimento e é capaz de aplicar o Scrum, mas não comprova experiência ou habilidade.

No segundo nível de certificação, a pessoa precisa responder a uma série de questionamentos sobre a utilização de Scrum em um projeto em que participou. Estes questionamentos são avaliados por uma comissão da Scrum Aliance, que pode fazer novos questionamentos para esclarecer algo que não esteja claro. Esta comissão verifica se no projeto avaliado os conceitos de Scrum foram seguidos corretamente, conferindo (ou não) o título de Certified Scrum Practitioner. Nesse nível, a certificação também atesta experiência e habilidade com a implantação e utilização de scrum.

No terceiro nível da certificação, a pessoa passa a ter um tutor, que vai treiná-la para a realização de treinamentos de novos Certified Scrum Masters e Certified Scrum Product Owners, ou então atuar como coach de Scrum em organizações. A impressão que tenho, é que este nível da certificação é algo parecido com um "treinamento Jedi", mestre e aprendiz. Quando o tutor decidir, o candidato passa por uma avaliação, onde uma comissão pode aprová-lo como Certified Scrum Trainer ou Certified Scrum Coach. Nesse nível, a certificação atesta que a pessoa é capaz de transmitir conhecimento para outras pessoas que estejam interessadas em aprender Scrum.

Concordo quando pessoas da comunidade ágil dizem que os nomes devam ser diferentes, pois não demonstram fielmente o objetivo de cada nível de certificação. De qualquer forma gostei muito do processo de certificação, acho muito mais honesto que muitas das certificações "decore o livro, responda o questionário de Xzinho e você será um super especialista no assunto", que vemos por ai. Talvez os nomes pudessem ser diferentes, para deixar mais claro o significado de cada nível, mas isso é outra história.

Notícia +/- de última hora: Segundo o site da Scrum Aliance, há um novo sistema de avaliação em fase de aprovação, onde as certificações para CSMs e CSPOs serão realizadas através de uma prova e não mais pelo feeling dos trainers. Até onde entendi, a cada 2 anos a pessoa precisaria fazer uma nova prova comprovando que está atualizando seus conhecimentos e renovar a certificação. Os detalhes serão finalizados na Scrum Gathering Orlando, em breve teremos novidades.

Certified Scrum Master

2009-02-24T18:10:00.001-03:00

Finalmente tirei o escorpião do bolso e fiz o meu Certified Scrum Master agora nos dias 18 e 19 de fevereiro pela Caelum. O instrutor foi o Alexandre Magno, que já é uma figura mais do que carimbada quando se fala em Scrum. Já queria fazer este treinamento há um bom tempo, mas por uma série de motivos ainda não havia me dedicado como deveria a este objetivo.

Como algumas pessoas andaram me perguntando, "E ai, foi difícil a prova?", acho legal deixar algumas coisas claras para evitar desentendimentos. O treinamento de Certified Scrum Master é um treinamento de imersão em Scrum, com a duração de 16 horas, e é ministrado por um Trainer Certificado pela Scrum Aliance. Este treinamento certifica apenas que o participante possui conhecimento em Scrum, e que está apto a trabalhar em implantações de Scrum em qualquer organização. Por outro lado este treinamento não certifica que o participante tenha experiência com Scrum ou qualquer tipo de habilidade necessária para a sua implantação. Por outro lado, por experiência própria, tenho certeza absoluta que qualquer Certified Scrum Master tem um conhecimento muito maior do que qualquer pessoa que tenha tentado aplicar Scrum por conta própria, apenas pesquisando e estudando.

Trata-se de um treinamento extremamente dinâmico e com muito conteúdo e prática também. Eu que venho estudando e procurando aplicar Scrum a mais de um ano aprendi MUITO, mas MUITO MESMO neste treinamento. Durante o treinamento há muitas dinâmicas e debates que mostram claramente vários dos conceitos e práticas propostos pelo Scrum.

Por causa disso tudo, não há nenhuma prova durante o processo, mas isso não significa que esta certificação seja uma enganação, muito pelo contrário, o treinamento é absurdamente bom. Caso alguém pense que é só ir para o treinamento e dormir o dia todo para ser certificado, fique sabendo que o instrutor tem toda a autoridade de não certificar o participante se em algum momento perceber que este não absorveu o conteúdo necessário a um Certified Scrum Master.

Todo o processo de certificação da Scrum Aliance é bem diferente do que estamos acostumados a ver, mas entendendo melhor o processo de certificação, fica fácil perceber que é um sistema bem mais honesto que a maioria das certificações que vemos por ai. Antes eu tinha muitas dúvidas, mas agora que entendi melhor como funciona, eu achei que o processo todo é muito legal. Agora, para não me estender muito por hoje, vou deixar esta parte para o próximo post.

Dica - Pós-Graduação em Gestão Estratégica de TI

2009-02-17T18:19:00.004-03:00

Pessoal, esta é uma dica que recebi de minha esposa, Cristiane. A Academia de Ensino Superior de Sorocaba está abrindo mais uma turma para a Pós-Graduação em Gestão Estratégica de TI. O contato que tenho com a instituição é mais através da Cris, mas pelo pouco que vi, já pude observar que se trata de uma instituição séria, que realmente quer formar profissionais. E nesses tempos que a cada dia surgem 3 novas faculdades, onde 2.9 delas querem só faturar em cima dos alunos e explorar os professores, já é muito mais do que se pode esperar.

O coordenador da área de TI por lá é o Prof. Castelan, com quem já tive aulas na minha pós-graduação, e sem dúvidas é muito competente. Abaixo segue o texto que recebi por e-mail para divulgação do curso.

É com satisfação que anunciamos o inicio das aulas do nosso curso de Pós-Graduação em Gestão Estratégica de TI da Academia de Ensino Superior. O curso inicia-se em 14 de março aos sábados das 08:00 às 12:30hrs., e já estamos com as inscrições abertas.

Maiores informações com Melissa Franchini por email (melissa.franchini@aes.edu.br) ou pelo telefone 15 3331-7201. Esta iniciativa faz parte da nossa estratégia em oferecer ao mercado de Sorocaba e Região cursos de extensão e pós-graduação de forma a permitir a educação continuada de seus alunos e profissionais de TI, atualmente em franca expansão.

Quanto ao investimento, temos três opções para pagamento: 18 parcelas mensais de R$448,00, ou 20 parcelas mensais de R$ 418,32, ou 24 parcelas mensais de R$361,20. Ex-alunos e funcionários de empresas parceiras da Academia de Ensino Superior tem descontos.

Fique a vontade para me contatar e/ou agende uma visita para conhecer melhor o projeto pedagógico e as instalações da Academia de Ensino Superior. Será um grande prazer recebê-lo.

Também é possível obter mais informações no site da Academia de Ensino Superior.

Um conto de Matilda

2009-02-10T18:20:00.004-02:00

Matilda, como tantos outros, era apenas uma estagiária procurando conquistar o seu espaço. Sempre decidida e esforçada, se preparou muito para ser "alguém" na vida, sempre tirou boas notas na escola, fez curso técnico, está na faculdade, começou a trabalhar na área já nos primeiros semestres. Apesar de receber uma ajuda dos pais, sempre procurou ajudar no que podia, seja em casa ou com a mensalidade da faculdade. Depois de passar por dois estágios em que era apenas "mão-de-obra barata", conseguiu uma vaga em uma empresa que aparentemente tinha um programa de estágio de verdade, que desenvolvia e absorvia seus estagiários para o quadro de funcionários.

Após alguns meses no novo emprego, Matilda começou a perceber que as coisas não eram bem como lhe falaram. Era uma empresa familiar, onde o principal requisito para ser promovido, ou mesmo receber um aumento, é ser parente ou amigo próximo dos donos. Um ambiente onde quem não está no circulo íntimo de amizades dos donos e diretores é tratado como lixo, literalmente. Após um ano de estágio, e nada de se falar em efetivação, Matilda se viu assumindo funções de Bartolomeu e Rosana, que já estavam a 10 anos na empresa quando foram demitidos, Bartolomeu foi dispensado por ficar doente, de cama, e faltar UM dia do trabalho, já Rosana foi considerada incompetente por se negar a mudar de setor, ela passaria a fazer café e tirar cópias de documentos o dia inteiro. Com o tempo, pessoas pedindo as contas passou a ser algo comum, e Matilda simplesmente foi acumulando funções de outras pessoas.

Apesar de tudo, Matilda sempre se esforçou para dar conta de tanto trabalho, mesmo com o histerismo de Jorge, seu diretor. Jorge é o tipo de pessoa que quer tudo pra ontem, adora se gabar, dizer que é o bom, não consegue fazer nada sozinho, mas tem uma garganta muito boa(seus berros são bem potentes).

Se você acha isso atormentante, saiba que o tormento de Matilda estava apenas começando. Em uma bela manhã de sexta, Jorge decidiu que iria assistir o carnaval do Rio de Janeiro, e para isso, mandou que Matilda conseguisse lugares no camarote vip do sambódromo para ele e sua mulher. Após uma manhã inteira de ligações, e-mails, faxes, e nada de conseguir o tal camarote vip para Jorge, Matilda decidiu trabalhar de verdade, e fazer o faturamento de uma conta que já estava atrasado. Esse faturamento era algo em torno de 400 mil reais para a empresa, afinal, é pra isso que era paga e não para resolver coisas pessoas de Jorge.

Jorge, inconformado por Matilda deixar um assunto tão importante de lado, passou a se certificar pessoalmente de que Matilda sempre desse o seu "melhor". E procurou fazer isso no seu melhor estilo, humilhando-a em cada oportunidade que tinha. Para Jorge, Matilda não era capaz de fazer uma ligação direito, não conseguia preparar documentos direito, tudo estava mal-feito, errado e atrasado. Matilda passou a ter ainda mais trabalho a fazer, e como nem sempre dava conta, passou a ser considerada mais incompetente a cada dia, e Jorge usava cada uma destas chances.

Em certa ocasião, já no limite, Matilda estava decidida a sair daquele inferno. Depois de literalmente explodir e gritar e xingar meio mundo, seu gerente, Fábio, a convenceu a tirar a tarde de folga, descansar e pensar melhor. A noite, Fábio ligou para Matilda novamente e a convenceu a continuar na empresa, porque logo iriam resolver a situação dela.

Realmente, a situação foi resolvida três semanas depois, após 3 meses de humilhações acabou o contrato de estágio de Matilda com a empresa. Adivinhe o que aconteceu? Matilda foi dispensada, e adivinha o que mais pesou? Foi justamente Matilda ter deixado de lado o tal camarote vip de Jorge, para TRABALHAR e faturar para a empresa.

Agora, enquanto Jorge vai gastar míseros 200 reais a mais do que planejava para aproveitar o seu camarote vip no carnaval, Matilda tem que procurar emprego em meio a maior crise dos últimos tempos. A bolsa-estágio ajudava, e bastante a pagar a mensalidade da faculdade, e mesmo com todas estas humilhações, Matilda sempre aguentou firme, pois estava em busca de um futuro melhor.

É nessas horas que percebo que o ser-humano sabe ser uma criatura egoísta, mesquinha e baixa. Humilhar uma pessoa durante meses até o seu limite, depois convencê-la a não pedir demissão, só para poder demiti-la e "sair por cima" é o fim. E só para constar, esta historinha é muito mais real do que muita gente pode imaginar, mas tenho certeza que Matilda vai tirar de letra, afinal ela já passou por situações bem piores que essa e sempre que a coisa apertou, me deixou muito orgulhoso.

Avaliação da Pousada

2009-01-29T18:15:00.003-02:00

Como bem disse no último post, depois da odisséia da pousada filha da p... que não cumpriu com a própria palavra, hoje vou fazer uma avaliação da pousada que cumpriu com o que prometeu. Antes de mais nada, vamos apresentar a pousada escolhida, que é a pousada praia do tombo. É uma pousada bem localizada, próxima a praia, a dois mini-mercados e também é bem tranquila. Vou fazer uma análise do que, a meu ver, foram os pontos positivos e negativos da pousada.

Pontos Positivos
- O pessoal da pousada é super atencioso, inclusive o dono é muito tranquilo e gente boa
- O lugar é muito tranquilo, dá pra chegar e descansar a hora que quiser
- A pousada fica a 5 minutos de caminhada da praia
- Se quiser ir de turma, tem espaço para um bom churrasco
- O café da manhã, apesar de simples é muito bom e gostoso
- Tem uma mini piscina para a criançada se divertir enquanto os "véios" descansam
- O quarto tem ar-condicionado, muito bom para esses dias amenos de verão que temos
- Os horários de check-in e check-out diferenciados, poder sair no domingo até as 18:00 hrs foi espetacular, deu pra aproveitar a praia com calma de manhã e até dar uma descansada antes de pegar a estrada a tarde

Pontos Negativos
- Eu achei o quarto pequeno e bem simples, o banheiro então nem se fala, uma pessoa um pouquinho maior não iria conseguir entrar no box pra tomar banho
- Não tem estacionamento para todos os hóspedes, talvez o lugar seja tranquilo e tal, mas eu fico com um pé atrás de deixar carro na rua
- A cama de casal é box feita com dois colchões de solteiro, uma solução bem versátil, mas é osso dormir com aquele calombo que fica no meio da cama

Para quem quer saber como foi a viagem, foi bem legal, aproveitamos bastante. O tempo ficou nublado boa parte do tempo, mas mesmo assim estava bem quente, permitindo ótimos banhos de mar \o/. No domingo estava um calor infernal, mas depois do almoço ficamos na pousada descansando um pouco, o ar-condicionado nessa hora foi nossa salvação.

O fato curioso foi que pegamos uma pequena tempestade quando estávamos em um mirante. Pudemos ver a tempestade chegando, e eu tirei algumas fotos. Estas aqui são do mesmo lugar, da mesma praia, a diferença é que a primeira é uma foto de toda a praia, já na segunda é um zoom do que está no canto inferior direito da primeira foto, e a chuva já estava chegando e muito rápido, essa reviravolta toda foi questão de 5 a 10 minutos.

Momento Revolta - Tentando reservar quarto em Pousada

2008-12-19T19:08:00.003-02:00

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"

2008-12-15T19:11:00.000-02:00

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

2008-12-10T19:33:00.004-02:00

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

2008-10-09T18:20:00.005-03:00

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

2008-09-25T18:02:00.004-03:00

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

2008-09-01T18:06:00.004-03:00

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

2008-08-29T18:13:00.007-03:00

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

2008-08-27T18:51:00.010-03:00

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

2008-08-22T18:10:00.004-03:00

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

2008-08-11T18:19:00.007-03:00

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

2008-08-04T16:35:00.006-03:00

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

2008-07-30T19:15:00.002-03:00

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

2008-07-25T19:39:00.005-03:00

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.