Agile Environment /ou: Let's have some fun...

Alguns times trabalham...

Outros times, tão se divertindo...

Jim Webber na Abril Digital /ou: No caminho certo...

Ontem assistimos a apresentação (short version) do Jim Webber sobre REST aqui na Abril. Apesar de já ter lido o PDF umas mil vezes, ainda assim foi muito legal rever alguns conceitos e aprender outros novos (como usar OpenID e OAuth, por exemplo).

Depois passamos um tempo conversando sobre o que estamos fazendo aqui (System of Systems, REST, Arquitetura Emergente, Restfulie, Scrum em Escala, etc). O resultado da conversa foi muito bacana. Vou tentar postar mais sobre esses assuntos. O mais legal é a confirmação que estamos indo no caminho certo. Cool!

A estrutura empresarial e a qualidade de software /ou: Galera não tá se falando direito...

Esta cada vez mais claro que o desenvolvimento de software é mais do que uma atividade entre pessoas e computadores: é uma atividade social antes de tudo. É social pois depende de comunicação para acontecer.

Dentro de uma empresa a comunicação entre as pessoas passa por hierarquias, processos, etc. que quanto mais complexos, maior serão os ruídos. Ou seja, a qualidade da entrega é extremamente afetada pela estrutura organizacional (Mythical Man Month). Não só a qualidade é afetada mas também a própria entrega toma forma dessa estrutura (Conway's law). Lembra do Waterfall, RUP, XP-SCRUM, etc.? No fundo todos esses processos tentam atacar o problema de comunicação entre os membros de um projeto, seja usando os fantasmagóricos documentos de levantamento, os enigmáticos diagramas UMLs, continuos integration, daily team meetings e afins.

Mas se a qualidade de um software é influenciada pela organização (e como ela gerencia a comunicação), como medir ou prever essa qualidade? Qual métrica organizacional usar para saber se um software vai ser bem construído? Mas e as outras métricas de software (quantidade de linhas de código, cobertura de teste, complexidade ciclomática)? Elas são boas? Afinal, se a organização influencia tanto assim na qualidade da entrega, essas métricas não fazem muito sentido, certo?

Na tentativa de responder a essas perguntas, o ótimo paper "The Influence of Organizational Structure On Software Quality: An Empirical Case Study" estudou as métricas de software e as organizacionais do desenvolvimento do Windows Vista. Eles analisaram dados do controle de versão (libs, quantidade de updates, etc.), adicionaram dados dos funcionários (hierarquias, quantidade de pessoas no time, tempo de empresa, promoções, etc.) e dados de bugs do Vista depois da entrega. Analisando tudo isso (aprox. 50 milhões de linha de código, milhares de pessoas e muitos bugs!), foi possível mostrar que as métricas organizacionais são mais eficientes que as métricas de software (84% contra 79%, no melhor caso) em prever a qualidade do software entregue.

Lembrando que essa é a primeira pesquisa nesse sentido e talvez os números só se apliquem nesse cenário, mas ainda assim reforça (agora com números) o que antes só se tinha a impressão.

Isso que dizer que na próxima vez que você for fazer um check-in no seu source control, pode aparecer uma janela te perguntando qual seu cargo, quem é seu chefe e quantas pessoas tem na sua equipe e, depois do "ok", a IDE vai te mostrar as partes do código que tem uma grande chance de dar erro. Não porque tem muitos IFs ou o teste não passou por ali, mas porque a "galera não tá se falando direito".

Windows 7 /ou: Resolvendo o problema do botão de desligar

Dentro do possível, parece que os métodos ágeis influenciaram o processo de desenvolvimento do Windows 7:

In Windows 7, senior management has been extremely supportive of the various development teams that have had to make the hard decisions to scale back features that were not going to be able to make the quality bar associated with a Windows release – and there absolutely are major features that have gone all the way through planning only to discover that there was too much work associated with the feature to complete it in the time available. In Vista it would have been much harder to convince senior management to abandon features. In Win7 senior management has stood behind the feature teams when they’ve had to make the tough decisions. One of the messages that management has consistently driven home to the teams is "cutting is shipping", and they’re right. If a feature isn’t coming together, it’s usually far better to decide NOT to deliver a particular feature then to have that feature jeopardize the ability to ship the whole system. In a typical Windows release there are thousands of features and it would be a real shame if one or two of those features ended up delaying the entire system because they really weren’t ready.

The process of building 7 has also been dramatically more transparent – even sitting at the bottom of the stack, I feel that I’ve got a good idea about how decisions are being made. And that increased transparency in turn means that as an individual contributor I’m able to make better decisions about scheduling. This transparency is actually a direct fallout of management’s decision to let the various feature teams make their own decisions – by letting the feature teams deeper inside the planning process, the teams naturally make better decisions.

Problemas com o botão de desligar, nunca mais!

Métodos Ágeis - Mais Mitos /ou: Doce utopia?

Estava lendo Some value statements beyond Agile Manifesto. O post traz algumas declarações dos métodos ágeis com um rápido aprofundamento.

Vou reproduzir cada declaração (ver definição no próprio post) e colocar meu ponto de vista sobre o assunto. No final, coloco minha opinião sobre o movimento.

Self Organizing Team over Control & Command Team.
A metodologia ágil, como movimento que nega os movimentos anteriores, tem a tendência de querer quebrar antigos valores. O que é historicamente normal.

Infelizmente, querer ter uma equipe descentralizada, sem "chefe" tem algumas falhas.

Primeiro que aquele "chefe" que tem a palavra final, que não é aberto a idéias dos subordinados, não ouve e só manda, não existe mais. Se seu chefe é aquele que te atrapalha ao invés de viabilizar seu trabalho, mude de emprego.

Depois, dificilmente uma equipe descentralizada vai ser aceita dentro da organização. Simplesmente porque o chefe do chefe quer ouvir uma só pessoa e essa pessoa é o canal de comunicação e decisão. Ou seja, um responsável ainda é necessário. Alguém tem que falar "sim" ou "não" e ser responsável por isso.

No extremo, acho que equipes descentralizadas devem funcionar em poucas empresas, provavelmente pequenas, mas não vai funcionar na maioria.

Cuidado. Utopia faz parte dos movimentos revolucionários. Todos tem um pouco dessa doce ingenuidade. Mas não arrisque seu emprego por eles.

Agile done over just done.
É isso. Feature pronta é feature pronta. Crie sua definição do que é "feature pronta" e seja feliz. Do post do Michael Nygard, criei meu checklist:

1. All unit tests are green.
2. The code is as simple as it can be.
3. It communicates clearly.
4. It compiles in the automated build from a clean checkout.
5. The customer has accepted the feature.

Enough Design over big up-front design.
Finalmente, como movimento que nega o movimento anterior, a metodologia ágil acerta aqui. Com seus curtos ciclos de desenvolvimento e ferramentas para garantir a qualidade nesses ciclos(Continuous Integration, xUnit, etc.), é possível ter pequenas alterações em produção em tempos nunca imaginados nos tempos do modelo em cascata ou mesmo nos mais recentes, como no RUP.

Mas aqui cuidado novamente. Alguns mais radicais irão dizer que qualquer tipo de especificação documentada, seja do cliente ou de um arquiteto, nem que seja um Use Case, já é BDUF (Big Up-Front Design). Como radicalismo esta longe da minha pessoa, eu acredito no seguinte: se seu código sozinho não conseguir expressar a sua funcionalidade de modo intuitivo, não tenha vergonha em produzir documentos ou diagramas. O importante é a "comunicação" da intenção do código.

Code Reuse over cut and paste.
Eu gosto da idéia de reutilização e tento sempre que possível não duplicar código. Mas para quem já tem alguns anos de estrada, sabe que nem sempre isso é possivel. Tentar levar essa regra ao limite pode quebrar sua aplicação.

Pair programming over code review
Esse é um ponto complicado. Eu, hoje, acho que o code review seja suficiente. Dependendo do contexto (código com baixa complexidade, por exemplo), acho que duas pessoas no mesmo computador seja um desperdício. Mas estou aberto a tentar um dia e descobrir que estava errado.

Stand up Meetings over status meetings
Concordo com o princípio. Porém acho que deva ocorrer usando ou não metodologia ágil.

Tenha membros seniors
Tem uma declaração implícita que é pouco "divulgada": Tenha membros seniors.
Como você pode ter equipe descentralizada, membros negociando e tomando decisões diretamente com os clientes, codificação descentralizada, refatoração a qualquer momento do desenvolvimento, etc., sem que todos eles sejam ótimos programadores-arquitetos? Qualquer outro tipo de programador iria ficar mais perdido que peixe fora d'agua.

Minha opinião sobre tudo isso é: Métodos Ágeis trás a luz verdadeiras preciosidades, princípios que condiz com a natureza do software. Mas também trás outros princípios que não se encaixa a todos ou são simplesmente utópicos.

No caso de não se encaixar, adapte-se. Não é necessário levar ao pé da letra o que lemos nos livros. Use sua inteligência, experiência e intuição e pegue o que for necessário para você. Continuous Integration, não foi criada no XP e já trazia resultados. Test Case não foi criado no XP e já trazia resultados. Ou seja, partes isoladas podem trazer resultados sem ter que aplicar tudo "by the book".

Mitos sobre os Métodos Ágeis - Continuous Integration /ou: Quem realmente integra?

Para quem não conhece, Continuous Integration (CI) é o processo automático de compilar e testar (usando os seus unit tests) seu software, este vindo do seu source control. O resultado, um monte de bolinhas vermelha e verde, é divulgado para a equipe de desenv para que eles possam identificar onde o código de um programador está dando pau na chamada no método do outro, por exemplo. Assim, os problemas de integração entre os componentes do sistema são identificados o mais rápido possível. Teoricamente...

CI é uma ferramenta extremamente útil e vale cada segundo gasto para por em prática e dizer que a CI não cumpre seu papel de identificar problemas na integração entre os programadores é injustiça. Mas o problema é que é preciso ir além da identificação de um bug e identificar onde esta realmente o problema. Começando na linha de código e terminando na arquitetura. E isso não é papel do programador. Não deixe que os programadores discutam o porquê as classes não se falam e como elas deveriam conversar. Não é o papel deles. Se os componentes não se comunicam, é porque o arquiteto não falou (documentou, escreveu, expressou, etc.) a intenção de forma correta, logo o problema pode ser maior do que um simples vermelhinho no report da CI.

Existem outras coisas que podem não colaborar com que a CI cumpra seu papel, apesar de não serem mitos propriamente. Primeiro, tem sempre o cara que não sobe as alterações dele para o source control e deixa para fazê-lo nos 45 do segundo tempo. A pratica de subir código (check-in) deve ser diária. Mas ai sempre vem a pergunta: “Mas e se eu não tiver terminado?” Terminado o que? Uma classe ou um método? Geralmente um método dá pra terminar no prazo de um dia, seja qual for o tamanho do método, e é isso que me interessa. O relatório enviado pelo servidor de CI não precisa mostrar tudo verde e sim ir mostrando verdes conforme a evolução do sistema, ou seja, deixar tudo para ultima hora não bem uma integração "continua".

Um outro problema chato, que chegamos a enfrentar, é que nosso ambiente era “quase” padronizado. Todos tinham a mesma estrutura de diretórios para os projetos, mas cada programador colocava essa estrutura em um drive ou diretório da sua escolha. Infelizmente, as ferramentas que usamos (VS2005, LLBLGen, etc.) sempre guardam algum tipo de caminho fixo. Ao subir esses arquivos para o source control, o servidor de CI (no nosso caso o CruiseControl.NET) pode não encontrar o caminho dos arquivos a serem compilados. Dica: padronize TOTALMENTE seu ambiente o mais rápido possível se você quiser usar CI.

Métodos Ágeis - A parte cômica /ou: Mais ágeis...

Mitos sobre os Métodos Ágeis - Unit Test /ou: Test Hype!

Um dos mitos que eu mais leio e ouço por ai é que os testes unitários (unit test) vão eliminar os bugs da sua aplicação. Gostaria de dizer o contrário, mas infelizmente não vão. Veremos...

O primeiro problema é que nem todo código da sua aplicação pode ser testado. Hoje é muito fácil testar componentes, mas muito difícil testar as outras partes do software como, por exemplo, a UI. E como esse código "marginal" não vai ser testado automaticamente, as alterações lá não vão ganhar os benefícios dos métodos ágeis (refactoring, continuous integration, etc.).

A segunda pedra no caminho para detectar bugs via teste unitário é na minha opinião a pior. É a dificuldade de escrever testes. Um exemplo que vou dar é um dos muitos que está nos fazendo quebrar a cabeça aqui. Existe um requisito no sistema que diz que a segunda compra do mesmo produto pelo cliente em menos de um mês deve ter um tratamento diferenciado.

Simular a primeira compra é simples. Mas simular a segunda, como se fosse daqui a 15 dias, nem tanto. Alteramos a data do computador? Ok, mas e a data do DB de teste? Mas e se o DB está numa maquina que você não tem permissão para mudar a hora? Ou seja, se não conseguir simular esse comportamento não estou testando os possíveis bugs que podem acontecer, logo a porcentagem de código testada cai.

Outro exemplo da dificuldade de escrever teste é "o que" verificar nos testes. Quando um requisito diz que tenho que incluir um registro, o que devo verificar? Se um registro a mais foi incluído na tabela? Se os dados incluídos estão corretos? Mas e os valores "default" criados pelo DB? Devo verificá-los? Então imagine agora uma rotina que sensibiliza 7 tabelas. Conseguiu visualizar o tamanho do problema?

Com esse exemplo já dá pra ver que apenas uma pequena porção do seu código vai ser testada via teste unitário e, sendo assim, sinto dizer, mas seu software vai ter bugs!

Como resolver esse problema da maneira "Ágil"? Aqui vai minha dica para contornar o problema: Já que não temos como criar testes para todos os cenários possíveis (mesmo nos esforçando para isso), é importante responder rápido aos bugs quando eles aparecem. Por isso é importante ter (1) um otimo sistema de logs e (2) um bom bugtracker. Assim, as exceptions geradas pelos sistemas são enviadas por e-mail, via sistema de log e colocadas no bugtracker. Problemas conceituais são também reportados pelos clientes via e-mail e também colocados no bugtracker. Depois, é só priorizar e delegar os problemas no bugtracker. Em um ritmo normal de trabalho, os bugs têm prioridade. Com esse ciclo, conseguimos alcançar o que os métodos ágeis pregam: gerar softwares cada vez mais robustos, que atendem o requisito do cliente, em curtos ciclos de entrega.

Se o tempo ajudar, vamos ver se consigo escrever outros mitos dos métodos ágeis. Porque, como todo hype, tem coisas muito boas, mas tem sempre algo que eles não querem que você saiba.

Métodos Ágeis /ou: Pode me responder 4 perguntinhas?

Você é Ágil?

- Use "Unit Test"

- Mantenha contato e interaja, pelo menos uma vez por semana, com as partes envolvidas (stakeholder) no software sendo produzido

- Produza software "rodando" o mais rápido possível

- Mantenha a equipe informada sobre o que está acontecendo e deixe a equipe concertar o que está errado

Se você não pratica pelo menos os 4 itens acima, desculpa ai, mas você não é ágil. Pelo menos é o que diz Scott Ambler da IBM.