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... =)