Open Serpro?

Reter é perecer...

Ederson Torresini - Professor Universitário, Comunista e Adm Redes

Notícia do SL.org:
"O Serpro, que processa os principais programas de informática do governo e a arrecadação da Receita Federal, anunciou a adoção de uma nova política de sistemas por meio da qual irá reforçar a adoção de software livre e intensificar o desenvolvimento na plataforma aberta, além de buscar a aproximação da empresa com a comunidade open source, de modo a estreitar a colaboração na produção do conhecimento tecnológico brasileiro."

Fonte: http://www.softwarelivre.org/news/10495

Tem certeza que isso ai é um framework?

Saudações a todos... post melancólico... =)
Acredito que seja talvez nossa ânsia por resolver todos os problemas de uma vez só. Ou ainda nossa pretensão em acreditar que possamos realmente resolver todos os problemas de uma vez só...
Engraçado, mas tenho visto muito disso no mundo de desenvolvimento Java. Basta procurar em sites como Sourceforge ou Javaforge pelas palavras "framework"(1 e 2) e você terá a com extatidão o tamanho do problema.

Deve ser pela interpretação errada que alguns líderes técnicos fazem do tema, mas todos os frameworks que presenciei a implementação causaram sempre mais problemas do que soluções. Sempre fui e sempre serei averso à criação de frameworks, ou um pseudo-genérico-subsistema que "deixe as coisas mais fáceis" sem que seja estritamente necessário... como infelizmente nunca estive na posição de tomar este tipo de decisão, apenas paguei pelo erro dos outros, utilizando implementações que não foram feitas para serem utilizadas, mas apenas para servirem de vitrine: "olha, como nosso framework é maravilhoso! implementamos todos os desigs patterns existentes! não funciona para o seu caso de uso, mas mesmo assim ele é maravilhoso!".

Bom saber que exitem pessoas preocupadas com isso além de mim (vide 37signals com o Getting Real)... a apresentação deste post é do cara que ajudou a implementar a API de coleções do Java, Joshua Bloch... até que ele programa um pouco... conhece um pouco do assunto...

Bem, todos deveriam ver este vídeo... sinceramente...
Principalmente akeles que acreditam que sabem implementar frameworks e APIsp. São apresentados conceitos simples (muito simples), mas que muitas vezes são esquecidos: como tentar SEMPRE implementar um sistema que utilize a API ou framework (sempre é pouco, que tal 3 sistemas até realmente afirmar que o framework está pronto??), ou ainda tentar obter o máximo de feedback e tentar deixar tudo o mais simples possivel? ( do one thing, and do it well!) ou ainda documentar o necessário para que outras pessoas possam utilizar o seu framework/API.... entre muitas outras coisas. Confira por si próprio...

Com vcs, o cara:

ABSTRACT

Every day around the world, software developers spend much of their time working with a ... all » variety of Application Programming Interfaces (APIs). Some are integral to the core platform, some provide access to widely distributed frameworks, and some are written in-house for use by a few developers. Nearly all programmers occasionally function as API designers, whether they know it or not. A well-designed API can be a great asset to the organization that wrote it and to all who use it. Good APIs increase the pleasure and productivity of the developers who use them, the quality of the software they produce, and ultimately, the corporate bottom line. Conversely, poorly written APIs are a constant thorn in the developer's side, and have been known to harm the bottom line to the point of bankruptcy. Given the importance of good API design, surprisingly little has been written on the subject. In this talk, I'll attempt to help you recognize good and bad APIs and I'll offer specific suggestions for writing good ones.

Marcio Marchini at edugraf

Saudações a todos!
Bem, na semana passada, em Florianópolis, houve uma apresentação do Marcio Marchini, consultor da Bedarra, empresa Canadense do Dave Thomas. Bem, o Marcio está no Brasil para auxiliar a Audaces na adoção do desenvolvimento Ágil. Estamos crescendo muito com a participação dele!

Desculpe a divagação.

Na terça passada o Marcio fez uma apresentação (aula aberta) com o título "Desenvolvimento de Software no Silicon Valley North", mostrando sua experiência com Desenvolvimento de software e principalmente com Desenvolvimento Ágil.
A palestra foi bastante produtiva, e alguns pontos são importantes ressaltar:

- Na Rational eles usam Diagramas de classe para o desenvolvimento? Resposta: HAHAHAHAHAHAHAHA
- Na Rational eles fazem testes automatizados? Resposta: HAHAHAHAHAHA
- E na IBM? Resposta: HAHAHAHAHAHA
- A Microsoft utiliza o Project para desenvolvimento de Software? Resposta: HAHAHAHAHAH

"Em casa de ferreiro o espeto é de pau"...

Também foi uma oportunidade para o Marcio divulgar os serviços da Bedarra no Brasil... com o CTIP (Continuous Test and Integration Plattaform), que é uma compilação de vários sistemas para promover a Integração Contínua.

O Edugraf disponibilizou os slides da apresentação, e logo estará disponível o video com a palestra... vale muito a pena conferir!

Veja os slides: Marcio-Bedarra-Agile.pdf

[]s

Triste Realidade

Saudações!
Infelizmente é comum encontrarmos projetos em que não houve a menor preocupação com qualidade... seja qualidade na resolução do problema que um código se propõe, seja na qualidade do código produzido.
Lendo um texto clássico, How to Write Unmaintainable Code, percebe-se o quanto é importante a preocupação com a forma que produzimos software.
"Any fool can write a code that a machine understands. Good programmers can write code that a human can understand"

Pense nisso... em desenvolvimento de software, código legal está entre os principais motivos para atrasos no desenvolvimento.


Continue a leitura do artigo, e caso encontre similaridades na forma com que seu código fonte está organizado repense sua forma de trabalho. Coloquei apenas a introdução do texto, mas vale a pena checar o artigo completo.

Introduction

Never ascribe to malice, that which can be explained by incompetence.

Napoleon

Because of the Slashdot plug, hits peaked at 250 a second on this page, and the hit counters stopped kicking over. I received a slew of email with suggestions for ever more subtle techniques of writing unmaintainable code. It took me quite while for me to incorporate all your suggestions. The essay has been like rock candy, seed the string with sugar, soak in sugar water, soon it grew out of control.

In the interests of creating employment opportunities in the Java programming field, I am passing on these tips from the masters on how to write code that is so difficult to maintain, that the people who come after you will take years to make even the simplest changes. Further, if you follow all these rules religiously, you will even guarantee yourself a lifetime of employment, since no one but you has a hope in hell of maintaining the code. Then again, if you followed all these rules religiously, even you wouldn't be able to maintain the code!
General Principles

Quidquid latine dictum sit, altum viditur.
Whatever is said in Latin sounds profound.

To foil the maintenance programmer, you have to understand how he thinks. He has your giant program. He has no time to read it all, much less understand it. He wants to rapidly find the place to make his change, make it and get out and have no unexpected side effects from the change.

He views your code through a tube taken from the centre of a roll of toilet paper. He can only see a tiny piece of your program at a time. You want to make sure he can never get at the big picture from doing that. You want to make it as hard as possible for him to find the code he is looking for. But even more important, you want to make it as awkward as possible for him to safely ignore anything.

Programmers are lulled into complacency by conventions. By every once in a while subtly violating convention you force him to read every line of your code with a magnifying glass.

You might get the idea that every language feature makes code unmaintainable -- not so, only if properly misused.

Street Fighter IV

Ainda com a nostalgia em alta, lah vai mais um video...
Depois de Rambo, o que poderia ser mais "roots" para nós, nascidos em meados da década de 80? Street Fighter!!!
Bem, o video fala por si só



Fonte: Uol Videos

Rambo 4

Tiros... muitos tiros... e mulher bonita... algumas... e muito sangue... Rambo 4



Fonte: Rambo 4 trailer
... Estou me sentindo nostálgico....

Um pouco de Alan Shalloway

Allan Shalloway, da NetObjectives apresenta seu ponto de vista sobre os benefícios do Scrum:

Fonte: Praise for Scrum

A natureza iterativa do Scrum permite o aprendizado rápido. Sendo Scrum baseado num modelo iterativo, é normalmente necessário construir uma parte do sistema e inclusive entregá-la ao cliente para receber feedback e somente assim continuar. Esta natureza permite aprender rapidamente as necessidades do cliente tão bem quanto aprender de que forma otimizar o próprio processo de entregar valor agregado ao cliente.

A inclusão do cliente, assim mais valor pode ser entregue rapidamente. Focando-se na relação entre o cliente e a equipe, Scrum traz à tona um dos maiores desafios para a equipe: conseguir informações concretas sobre o que construir. Scrum provê uma serie de idéias para lidar com clientes sobre a ótica de produtos. Construindo software em partes com o contato direto com o cliente, as funcionalidades mais importantes podem ser entregues rapidamente.

Diminuição do risco de construir a coisa errada. Apresentando o mais rápido possível as funcionalidades implementadas ao cliente, a equipe pode diminuir significativamente as chances de construir ou interpretar errado requisitos. Isto é extremamente importante, sendo o maior risco para o desenvolvimento de software. Construir funcionalidades que não serão utilizadas é obviamente desperdício de recursos. Entretanto é muito pior do que se imagina. A complexidade extra, e não utilizadas, deste software pode causar ainda maiores custos de manutenção, que serão normalmente maiores que o custo de construir a funcionalidade.

A ênfase em na remoção de impedimentos. Sendo Scrum um ótimo processo para iniciar, seu foco em remover impedimentos leva a equipe à procura de continuamente melhorar seu desempenho. Isto não apenas possibilita à equipe gerar mais valor, é um beneficio para a propria criação do time. E uma ótima equipe produzirá muito mais valor com um processo capenga do que uma equipe mediana. Boas equipes com processos ótimos podem ser realmente maravilhosos.

Dá a oportunidade às pessoas perceberem que estão no controle de seu destino. Remover impedimentos da vida de alguém possue um efeito espiritual. Traz à tona a consciencia de que esta pessoa não é a vitma, mas o capitão de suas proprias decisões.

Facilmente implementado pela equipes. O fato de Scrum ser tão simples é impressionante. Com apenas um dia de treinamento já é possível iniciar a sua utilização. Vitórias rápidas são as melhores!

Are you Agile or Fragile??

Saudações!!
Lah vai mais um video: Scott Ambler, autor de dezenas de livros, faz uma apresentação de improviso extremamente Agile Like!!
Video bastante longo e instrutivo, com intensa participação da platéia.


Fonte: Google Video


Desculpem a demora... estamos no meio de uma visita de um consultor canadense (Bedarra), que está ajudando muito nossos projetos Scrum e auxiliando bastante na implantação de um ambiente de Integração Contínua... novidades por ai!
[]s

Technical Success

By Ken Schwaber:
"There is no such thing as 'Technical Success'. If there is not business success, 'Technical Succes' is just an eufemism for failure"

Ou em bom e velho português:
"Não existe esse negócio de 'Sucesso Técnico'. Se não houver sucesso de negócio (ou comercial), então 'Sucesso Técnico' é apenas um eufemismo para fracasso"

Essa frase vai para o Abu, amigo Agilista, que agora sim está mudando para uma nova fase, que com certeza será mais produtiva e menos frustrante!

Free Beer

As profecias estão cada vez mais claras para mim... sim! Colaboração e Liberdade de Escolha são o caminho!

Fonte: Folha de São Paulo
A Free Beer é a nova ação do coletivo dinamarquês Superflex, composto por Bjornstjerne Reuter Christiansen, Jakob Fenger e Rasmus Nielsen. No ano passado, o grupo trouxe polêmica à 27ª Bienal de São Paulo com o Guaraná Power, censurado pela presidência da instituição, que afirmou que não se tratava de uma obra de arte. Apesar do veto, o Guaraná Power, feito em colaboração com a Cooperativa de Agricultores da Região de Maués, na Amazônia, chegou a ser distribuído em museus e na própria Vermelho, durante a Bienal.

"Agora estamos propondo uma marca aberta e, nesse sentido, sugerimos um novo modelo econômico, que permite a qualquer um produzir e distribuir cerveja, a partir de uma receita que é pública, além de criar consumidores não obedientes, como gosta o mercado", conta Fenger.

"Free software"

A Free Beer surgiu em 2004, numa parceria com estudantes da Universidade de Copenhague. "Buscamos transferir os princípios do software livre para algo físico, e a cerveja se tornou um bom exemplo", conta Nielsen. "Por isso, a Free Beer tem sido comparada ao Linux [sistema operacional gratuito] e à Wikipedia", diz o artista.

Quem quiser produzir e comercializar a Free Beer pode baixar do site www.freebeer.org a logomarca da cerveja, de forma gratuita. "Já há Free Beer sendo produzida na Inglaterra, nos Estados Unidos, na Dinamarca e até na República Tcheca", afirma Fenger.

Tornando-se um líder Ágil - parte 3

Entenda como funciona a Liderança sob a ótica do Lean thinking.
Palestra ministrada por Mary Poppendieck - excepcional. Um pouco demorada, mais muito produtiva.

Assista na íntegra (com os slides da apresentação)
http://www.infoq.com/presentations/poppendieck-agile-leadership

Mais trágico que engraçado

Gosto muito do Dilbert, e esta semana recebi a tirinha acima numa lista de amigos da faculdade. E me deixou um pouco chateado...
Não pela tirinha em si, mas pela representatividade que ainda não temos no Brasil. É mais comum do que se possa imaginar o fato de profissionais de TI nunca terem ouvido falar em Desenvolvimento Ágil, mesmo já sendo algo completamente batido, com menções já publicadas na MundoPM, CNN, MundoJava, JavaMagazine entre outras tantas. Mesmo com um termo já no Mainstream mundial, empresas ainda se recusam a dar crétido ao que as empresas mais promissoras estão utilizando.
Seria isto culpa de nós, agilistas? Estaríamos realmente transmitindo os valores corretos às pessoas que abordamos com essa história de Desenvolvimento Ágil? Ou seria mais a nossa incapacidade de transformar o manifesto em algo realmente aplicável?

Talvez falte divulgação concreta e de qualidade. (Um dos motivos que me prontifiquei a ajudar a revista Visão Ágil - para fazer parte da disseminação de conhecimento e esclarescimento que precisa ser feito). Faça você tb!!
Mês passado dei uma palestra na empresa Way2 com o título: O Desafio da Mudança. E foi muito importante esclarescer o que realmente está por trás do Manifesto Ágil: princípios acima de técnicas!!. Técnicas são apenas a consequência da aplicação dos princípios, e é isso que a minha apresentação tenta cobrir. Mesmo que você saiba de cór e salteado o ciclo Scrum, ou as práticas XP, você somente atingirá um pequeno grau de produtividade, qualidade e satisfação. Para ultrapassar isso é necessário buscar os princípios. Bem, no fundo apenas espero que eles tenham gostado da apresentação... =)

Enquanto estivermos apenas pensando em técnicas, ferramentas e procedimentos, não haverá o sucesso real do desenvolvimento Ágil, apenas o aumento da produtividade. E trasmitir isto às empresas é o principal... Como o Yugo sempre diz:"É descobrir o que está por trás dos conceitos e das práticas".

Performing transformation

HBR IdeaCast 69: Rapid Transformation

Rapid Transformation: Harvard Business Digital's Paul Michelman talks with Stanford University's Behnam Tabrizi, author of Rapid Transformation: A 90-Day Plan for Fast and Effective Change.

Entrevista muito boa... impressionante... e bastante alinhado com o modelo Ágil de desenvolvimento...

aliás, vc deveria acompanhar estes podcasts... =) Business language....

File .mp3

Como tratamos nosso departamento de TI

Saudações!
O conto abaixo foi apresentado a mim na especialização que fiz... e traduz muito fielmente experiências que passei em algumas empresas...



A FÁBULA DOS PORCOS ASSADOS
DESCONHEÇO O AUTOR
CONTOS E LENDAS


Certa vez, aconteceu um incêndio num bosque onde havia alguns porcos, que foram assados pelo fogo. Os homens, acostumados a comer carne crua, experimentaram e acharam deliciosa a carne assada. A partir daí, toda vez que queriam comer porco assado, incendiavam um bosque... Até que descobriram um novo método.

Mas o que quero contar é o que aconteceu quando tentaram mudar o SISTEMA para implantar um novo. Fazia tempo que as coisas não iam lá muito bem: às vezes, os animais ficavam queimados demais ou parcialmente crus. O processo preocupava muito a todos, porque se o SISTEMA falhava, as perdas ocasionadas eram muito grandes - milhões eram os que se alimentavam de carne assada e também milhões os que se ocupavam com a tarefa de assá-los. Portanto, o SISTEMA simplesmente não podia falhar. Mas, curiosamente, quanto mais crescia a escala do processo, mais parecia falhar e maiores eram as perdas causadas.

Em razão das inúmeras deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de reformar profundamente o SISTEMA. Congressos, seminários e conferências passaram a ser realizados anualmente para buscar uma solução. Mas parece que não acertavam o melhoramento do mecanismo. Assim, no ano seguinte, repetiam-se os congressos, seminários e conferências.

As causas do fracasso do SISTEMA, segundo os especialistas, eram atribuídas à indisciplina dos porcos, que não permaneciam onde deveriam, ou à inconstante natureza do fogo, tão difícil de controlar, ou ainda às árvores, excessivamente verdes, ou à umidade da terra ou ao serviço de informações meteorológicas, que não acertava o lugar, o momento e a quantidade das chuvas.

As causas eram, como se vê, difíceis de determinar - na verdade, o sistema para assar porcos era muito complexo. Fora montada uma grande estrutura: maquinário diversificado, indivíduos dedicados exclusivamente a acender o fogo - incendiadores que eram também especializados (incediadores da Zona Norte, da Zona Oeste, etc, incendiadores noturnos e diurnos - com especialização matutina e vespertina - incendiador de verão, de inverno etc). Havia especialista também em ventos - os anemotécnicos. Havia um diretor geral de assamento e alimentação assada, um diretor de técnicas ígneas (com seu Conselho Geral de Assessores), um administrador geral de reflorestamento, uma comissão de treinamento profissional em Porcologia, um instituto superior de cultura e técnicas alimentícias (ISCUTA) e o bureau orientador de reforma igneooperativas.

Havia sido projetada e encontrava-se em plena atividade a formação de bosques e selvas, de acordo com as mais recentes técnicas de implantação - utilizando-se regiões de baixa umidade e onde os ventos não soprariam mais que três horas seguidas.

Eram milhões de pessoas trabalhando na preparação dos bosques, que logo seriam incendiados. Havia especialistas estrangeiros estudando a importação das melhores árvores e sementes, o fogo mais potente etc. Havia grandes instalações para manter os porcos antes do incêndio, além de mecanismos para deixá-los sair apenas no momento oportuno.

Foram formados professores especializados na construção dessas instalações. Pesquisadores trabalhavam para as universidades para que os professores fossem especializados na construção das instalações para porcos. Fundações apoiavam os pesquisadores que trabalhavam para as universidades que preparavam os professores especializados na construção das instalações para porcos etc.

As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo depois de atingida determinada velocidade do vento, soltar os porcos 15 minutos antes que o incêndio médio da floresta atingisse 47 graus e posicionar ventiladores gigantes em direção oposta à do vento, de forma a direcionar o fogo. Não é preciso dizer que os poucos especialistas estavam de acordo entre si, e que cada um embasava suas idéias em dados e pesquisas específicos.

Um dia, um incendiador categoria AB/SODM-VCH (ou seja, um acendedor de bosques especializado em sudoeste diurno, matutino, com bacharelado em verão chuvoso) chamado João Bom-Senso resolveu dizer que o problema era muito fácil de ser resolvido - bastava, primeiramente, matar o porco escolhido, limpando e cortando adequadamente o animal, colocando-o então numa armação metálica sobre brasas, até que o efeito do calor - e não as chamas - assasse a carne.

Tendo sido informado sobre as idéias do funcionário, o diretor geral de assamento mandou chamá-lo ao seu gabinete, e depois de ouví-lo pacientemente, disse-lhe: "Tudo o que o senhor disse está muito bem, mas não funciona na prática. O que o senhor faria, por exemplo, com os anemotécnicos, caso viéssemos a aplicar a sua teoria? Onde seria empregado todo o conhecimento dos acendedores de diversas especialidades?". "Não sei", disse João. "E os especialistas em sementes? Em árvores importadas? E os desenhistas de instalações para porcos, com suas máquinas purificadores automáticas de ar?". "Não sei". "E os anemotécnicos que levaram anos especializando-se no exterior, e cuja formação custou tanto dinheiro ao país? Vou mandá-los limpar porquinhos? E os conferencistas e estudiosos, que ano após ano têm trabalhado no Programa de Reforma e Melhoramentos? Que faço com eles, se a sua solução resolver tudo? Heim?". "Não sei", repetiu João, encabulado. "O senhor percebe, agora, que a sua idéia não vem ao encontro daquilo de que necessitamos? O senhor não vê que se tudo fosse tão simples, nossos especialistas já teriam encontrado a solução há muito tempo atrás? O senhor, com certeza, compreende que eu não posso simplesmente convocar os anemotécnicos e dizer-lhes que tudo se resume a utilizar brasinhas, sem chamas! O que o senhor espera que eu faça com os quilômetros e quilômetros de bosques já preparados, cujas árvores não dão frutos e nem têm folhas para dar sombra? Vamos, diga-me?". "Não sei, não, senhor". "Diga-me, nossos três engenheiros em Porcopirotecnia, o senhor não considera que sejam personalidades científicas do mais extraordinário valor?". "Sim, parece que sim". "Pois então. O simples fato de possuirmos valiosos engenheiros em Porcopirotecnia indica que nosso sistema é muito bom. O que eu faria com indivíduos tão importantes para o país?" "Não sei". "Viu? O senhor tem que trazer soluções para certos problemas específicos - por exemplo, como melhorar as anemotécnicas atualmente utilizadas, como obter mais rapidamente acendedores de Oeste (nossa maior carência) ou como construir instalações para porcos com mais de sete andares. Temos que melhorar o sistema, e não transformá-lo radicalmente, o senhor, entende? Ao senhor, falta-lhe sensatez!". "Realmente, eu estou perplexo!", respondeu João. "Bem, agora que o senhor conhece as dimensões do problema, não saia dizendo por aí que pode resolver tudo. O problema é bem mais sério e complexo do que o senhor imagina. Agora, entre nós, devo recomendar-lhe que não insista nessa sua idéia - isso poderia trazer problemas para o senhor no seu cargo. Não por mim, o senhor entende. Eu falo isso para o seu próprio bem, porque eu o compreendo, entendo perfeitamente o seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo, não é mesmo?".

João Bom-Senso, coitado, não falou mais um a. Sem despedir-se, meio atordoado, meio assustado com a sua sensação de estar caminhando de cabeça para baixo, saiu de fininho e ninguém nunca mais o viu. Por isso é que até hoje se diz, quando há reuniões de Reforma e Melhoramentos, que falta o Bom-Senso.

The Enterprise Scrum

Saudações! Eis a minha mais nova aquisição, o novo livro do Ken - The Enterprise Scrum. Seguindo a indicação do próprio Ken Schwaber, na lista scrumDevelopment (sim, ele respondeu um email meu!!! hahahahah que merda).
Os questionamentos que me fizeram comprar o livros estão relacionados à formas de extrapolar a utilização do movimento Ágil, deixando o ambiente de software e TI para uma visão mais ampla e estratégica da empresa. Talvez tenha encontrado uma pequena introdução neste livro...

Estou no início do livro, mas algumas coisas são interessantes:
- Afirmação clara: Scrum não resolverá seus problemas. Pelo contrário, ele os tornará mais explícitos e será difícil não encará-los. Portanto, se você não está pronto para resolver seus problemas, utilizando o scrum, você apenas vai deixá-los mais expostos.
E tenho visto esta a afirmação realmente ocorrer em nossa utilização do Scrum na Audaces. Conflitos sempre ocorrerão. E realmente, este é o maior sinal de que a mudança que propomos com o Desenvolvimento Ágil está acontecendo...
- O livro é mais uma tentativa de vender inúmeros livros e cursos para formação ScrumMasters... como não poderia deixar de ser...


Está sendo interessante a leitura...

[]s

Implantando Scrum em 10 passos

Saudações!!

Bem, aqueles que acessam o site já devem ter percebido que eu disponibilizo uma seleção de posts direto dos feeds que assino (GoogleReader Shared Links)...
E tenho acompanhado muito de perto os escritos de Kelly Waters, do All About Agile. Ultimamente Kelly tem escrito um série de posts sobre como implantar Scrum de forma simples (será mesmo??? )... valeu MUITO a pena a leitura...
Infelizmente não estou com muito tempo para traduzir, e provavelmente o farei em breve... então lá vai o texto em inglês:

How to implement Scrum in 10 easy steps:
- Step #1: Get your backlog in order!
- Step #2: How to estimate your product backlog
- Step #3: Sprint Planning/clarify requirements
- Step #4: Sprint Planning/estimate tasks
- Step #5: Create a collaborative workspace
- Step #6: Sprint!
- Step #7: Stand up and be counted!
- Step #8: Track progress with a daily burndown chart
- Step #9: Finish when you said you would
- Step #10: Review, reflect, repeat...

Errata

Corrigido post anterior (mea culpa mea maxima culpa)

Enterremos o termo "Engenharia de Software"

Enterremos o termo "Engenharia de Software"

Saudações!

Desculpem a demora em escrever... estou um pouco ocupado escrevendo o novo artigo para a revista Visão Ágil...
Mas vamos lá...

Dica quente: Agile Journal de novembro

Sou muito fã das publicações desta revista, e desta vez devo admitir que eles foram muito bem na escolha dos temas, recomendo imensamente...
Me chamou atenção um texto entitulado: Let's Bury the Term Software Engineering, que gostaria de dividir com vocês, fazendo uma pequena introdução em português.
Continuo não acreditando que Desenvolvimento de software não deve ser comparado em engenharia (na verdade gosto mais do termo criado dave Thomas: Jardinagem de software), e o texto me trouxe maiores embasamento sobre minha convicção. E vale muito a pena ser comentado.

"In software, if we discourage changes, we can expect failure. Our constraints come packaged with change. Our constraints are the expectations, needs, wants, and feelings of people."

O texto inicia com uma comparação bastante interessante:

Engenheiros ao trabalharem possuem as restrições principais relacionadas às leis da física, bastante conhecidas, documentadas e estáticas (em termos gerais: leis de newton, mecânica dos sólidos, leis da aceleração, peso, momento, etc). Obviamente que espectativas de clientes são restrições a serem consideradas... entretanto a base do pensamento na construção de uma ponte está focada em axiomas matemáticos e físicos...
Em desenvolvimento de software isso não ocorre!! As maiores restrições que possuimos estão relacionadas a expectativas de stakeholders, mal documentadas, mal compreendidas (se é que um stakeholder sabe realmente o que quer). E como o resultado de nosso trabalho é um produto intengível, leis da física não são prioridade... e pior, as "leis" que regem o desenvolvimento podem mudar a qualquer momento! Inclusive na leitura deste blog...

A principal forma de trabalhar de forma eficiente e produtiva num ambiente mutável como o de criação de software é estar preparado para a mudança, não tentando evitar que ela ocorra, mas incorporando-a. E como resolvemos este problema? Criatividade! Não processos de engenharia...

Daryl Kulak propõe inclusive a abolição do termo Engenharia de Software, na tentativa de mudar nossas convicções que nos prendem a um modelo estático e mecanizado, que não corresponde a nossa realidade. Vou apoiar a iniciativa e não falarei mais em engenharia de software! =)

Leia o artigo completo

Ampliando o blog

Iniciando no Technorati

Technorati Profile

Tipping Point - Guinness

Assista abaixo, a super produção “Tipping Point”, o comercial mais caro dos 80 anos de história da Guinness e dirigido por Nicolai Fugslig, o mesmo responsável por “Balls” da Sony Bravia.

Scrum at Yahoo and Google AdWords.

O vídeo abaixo foi retirado do site AgileSoftwareDevelopment, e conta a história de como Yahoo! e o projeto Google Adwords passaram a utilizar Desenvolvimento Ágil apresentada por Jeff Sutherland (pai da criança)...

Uma aula excepcional... ASSISTAM!

Resumão PIV (pra inglês ver):

Yahoo
1. Yahoo já foi uma empresa "organica". Existiam vários pequenos grupos com a capacidade de realizar qualquer coisa com o mínimo de disciplina.
2. Houve a necessidade melhorar a estrutura da empresa. Assim, os consultores entregaram 300 páginas de um processo Pesado e complexo. Todos odiaram a iniciativa, e não trouxe reais benefícios para aempresa
3. Viram scrum como a possibilidade de retornar às origens, enquanto ainda teriam alguma estrutura. Atualmente o desenvolvimento de produtos é realizado utilizando Scrum (Mais informações: aqui )


Google AdWords
1. Em 2001 existiam inúmeros gerentes no Google. Eles costumavam a dizer a pessoas inteligentes o que elas deveriam ou não fazer. Então a empresa livrou-se deles.
2. Então tornou-se comum inúmeras equipes orgânicas de três pessoas com liderança rotativa. Em torno de 160 equipes se reportavam para uma única pessoa - sem problemas uma vez que os times não necessitavam instruções. Ainda assim aplicações b2b precisavam de muitos retornos do cliente.
3. Scrum tornou-se uma opção bastante promissora. Sua hierarquia é bastante próxima do que eles já possuiam, mas ainda assim possui alguma estrutura e permite facilmente a apresentação de prioridades de forma mais clara.

Com vocês, o vídeo:

Fonte

Bellatorus

Saudações a todos!

É com grande satisfação que anuncio o lançamento do Jogo Bellatorus pela Manifesto Games esta semana! Melhor ainda por ter acompanhado de perto o desenvolvimento e os desafios que o criador, O Petrucio da Pangas Entertainment, enfrentou ao largar o belo emprego que possuia para se arriscar num sonho...

Muito Sucesso Pangaré!!
Segue a descrição do jogo:

Bellatorus is a card battle game, where you'll struggle to destroy your opponent's tower and protect your own. If your are not too fond of wanton destruction, you can focus on building and protecting your tower, and should consider siding with the good guys. If you are a destructive kind of fella, the bad guys are your choice of allies.

Bellatorus is multiplayer, and you will be able to play with your friends over the internet and show them who's boss... You can even create your own decks and new cards with the integrated Bellatorus Deck Editor, and use them to play, and maybe even share them with the rest of the Bellatorus comunity at this site!

Add to that the gorgeous 3D look & feel of Bellatorus, and you've got a card battle experience unlike any you've known before.

Alguns Screenshots
[]s

Mobile Comédia!!

Saudações!!
Seguindo a linha de grandes sites como o UnderGoogle, eu tb criei a versão mobile para A Maldita Comédia!! Muito bom!

Através do site MoFuse, você também pode gerar a sua versão simplificada e acessível por qualquer celular... =) Web 2.0 meu amigos! Chame do que quiser: wikinomics, convergência, web 2.0, futuro, brincadeira de nerd... mas ficou muito bom!!!

http://malditacomedia.mofuse.mobi

Imagens do site:

Caia na Real!!

Fonte: Getting Real (versao pt_BR)

Alguns pensamentos que deveriam nortear todo nosso desenvolvimento (leitura obrigatória se você quiser trabalhar com web):

Execução

Qualquer um pode ler um livro. Qualquer um pode chegar com uma idéia. Qualquer um tem um primo que é um web designer. Qualquer um pode escrever um blog. Qualquer um pode contratar alguém para grudar algum código.

A diferença entre você e qualquer um será quão bem você executa. Sucesso tem tudo a ver com uma grande execução.

Para software, isso significa fazer um monte de coisas certas. Você não pode somente ter uma boa escrita mas falhar em entregar as promessas na sua prosa. Design limpo de interface não vai dar certo se seu código é cheio de gambiarras. Uma grande aplicação não vale nada se promoção pobre significa que ninguém saberá sobre ela. Para pontuar grande, precisa combinar todos esses elementos.

A chave é balanço. Se for longe demais em uma direção, está caminhando para o fracasso. Constantemente procure seus pontos fracos e foque neles até estar nivelado.

Pessoas

Vale a pena enfatizar a coisa que achamos que é o ingrediente mais importante quando falamos em construir uma aplicação web de sucesso: as pessoas envolvidas. Mantras, designs de epicentro, menos software e todas essas idéias maravilhosas não vão realmente importar se não tiver as pessoas certas a bordo para implementá-las.

Você precisa de pessoas que são apaixonadas pelo que fazem. Pessoas que se importam pela seu artesanato – e que realmente acham que é um artesanato. Pessoas que se orgulham do seu trabalho, independentemente da recompensa monetária envolvida. Pessoas que suam nos detalhes mesmo que 95% das pessoas nem saibam distinguir as diferenças. Pessoas que querem construir alguma coisa grande e não se conformam com menos. Pessoas que precisam de pessoas. Ok, não necessariamente essa última coisa mas não iríamos resistir não jogar um pouco de Streisand na mistura. De qualquer forma, quando encontrar essas pessoas, segure-se nelas. No final, as pessoas da sua equipe farão ou quebrarão seu projeto – e sua empresa.

Mais Que Apenas Software

Também vale a pena notar que o conceito de Caindo na Real não se aplica apenas a construir aplicações web. Uma vez que você começa a tocar nas idéias envolvidas, as encontrará em todos os lugares. Alguns exemplos:

• Forças de Operações Especiais, como os Boinas Verdes ou Navy Seals usam equipes pequenas e entrega rápida para atingir tarefas onde outras unidades são grandes demais ou lentas demais para cumprir.


• Os White Stripes abraçam restrições seguindo uma fórmula simples: duas pessoas, músicas enxutas, baterias infantis, manter o tempo de estúdio ao mínimo, etc.


• O iPod da Apple se diferencia da concorrência não oferecendo funcionalidades como rádio FM embutido ou gravador de voz.


• No futebol americano, jogadas rápidas ajudam a ganhar terreno rapidamente, eliminando a “burocracia” das jogadas ensaiadas.


• Ernest Hemingway e Raymond Carver usavam linguagem simples e limpa e ainda assim entregavam impacto máximo.


• Shakespeare revelou, nas limitações dos sonetos, poemas líricos de catorze linhas em pentâmetro iâmbico.


• E assim por diante …

Claro, Caindo na Real é sobre construir grandes softwares. Mas não há razão para parar por aí. Pegue essas idéias e tente aplicá-las em diferentes aspectos de sua vida. Você pode acabar atingindo resultados interessantes.

Em busca de uma Empresa Ágil

Success, particularly today, is a function of a team's ability to react to change, not its ability to plan and follow that plan. How teams are measured affects their adaptiveness. Adaptation—rather than adherence—brings success.

Fonte:The Measure Of A Management System

Tenho pensado muito sobre métricas e formas de mensurar progresso em equipes ágeis, e a forma que estas informações se alinham às informações necessárias para a tomada de decisão dos diretores de uma empresa Ágil.
Num post anterior, trabalhei a questão mundana deste tema, isto é, apresentando ferramentas de medição condizentes com o Processo Ágil. Danilo Sato, em sua teste de mestrado, apresenta de forma detalhada outras ferramentas. Vale a pena a leitura!

Mas gostaria de ir além...

A revista Better Software Magazine, apresenta um artigo mostrando de que maneira métricas de progresso devem ser aplicadas para garantir a real avaliação de desempenho para equipe de Desenvolvimento Ágil. Leia o artigo completo.


Fonte: Wikipedia

Dentro Balanced Score Card(BSC), existem 4 perspectivas bem definidas: Financeira, Cliente, Processos Internos e Aprendizado/Crescimento. A figura apresentada inlustra bem a forma como tais perspectivas se comunicam, numa relação de causa-efeito. Empresas privadas que visam o lucro que somos, é natural imaginar que a perspectiva financeira venha à frente de decisões estratégicas. Gostaria de tratar sobre a perspectiva do cliente.

Cliente
Medidas claras focadas a segmentos específicos devem ser apresentadas a toda a organização. Compartilhar a informação em todos os níveis da empresa, e garantir que indicadores de progresso estejam disponíveis é uma forma bastante clara de alinhamento entre decisões estratégicas e iniciativas.
O Feedback contínuo dos representantes destes segmentos é uma maneira de garantir alinhamento e progresso. Como nos Princípios do Desenvolvimento Ágil, software em funcionamento é a primeira medida de progresso. E sendo assim, transformar a satisfação do cliente em um indicador é um grande passo.
Na lista xpRio, Clavius Tales, da Fortes Informática, apresentou os resultados obtidos utilizando XP. Uma ótima medida de progresso utilizada pela equipe do Clavius foi "satisfação do cliente". Os resultados:

Alguns números que podem não dizer muito, mas que me impressionaram: amanhã finalizamos, com vinte dias de adiantamento, um projeto daqui da empresa, que tinha originalmente um prazo previsto de quatro meses e meio. A equipe era formada por onze colaboradores. Monitoramos a satisfação do cliente através de uma nota semanal entre 0 e 10. Na última semana, a nota ficou em 9,88 - chegou a estar em 7,8. Também monitoramos com uma nota entre 0 e 10, só que diariamente, o moral da equipe. A nota atual está em 9,8 - chegou a estar em 7,9. Estamos trabalhando com um nível de 75% de todas as práticas de XP (versão 2).

Um abraço.

Clavius Tales

Para tomar proveito da ligação entre cliente e desenvolvimento, gerando informações válidas para a empresa, é necessário uma intervenção branda através de medidas de desempenho que alimentarão indicadores do BSC.
Uma forma de se fazer isto é através da Análise de Valor Agregado (do inglês EVA), que pode ser adaptado para auxiliar analistas de negócio e diretores a garantir o ROI mais adequado na utilização do Desenvolvimento Ágil.
Nota Importante:Não estou tratando o ponto de vista do patrocinador de um projeto (o cliente), mas da empresa que utiliza o desenvolvimento Ágil como forma de garantir Qualidade, flexibilidade e menor custo.
Definição: "Earned Value Management (EVM) is a method for integrating scope, schedule and resources, and measuring project performance.” Fonte: APM with Scrum
Um artigo muito interessante (e complexo) que trata desta informação foi publicado pelas empresas SolutionIQ e InfoTech: acesse o artigo.
No documento, os autores concluem que a adaptação da técnica de EVM para o Scrum pode trazer resultados semelhantes à análise do Burndown, e deve ser utilizado em conjunto com as ferramentas do scrum, gerando informações importantes sobre releases e adequação orçamental.

Trabalhar com valor de negócio e agregação de valor ao cliente é uma postura bastante diferente do que estamos acostumados em nossos projetos. Para a maior parte das empresas, um projeto no prazo e debtri di orçamento é mais importante do que garantir que os clientes estejam realmente satisfeitos com as soluções promovidas. Isto é preciso ser alterado para que se possa atingir maiores benefícios relacionados ao Desenvolvimento Ágil.

Measurement systems are crucial to creating an agile enterprise, particularly for those projects that implement new products, services, or processes that will create your future company. If you are creating the future, an extra month or a few extra dollars will be insignificant. If you don't deliver value or you don't deliver innovation, that will be significant. We cannot continue to ask teams to be innovative, flexible, and adapt to changing competitive conditions and then measure their performance by forcing them into narrow expectation alleys. We have to be as innovative with our measurement systems as we are with our methodologies.

Pair it on baby!!

by Cenqua


Solução para todos os problemas com falta de cadeiras para realizar PairProgramming! Agora sim! Você pode realmente aproveitar todos os beneficios da atividade mais polêmica do XP.

Já sei o que vc está pensando:

Mas Victor, minha equipe tem um número ímpar de desenvolvedores! Não vai dar pra usar essa cadeira! Que pena!!

SEUS PROBLEMAS ACABARAM!!!
Mais barato que um programador ou analista, não reclama das gambiarras que você fizer no código, não pede para ir ao banheiro e ainda, se você for bonzinho, pode realizar suas fantasias!!!


Quem não vai querer fazer dupla com essa linda mocinha??

Gostou? Quer saber mais a respeito delas: Real Doll, para todos os pervertidos do mundo!

Entre a Expectativa e a Satisfação

Isso somente ocorre por aqui, em Florianópolis: Mulheres normalmente reclamam que os homens não prestam, e estes por sua vez, sempre dizem que elas querem demais... Interessante os pontos de vista discordantes desse conflito, onde mulheres esperam muito dos homens, que por sua vez, por não terem o real conhecimento do quê elas esperam, acabam passando a imagem de desleixados, relapsos, insensíveis ou inadequados. Seria isto uma realidade? Somos assim tão a quem das expectativas?

É realmente complexo assumir a postura: "Eu sei tudo o que você precisa, não se preocupe, vou satisfazê-la!" e não quebrar a cara dentro de uma relação. Isto porque é humanamente impossível saber de antemão o que pode ou não satisfazer uma mulher sem que ela mesma seja consultada a respeito. E todos nós somos diferentes neste sentido... é necessário que a conquista seja iterativa, isto é, a cada momento descobre-se o que é necessário fazer para suprir uma necessidade, obtém-se o feedack e parte-se para outra necessidade... hehehehe simples né?

Seria nossa atitude como profissionais semelhante? Não estaríamos tentando satisfazer clientes imaginando de antemão tudo que ele possa querer?
Motivação para mim é um assunto bastante delicado, e está solidamente aplicado em conceito do Desenvolvimento Ágil, talvez as características psicológicas e sociais relacionadas ao Scrum e XP é que tornem sua utilização mais agradável para as equipes.

Ciclo de expectativa e a atuação do Cliente

Como consumidores que somos, no dia-a-dia, sempre temos uma opinião formada sobre o que nos agrada e o que não nos agrada. O fato desta noção ser tão pessoal, faz com que muitas vezes tenhamos uma postura pessimista com relação a alguns produtos, já que não existe uma preocupação em produzir algo personalizado, que atenda nossas próprias necessidades.
O modelo de entrega contínua de valor agregado e feedback contínuo em práticas de Sprint Review, Sprint Planning, Jogo do Planejamento, Cliente Presente e iterações menores garante maior satisfação do cliente.
Infelizmente, expectativas são inversamente proporcionais à satisfação. Isto é, lembrando do exemplo amoroso acima, quanto mais uma mulher espera de um homem, menor será a satisfação que ela terá ao perceber que não é possível para seus parceiros suprirem tais expectativas.

O mesmo ocorre com seus clientes, que esperam 6 meses ou até mesmo um ano para poderem visualizar o software em funcionamento. Assim, o resultado esperado por eles não consegue ser atingido, já que eles passaram tempo demais fantasiando como seria o sistema.
No Desenvolvimento Ágil trazemos para nível contornáveis esta balança entre expectativa e satisfação. Isto é: se quanto mais se espera de um sistema maior é a frustração em não obter o resultado, vamos diminuir a quantidade expectativas e, no menor tempo possível, receber o feedback necessário para mudar e adequar-se às novas expectativas que surgem.
Simples? Nem tanto. As várias práticas relacionadas acima se unem para garantir que o cliente esteja sempre satisfeito, ou ainda, que no menor tempo possível ele receberá algo concreto com o qual poderá gerar valor para sua empresa.
Scott Ambler traz de forma exepcional uma comparação entre modelos tradicionais de feedback e os modelos Ágeis, que trascrevi uma parte neste post (sim, em inglês). Leia o documento completo

Technique	Description	Feedback Period
Active Stakeholder Participation	Stakeholders (users, managers, support people, ...) are actively involved with the modeling effort, using inclusive techniques to model storm on a just in time (JIT) basis.	Hours. A stakeholder will describe their requirement(s), then the developer spend several hours, or perhaps day or two, implementing them to produce working software which they can then show to the stakeholder(s).
Agile Model Driven Development (AMDD)	AMDD is the agile version of Model Driven Development (MDD). With an AMDD approach, at the start of a project you do some high-level, initial requirements modeling and initial architecture modeling. During development you model storm on a just in time basis.	Hours. With model storming, you explore a requirement with your stakeholder(s) or a technical issue with other developers and then spend several hours or days implementing working software.
Big Design Up Front (BDUF)	With a BDUF approach, a comprehensive design document is developed early in the project lifecycle which is used to guide the implementation efforts.	Months. It is typically months, and sometimes years, before stakeholders are shown working software which implements the design.
Big Requirements Up Front (BRUF)	With a BRUF approach, a comprehensive requirements document is developed early in the project lifecycle which is used to guide the design and implementation efforts.	Months. It is typically months, if not years, before stakeholders are shown working software which implements their requirements.
Code Inspections	A developer's code is inspected by her peers to look for style issues, correctness, ...	Days to Weeks. Many teams will schedule reviews every Friday afternoon where one person's code is inspected, rotating throughout the team. It may be weeks, or even months, until someone looks at the code that you've written today.
Continuous Integration	The system is built/compiled/integrated on a regular basis, at least several times a day, and ideally whenever updated source code is checked into version control. Immediately after the system is built, which is often done in a separate "project integration sandbox" it is automatically tested.	Minutes. You make a change to your code, recompile, and see if it works.
Model With Others	The modeling version of pair programming, you work with at least one other person when you're modeling something.	Seconds. You're discussing the model as you're creating it, and people can instantly see a change to the model made by someone else.
Model/Documentation Reviews	A model, document, or other work product is reviewed by your peers.	Days to Weeks. A work product will be created, the review must be organized, materials distributed, ... The implication is that it can be weeks, or even months, before the item is reviewed.
Pair Programming	Two developers work together at a single workstation to implement code.	Seconds. You're working together to develop the code, the second coder is watching exactly what the person with the keyboard is doing and can act on it immediately.
Test Driven Design (TDD)	With TDD, you iteratively write a single test then you write sufficient production code to fullfill that test.	Minutes. By implementing in small steps like this, you quickly see whether your production code fulfills the new test.
Traditional Acceptance and System Testing	Acceptance testing attempts to address the issue "does the system do what the stakeholders have specified". System testing, including functional, load/stress, and integration testing, attempts to address the issue "does the system work". With traditional testing the majority of testing occurs during the testing phase late in the lifecycle. Testers will write test cases, based on the requirements, in parallel with implementation.	Months. By waiting until the system is "ready for testing", the testers won't see the system until months after the requirements are finalized.

Entre amores e projetos, seguimos tentando a todo custo gerar um único valor: satisfação.

[]s

Nova edição da Revista Visão Ágil

Saudações a todos!

Bem, após algum tempo de espera, saiu a segunda edição da revista Visão Ágil!
Nesta edição acabei contribuindo com um artigo conceitual sobre TDD. Vale a pena a leitura!

Download do arquivo: http://br.groups.yahoo.com/group/visaoagil/files/edicoes/VA_02.pdf

Nesta edição:

• Visão Ágil pelo mundo
• AS 5 doenças do desenvolvimento de software
• Desenvolvimento Orientado a Testes
• Humor de Projetos
• Um Cardápio de Metodologias Ágeis
• Referências Ágeis
• Desenvolver ou não desenvolver, eia a questão
• Tabuleiro de Projetos

Impressões - Semana Acadêmica do Senac

Saudações a todos!

Recorde para mim: 3 capitais brasileiras em menos de uma semana...
Informação off-topic: Dona Rita, minha mãe, defendeu o mestrado esta semana e está toda feliz pela nota 10 com louvor na PUC/SP. Isso ai! PARABÉNS MÃE!! Estou em São Paulo para comemorar junto com ela essa conquista!! (...)

Voltando.
Quinta feira apresentei duas palestras na semana acadêmica do Senac, como descrito no post anterior. Muito bom!! Para as duas primeiras palestras falando de Desenvolvimento Ágil que fiz... até que foi ótimo!

Bem, foi bastante diferente do que imaginei, mas gostei muito da experiência...
A primeira das apresentação foi para um grupo pequeno de alunos do curso de Análise de Sistemas, e confesso ter ficado um pouco receoso se o foco estaria realmente adequado para os participantes, mas no final correu tudo bem, espero que as pessoas tenham gostado.

A segunda apresentação, com 50 inscritos foi mais tranquila, me senti mais à vontade com as perguntas dos participantes, e o ritmo da apresentação foi mais orgânico. Tanto que consegui falar por mais de 2 horas... absurdo! E só duas pessoas dormiram!! Com certeza um recorde!

Questões importantes: precisamos exercitar mais nosso poder didático e explicar melhor conceitos, evitando que coisas saiam mal entendidas. Mais de uma pessoa me perguntou: "vem cá, como esse tal de XP consegue elimar toda a documentação? Isso funciona mesmo?"... vamos produtores de conhecimento, aos princípios!! Eles nos salvarão da mediocridade do mundo... Agilistas Uni-vos!

Fiquei muito feliz em saber que um grupo de desenvolvimento de um Hospital de Porto Alegre conseguiu utilizar eXtreme Programming em uma equipe php, influenciando os demais desenvolvedores a utilizar algumas práticas. Um comentário interessante que ouvi: "Uma coisa interessante que identificamos é a mudança de postura com os cliente: ao invés do papel de chato, sempre cobrando 'e ai, ta pronto já esse sistema?' que os cliente faziam, passaram a ser os próprios desenvolvedores a cobrar por atitudes mais colaborativas dos clientes: 'e ai, já testou a funcionalidade que lhe enviamos?'". Bom!! Muito bom!!

Abaixo segue uma parte da apresentação... apenas o início... agradeço ao Pelotas (vulgo professor Guilherme) por ter gravado essas partes no celular... tb não consegui editar o video para que ele ficasse na posição correta... hahahah eu sei, eu sei... está horrível, mas alguém sabe me dizer como deixá-lo correto???
PS: desculpem as tosses!! que coisa feia!

Palestra - Semana Acadêmica Senac RS

Saudações a todos!
A convite de um grande Amigo (Guilherme Pelotas), hoje estou de viagem marcada a Porto Alegre apresentar a palestra: Desenvolvimento Ágil - O desafio da mudança no dia 25 (quinta-feira)

A apresentação será feita na Semana Acadêmica das Faculdades Senac.

Bem, minha intenção é apresentar alguns princípios por trás do desenvolvimento Ágil (seguindo o exemplo de Kelly Waters) e de que maneira eles se unem gerando softwares de qualidade e divulgando empresas como o Google (se é que existe alguma empresa como o google). De forma descontraída, quero passar o que acredito ser o mais importante no desenvolvimento de software.

Programação do evento:
http://www.senacrs.com.br/2007/personal/2007109/10361.pdf
Uma correção: Meu nome é Victor Hugo Germano =)

Segue o pdf da apresentação:
http://www.4shared.com/file/27325657/fa6c772e/Desenvolvimento_gil.html

Novamente, minha intenção é divulgar o desenvolvimento Ágil, por isso disponibilizei a apresentação em seu formato real... sinta-se livre para modificá-la, critiá-la e distribuí-la.... desde que mantenha as referências... (chame-me de lunático... mas eu sou completamente partidário da mentalidade Wikinomics) =)
Ainda estou verificando a questão de copyrigth das imagens... mas logo se resolverá.

[]s

Comunidade Ágil

O site AgileJournal é uma ótima opção de leitura, caso queira se interar do que ocorre atualmente no mundo Ágil. A edição mensal da revista está disponível online e ainda existem webcasts, podcasts e artigos tratando do que há de mais novo nos estudos e no modelo de Desenvolvimento Ágil.

A edição desse mês trás destaque para o papel da comunidade na construção de um processo de desenvolvimento mais harmonioso. Vale a pena a leitura do artigo.

What Do Agile and Community Have in Common?

Several forces in the software industry are combining to dramatically shorten product cycle times for even the largest applications. These forces also shorten the feedback loops on an application's quality, usability, and customer relevance. As feedback loops shorten and the number of software deliveries goes up, it becomes paramount to inform and collaborate with employees, customers, and partners in a community setting.
Let me briefly share my perspective on how Web 2.0 communities can enable software teams to scale up their interactions from single-user conversations to collaborating across dozens, hundreds, and thousands of stakeholders. I'll also share my experience from the recent beta program of Agile Commons, a Web 2.0 community where users, partners, and employees collaborated in an agile development process to define the top features during a seven-week release cycle.

Aproveite!

Pra quem gosta de FPS

Tubo bem, talvez seja o vício que possuo por jogos de computador... mas olha que coisalinda ai do lado!?!?!?!?!?!?
3rdSpace Gaming Vest é um equipamento que permite a você sentir as sensações durante um FPS (First Person Shooter). Isto é, sinta explosões, tiros à queima roupa, coronhadas e socos sem precisar sangrar!!
Realmente o mundo do entreterimento está ficando cada vez mais convincente. A roupa foi criada para ser usada na medicina... mas sabe como é, às vezes uma boa idéia não precisa necessariamente ser aplicada ao seu propósito inicial. Chegada marcada para novembro, por U$189,00. (Fonte: YahooNews)


Imagine-se nesse jogo com um colete desses... credo... da até arrepios: o coice das armas e a brisa das explosões... Rambo que se cuide!!

Crysis Island Walkthrough

Tornando-se um líder Ágil - Parte 2

Como acabar com um projeto em nove passos

Se você já passou por projetos que:

• Simplesmente não deu certo


• Foi cancelado e você nem foi avisado


• Foi um desastre de proporções nababescas


• Atrasou por meses, com orçamento estourado e seus cabelos brancos


• Acabou com seu cabelo de tanto stress

Este texto não serve para você... muito provavelmente por o que escreverei você já deve saber...

Bem, com a experiência de quem já passou por projetos assim, Steve McConnell escreveu sobre Nove pecados que não se deve cometer, caso queira que seu projeto seja um sucesso. (não foi o caso de um projeto que participei...). Engraçado, mas o artigo que li é de 2001, mas completamente atual! Que coisa, será que até quando vamos acreditar nos velhos paradigmas??? Quantos projetos mais devem ir por água abaixo?

Vamos lá: (Fonte: The nine Deadly Sins of Project Planning, 2001) (versão online)

1- Planejamento Nenhum!
Obviamente, sem planejamento, não há projeto que se sustente... ou melhor, talvez possa existir por algum tempo, mas efetivamente ele ruirá por não conseguir suportar os encargos que um projeto desse tipo possui. Nota mental: encontre profissionais que saibam planejar e não seguir planos.

2- Falha ao levar em conta todas as atividades do projeto
Não planejar o suficiente. Não menospreze problemas que podem ocorrer durante o percurso do projeto. NUNCA crie planos irreais em que se assume que o projeto estará lindo e maravilhoso não importante o que ocorra com sua equipe, seu sistema, a tecnologia envolvida...
Extremamente importante levar em consideração: versões antigas do projeto, o tempo de setup para deploy da aplicação, a falta de testes suficientes, a motivação e comprometimento da equipe...
Problemas devem ser corrigido no momento em que eles surgirem em sua frente!

3- Falhar ao planejar levando em consideração o risco
Tudo bem se você não gosta de Desenvolvimento Ágil, mas acreditar que a melhor coisa a fazer é deixar para se preocupar com riscos de projeto só quando for tarde demais é burrice! Neste ponto o fato que nós tentarmos priorizar as tarefas, realizando as mais importantes primeiro, é que saimos na frente no controle de riscos. Assim, os pontos mais críticos do sistema são resolvidos primeiro e possuem acompanhamento diário, aliviando a vida de todos.

4- Utilizar o mesmo planejamento para todo projeto
JOGUE FORA A EXPRESSAO: "Esta é a forma que fazemos as coisas aqui na empresa"!!!!!!!!!!!!
Cada projeto deveria ser único, ou você terá grandes problemas em adequar tudo ao seu Modelo Unificado de Projetos...
Este tipo de atitude funcionará muito bem enquanto os projetos forem semelhantes. No momento em que um projeto novo, com escopo e necessidades novas surgir, você estará encrencado.
Não digo para criar um modelo de gerenciamento completamente novo para cada projeto da empresa, mas deixar esse mesmo modelo flexível às especificidades que cada projeto possui. Isso inclui, por exemplo, não tratar um projeto Web da mesma forma que se trata um projeto Desktop.

5- Utilizar modeos empacotados indiscriminadamente
Seguir princípios não quer dizer que não se possam fazer ajustes à realidade do projeto. Acreditar que comprar o livro sobre eXtreme Programming e utilizá-lo a risca vai ser o máximo é assinar o atestato de fracasso.
Identifique necessidades, estude soluções e aplique as melhores práticas de forma coordenada, para que tudo possa ser validade em seu ambiente... e o mesmo serve para o RUP, CMMI, PRINCE2, etc

6- Permitir que o planejamento se torne divergente da realidade
Um procedimento comum em projetos é criar um plano inicial e tentar seguí-lo na medida do possível. E independentemente do que ocorra, tentar manter este mesmo plano no decorrer do projeto...

7- Planejar com muitos detalhes de início
Fato: REQUISITOS MUDAM
Poderíamos discutir por horas aqui, mas não vou fazer isso, deixarei que a experiência de vocês fale por si só.
Além do óbvio disperdício de tempo e recursos que existe ao se planejar com muitos detalhes de início, eu acredito que o maior problema dessa abordagem é o descontrole emocional que isso pode causar numa equipe. Imagine-se trabalhando numa especificação por 6 meses, e então durante o primeiro mês de desenvolvimento descobre-se que a tecnologia ou os requisitos não vão atender à demanda. Todo seu trabalho será jogado fora e refeito... quem não gostaria de um bom saco de pancadas para evitar os pensamentos homicidas neste momento?

8- Planejar pela compensação
Não acredito em curva de aprendizado durante o planejamento. Seja consistente e realista ao traçar um planejamento para adesão de novas metodologias, novas pessoas e novos projetos. Se você planejar supondo que a equipe compensará o tempo perdido, certamente acabará com um projeto atrasado. Já passei por um projeto desses, é frustrante...

9- Não aprender com as experiências passadas
Um projeto que participei, como programador, em que TODOS envolvidos com o desenvolvimento me disseram a mesma coisa: "Que droga, está acontecendo exatamente como nos outros projetos, vai dar tudo errado"...
Aceite o desafio da mudança! Credite na experiência dos projetos, faça sessões de retrospectivas... somente assim pode evitar a repetição de erros conhecidos... é o que dizem: "erra é humano, mas persistir no erro..."

Até mais!

Tornando-se um líder Ágil - Parte 1

Colaboração, delegação de tarefas, feedback, prazos, orçamentos, planejamento estratégico: o que é necessário saber caso você queira se tornar um líder Ágil ?(assumindo que você sabe o que Ágil com A quer dizer)
Se você, como líder, acredita que para comandar uma equipe basta apenas ótimos conhecimentos técnicos, acho melhor você se atualizar um pouco pois os tempos mudaram... Vou tentar apresentar algumas informações importantes para que você possa entender onde Desenvolvimento Ágil pode ajudar a criar equipes mais produtivas e motivadas, empresas mais coesas e principalmente vantagens competitivas. O seu papel como líder é importantíssimo, auxiliando a todos no processo de mudança que está se tornando mais e mais evidente no mercado brasileiro.

Nem tudo são flores

É necessário dedicação, e muita força de vontade, se você quer tonar-se um líder realmente eficiente. O que muitos acreditam ao assumirem uma posição gerencial é que não existe a necessidade de estudo para realizarem sua atividade. Este engano pode levar uma equipe inteira ao desastre. A sensação de poder existente em um cargo de gerente pode torná-lo arrogante e cego às reais necessidades de sua função, portanto não se esqueça: aprenda sempre! com todos!
Um bom início a meu ver pode ser o livro de Paul Glen: Leading Geeks, por ser um livro simples e muito tranquilo de ler... (ah não sabe ler em inglês? desculpe, aprenda! Que tal começar por aki). O livro servirá como uma introdução ao mundo da liderança... aproveite! (alias, o programa de webinars gratuitos que o site do Paul Glen possui é uma ótima pedida! acesse!)
Respondendo à pergunta: pra que isso me serve?, vai um pequeno texto sobre as mudanças que nossa área está sofrendo: (fonte: ComputerWorld

A analista do Gartner disse que as companhias querem melhorar a habilidade em cuidar das informações, o que pode significar, por exemplo, ajudar os negócios a entender melhor a lucratividade de um determinado produto ou eliminar um passo desnecessário no supply chain via automatização.

Ken McGee apontou como evidência de que certas companhias estão se movendo nesse sentido o comportamento dos empregadores de buscar um CIO que não tenha necessariamente uma graduação em Engenharia da Computação ou em Ciência da Computação. “Elas procuram alguém que possa fazer outras coisas além de administrar o ambiente de TI”.

Em cinco anos, defende o analista, o CIO pode estar separado das responsabilidades de administrar a operação de TI. “Talvez a tecnologia tenha um melhor atendimento com a criação de um grupo de operações focado nisso, sendo submetido ao chefe das operações. Achamos que é um debate justo”, diz. É também um tema, ressalta McGee, sobre o qual o Gartner continua pensando.

Joe Montano, chefe de TI do departamento de Energia, Minerais e Recursos Naturais do estado norte-americano do Novo México, disse que o questionamento de McGee ressoou em seu pensamento. “Você pode notar isso acontecendo. Eu tenho ficado cada vez menos nas operações do dia-a-dia, portanto o foco está mais nos negócios”, completou.

Pois é, é necessário atualizar-se. Mas por onde começar?? Particularmente não acredito muito que fazer um curso de Administração em uma unibomba da vida não resolverá sua vida, mas que sabe por um custo muito menor você não consegue o mesmo resultado??
Já pensou em fazer um MBA? Caro? E se eu disser que ele pode sair de graça??!?!? Duvida? (Fonte: Personal MBA Manifesto)

The Personal MBA (PMBA) is a project designed to help you educate yourself about advanced business concepts. This manifesto will show you how to substantially increase your knowledge of business on your own time and with little cost, all without setting foot inside a classroom.

The PMBA is more flexible than a traditional MBA program, doesn’t involve going into massive debt, and won’t interrupt your income stream for two years. Just set aside some dedicated reading time, pick up one of these books, learn as much as you can, discuss what you learn with others, and go out into the real world and make great things happen.

If you’re interested in educating yourself about business, the Personal MBA is the best place to start.

Recomendo livros de Peter Drucker e Demin. Entenda de onde surgiu o conceito para poder aplicá-lo da melhor forma possível. É necessário aprender sobre qualidade total e administração moderna para saber onde quero chegar com esse negócio de Desenvolvimento Ágil

Leia meu amigo, leia muito! É necessário ter o conhecimento base durante a aplicação de práticas de Desenvolvimento Ágil

Onde TI e Businnes se encontram

Fonte: Business and IT – A Marriage Made in Heaven?

To most non-technical people, the mere mention of "IT" can be a real turn off, or result in a roll of the eyes. Although traditionally associated with geeks developing code in a back room, IT - in its very broadest sense - forms the backbone of organizations today, which begs the question: why is there still such a huge communication gap between the IT discipline and the business it powers? This article provides anecdotes and advice for businesses to help them resolve the issues between business and IT, and describes how using Agile methods might just save their relationship.

Talvez este seja o principal documento deste post de hoje... devore-o!

até o próximo...

Integração Contínua

Termo muito importante no mundo Ágil... eu disse muito? Eu quis dizer MUITO!
Sua intenção é ser a panacéia para os males relacionados a builds e gerações de versão para software, além de pode se tornar uma ferramenta bastante importante para tomada de decisão por parte da área gerencial da equipe... a idéia é simples:
um único botão é responsável por disparar uma série de ações que culminam com a contrução do seu sistema... assim, simples... que tal?
A este mesmo procedimento de construção podem ser adicionadas rotinas como:

• Execução de testes automatizados
• Geração de versões internacionalizadas de seu software
• Disponibilizar a versão atual em desenvolvimento para o cliente
• Criação de relatórios de código como:
• Cobertura de testes
• Inspeção de padrões de codificação
• Estatísticas de acoplamento

Todo o processo segue a arquitetura descrita na imagem abaixo:


O cenário acima pode ser descrito como: (Fonte: Continuous Integration)

1. O desenvolvedor envia o código para o controle de versão (SVN, CVS, etc). Enquanto isso a máquina de integração (servidor de Integração Contínua) está verificando o repositório buscando por modificações
2. Logo após um commit ser efetuado, o servidor ao verificar que alguma mudança ocorreu no repositório inicia o processo de build baixando os arquivos do Servidor de Controle de Versão. Assim, o script de build é executado, testes são realizados, relatórios gerados, e todo o projeto é integrado.
3. O Servidor de Integração envia por e-mail ou outros dispositivos o feedback sobre build para usuários específicos do projeto
4. O servidor volta ao estado de Poll buscando por mudanças no repositório

Um comportamento importantíssimo: Esta arquitetura força a equipe a manter sempre em funcionamento o código fonte que existir no repositório, adicionando mais controle a possíveis problemas de implementação ou integração.

Encontrei um site comparativo sobre ferramentas de build contínuo: Continuous Integration Matrix. Vale muito a pena dar uma lida. Autalmente utilizando o luntbuild, sem grandes problemas... bastante eficiente a ferramenta.
No livro, algumas outras ferramentas são citadas:

• Doxygen: Gera diagramas de classes e relacionamento automaticamente para uma infinidade de linguagem. Ferramenta muito poderosa!!
• X10: Utilizado para controlar qualquer mecanismo que utilize radio frequencia. Ideal para colocar um sirene ao lado com servidor de build para que todos saibam que algo de errado foi enviado ao repositório
• Sourcemonitor: Geração de métricas sobre desenvolvimento
• Selenium: Automatize testes de aceitação. Ferramenta show demais!
• Checkstyle: Ferramenta de inspeção de código para Java
  

Um exemplo prático pode ser encontrado no site da Improveit

É isso... =)

Lean Software Development

Saudações!!

Você ainda não ouviu falar de Lean Thinking? Então é melhor se atualizar...
=)

Fontes: Lean Institue Brasil, Poppendieck LLC
Video ao final do Texto

Lean Thinking

Introdução

"Lean Thinking" (ou "Mentalidade Enxuta") é um termo cunhado por James Womack e Daniel Jones para denominar uma filosofia de negócios baseada no Sistema Toyota de Produção que olha com detalhe para as atividades básicas envolvidas no negócio e identifica o que é o desperdício e o que é o valor a partir da ótica dos clientes e usuários.

As práticas envolvem a criação de fluxos contínuos e sistemas puxados baseados na demanda real dos clientes, a análise e melhoria do fluxo de valor das plantas e da cadeia completa, desde as matérias primas até os produtos acabados, e o desenvolvimento de produtos que efetivamente sejam soluções do ponto de vista do cliente. A adoção dessa filosofia tem trazido resultados extraordinários para as empresas que a praticam. Mas prepare-se para as dificuldades na implantação. Poucas empresas têm conseguido replicar totalmente o sucesso e a eficiência operacional da Toyota. Originalmente concebida por Taiichi Ohno e colaboradores, essencialmente como práticas de manufatura, tem sido gradualmente disseminadas em todas as áreas da empresa e também para empresas dos mais diferentes tipos e setores, tornando-se efetivamente uma filosofia e uma cultura empresarial.

Os resultados obtidos geralmente implicam em um aumento da capacidade de oferecer os produtos que os clientes querem, na hora que eles querem, nos preços que eles estão dispostos a pagar, com custos menores, qualidade superior, "lead times" curtos, garantindo assim uma maior rentabilidade ao negócio. Onde Aplicar Desenvolvido originalmente no ambiente de produção da indústria de manufatura, o lean thinking vem sendo aplicado, com grandes resultados em eliminação de desperdícios, nos mais diferentes ambientes das organizações, dentro do conceito de "Lean Enterprise" (administração, desenvolvimento de produto e produção), bem como em empresas de diversos setores, tais como: automobilístico e seus fornecedores, aeronáutico, eletrônico, serviços, construção, mineração, saúde, produção sob encomenda, etc.

Os princípios são listados abaixo:

Elimine o Desperdício (Eliminate Waste)

Os três maiores disperdícios em software development:

• Funcionalidades Extras
  • É necessário um processo que permita criarmos apenas os 20% de funcionalidades que nos dará 80% de valor
• Imobilidade
  • Se seus requisitos são imutáveis, você especifica muito cedo. Se possui ciclos de testes-correção, você testa muito tarde
• Fronteiras bem definidas
  • Fronteiras organizacionais geralmente ampliam em cerca de 25% o custo, criando pontos que diminuem o tempo de resposta e interferem na comunicação

Crie Conhecimento (Create Knowledge )

Planejar é muito importante. Aprender é essencial.

• Utilize o método científico
  • Ensine equipes a: estabelecer hipóteses, conduzir vários experimentos rápidos, crie uma documentação concisa e implemente a melhor alternativa
• Padrões existem para serem desafiados e melhorados
  • Encorpore a melhor prática atual que todos seguem, enquanto ativamente encoraja a todos o desafio de mudar os padrões
• Performance futura é guiada pelo Feedback
  • Uma organização não "advinha" sobre o futuro e cria um plano; ela desenvolve a capacidade de responder rapidamente ao futuro à medida que ele se desponta no horizonte
    

Produza com qualidade (Build Quality In)

Se rotineiramente você encontra defeitos nos sistemas em um processo de verificação, seu processo é defeituoso

• Código à prova de erros com Desenvolvimento Orientado a Testes
  • Escreva especificações executáveis ao invés de requisitos
• Pare de construir código legado
  • Código legado é um código que não possui testes de aceitação ou testes unitários automatizados
• O Big Bang está obsoleto
  • Use Integração Contínua é auto sincronização
    

Crie comprometimento (Defer Commitment)

Elimine a idéia de que iniciar o desenvolvimento deve acontecer através de uma especificação completa

• Quebre dependências
  • A Arquitetura de um sistema deve suportar a adição de qualquer nova funcionalidade a qualquer momento
• Mantenha opções
  • Pense no código como um experimento - faça-o ser tolerante a mudanças
• Adie decisões irreversíveis para o último momento
  • Aprenda o máximo possível até tomar uma decisão irreversível
    

Entregue rápido (Deliver Fast)

Listas e filas servem apenas para atrasar as coisas

• Entregas Rápidas, Qualidade Total e Baixo Custo são completamente compatíveis
  • Empresas que competem com base na velocidade possuem uma grande vantagem em custo, entregam qualidade superior e são mais alinhadas às necessidades dos clientes
• Teoria das Filas funciona para o desenvolvimento, não apenas servidores
  • Focar-se em utilização cria um problema de tráfego que reduz a própria utilização. Diminua o tempo entre ciclos com menos funcionalidades e menos itens em processo.
• Limite o trabalho à sua capacidade
  • Estabeleça uma velocidade confiável e cíclica com o desenvolvimento iterativo. Agressivamente limite o número de listas e filas de espera à sua capacidade de entrega

Respeito as pessoas (Respect People)

Pessoas inteligentes e comprometidas provém a maior vantagem competiva da empresa

• Equipes despontam através de Orgulho, Comprometimento, Confiança e Aplausos
  • O que nos trasforma em uma equipe? Membros estão mutualmente comprometidos a alcançar um objetivo comum
• Forneca liderança efetiva
  • Equipes eficientes possuem líderes eficientes que conseguem obter o máximo da equipe
• Respeito parceiros
  • Alianças em join ventures não devem nunca criar conflito de interesses.
    

Melhore o sistema (Improve the System)

Produtos brilhantes emergem da combinação única de Oportunidade e Tecnologia

• Foque-se em Toda a Cadeia de Valor
  • Do conceito ao faturamento
  • Da requisição do cliente à instalação do software
• Entregue um produto completo
  • Desenvolva um produto completo, não apenas software. Produtos completos são criados por equipes completas
• Meça
  • Meça capacidade do processo através de ciclos de tempo. Mensure a performance do time através de entrega de valor de negócio. Mensure satisfação do cliente através da promoção de redes.