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.

Compartilhando equipes Ágeis

Product Owner único, Scrum Master responsável por manter a ordem e o foco no projeto, e uma equipe isolada do mundo exterior, criada somente para trabalhar num único projeto.
Seria o ideal, mas o mundo não funciona deste jeito. Na verdade o que acaba acontecendo é que empresas não possuem pessoas suficientes para tocar todos os projetos, fazendo com que um único desenvolvedor seja responsável por mais de um projeto.
A resposta natural ao problema de possuir uma única equipe e vários projetos é dividir o time. Simples e funcional... mas muitas vezes o tamanho da equipe não permite tal divisão. Então como tratar?

Kelly Water, do AllAboutAgile, dá uma solução interessante em poucos passos:

Trate a equipe como um único elemento
Não divida a equipe, tente reuní-la em torno de um único foco por vez. como fazer isso?
Tenha um Product Owner para cada projeto que a equipe será responsável. (muito importante!)
Determine, baseado em seu orçamento, o percentual de utilização da equipe para cada projeto. ex: 3 projetos: 70% 10% 20% da capacidade da equipe será alocada (leia-se velocidade).
Faça reuniões com todos os Product Owners e esclareça que eles só terão o percentual definido de tarefas para uma Sprint.

Talvez seja necessário aumentar a granularidade dos requisitos de cada Product Backlog, mas não se esqueça: estime apenas no Sprint Planning.

Deixe a cargo da Equipe a divisão do trabalho para os projetos. Lembre-se que agora você trabalha com uma equipe auto-gerenciável.

É isso...

Paintball Ágil?

Ontem fomos nos aventurar num paintball... estávamos em 12 pessoas. Foi uma experiência muito marcante para mim (literalmente - alguns hematomas no braço podem confirmar)...
Mas o que achei interessante da brincadeira foi o extremo cansaço que todos sairam do jogo. Até mesmo os mais atléticos que eu (o que é muito simples de ser) estavam exaustos, mais todos ainda aguentamos duas horas de conversas à respeito de nossa aventura...

Como isso pode ser Ágil?
Paintball indor é um exemplo bastante rico de como deveriamos levar nossos projetos. Existe uma proteção que impede que pessoas fora do jogo sejam atingidas, ou que quem está dentro do jogo ser atrapalhado. Além disso, existe uma pessoa responsável por manter a ordem e garantir que regras do jogo não sejam quebradas... (como um scrum master?)
O jogo consiste em ciclos curtos em que o time inteiro tenta marcar os adversários, manchando-os de tinta... Quando todos são marcados o ciclo termina para ser reiniciado... é nesse momento que o time discute suas melhores táticas para vencer a próxima partida... não há tempo para grandes discussões, é necessário ser o mais pragmático possível para se obter o melhor resultado dessa pequena reunião. Depois de alguns ciclos (ou games), as equipes estão mais atentas, com tiros mais certeiros e melhores resultados...
Depois de um ciclo intenso de uma hora, mesmo exaustos, é o momento de descontrair e relatar os fatos que ocorreram na partida, para que no próximo evento todos estejam melhores e mais dispostos...


Seria a comparação um tanto equivocada?? Talvez nem tanto... talvez sejam os hematomas (e dois headshots que levei)
Adorei o esporte! Quem sabe mês que vem tire (e atire) para conclusões...

Net Fone - O mais barato

Telefone da Net consegue ser o mais barato em são paulo! Alguém sabe se o serviço é de qualidade?
Aki na ilha da magia as coisas não são das melhores, ainda nao vi nenhuma pessoa que estivesse satisfeita com o serviço da net...

Veja o estudo abaixo
Fonte: InfoMoney
Perfis
Para elaboração do estudo, o Idec escolheu três perfis de gasto:

• 200 minutos mensais para fixo + 100 minutos mensais para celular;
• 250 minutos mensais para fixo + 50 minutos mensais para celular;
• 400 minutos mensais para fixo + 300 minutos mensais para celular.

Quanto fica
Na tabela abaixo é possível verificar os preços dos serviços prestados em São Paulo pela Telefônica, Net e Skype. O tempo de ligação para celular foi estimado pela entidade em dois minutos:

Perfil 1
Empresa	Gasto com fixo	Gasto com celular	Total
Telefônica	R$ 38,80	R$ 69,14	R$ 107,94
Net Fone	R$ 20	R$ 65	R$ 85
Skype*	R$ 26,40	R$ 65,70	R$ 108,99
Perfil 2
Empresa	Gasto com fixo	Gasto com celular	Total
Telefônica	R$ 43,58	R$ 34,57	R$ 78,15
Net Fone	R$ 25	R$ 32,50	R$ 57,50
Skype*	R$ 33	R$ 32,85	R$ 82,74
Perfil 3
Empresa	Gasto com fixo	Gasto com celular	Total
Telefônica	R$ 57,91	R$ 207,42	R$ 265,33
Net Fone	R$ 40	R$ 195	R$ 235
Skype*	R$ 52,80	R$ 197,10	R$ 266,79

Acertando do início!

Saudações!
Desculpem a demora... estou preparando uma apresentação para a semana acadêmica do senac-RS e ando meio ocupado para escrever... mas vamos lah!

Texto muito bom de Jean MacAuliffe da NetObjectives (sempre ouço o podcast deles...), que trata sobre qualidade de software baseada nos princípios do Lean Thinking e Desenvolvimento Ágil, e a imensa diferença entre nossa abordagem e a abordagem tradicional.

Resumão:

Test-Driven Development unido a Pair Programming, Code review e Shared code Responsablities são as principais práticas para que se possa criar um ambiente onde a qualidade é o principal do desenvolvimento do produto.
O princípio Build quality in do Lean Manufacturing pode ser realmente aplicado num ambiente de desenvolvimento de software...
Pense nisso...

Pessoalmente acredito que outras práticas não tão relacionadas a desenvolvimento podem ser muito importantes para este estado de qualidade total... inclusive já escrevi sobre elas aqui.


Arquivo: Get it Right from the Start

=)