Débito Técnico

Na minha coluna MundoOO da revista MundoJava, publiquei um artigo que dismistifica muito sobre User Stories e responde a algumas perguntas comuns sobre o assunto que observei no mercado em muitas equipes: Como escrever? Quem faz o que? Pra que usar cartões? Aonde está a especificação? e etc…

Essas dúvidas geralmente surgem no nosso Workshop Scrum, onde temos uma atividade prática muito legal sobre captura de User Stories dentro de uma concepção ágil (veja cases do blog).

Este artigo é parte de uma série sobre Agilidade que estou mantendo na coluna. Ultimamente escreví sobre modelagem ágil, TDD, requisitos/especificações executáveis e etc…

Segue o trechinho grátis:

É fato que a maior parte do mercado brasileiro hoje usa contratos de escopo fechado, principalmente nos grandes projetos (governo, bancos, Telecom, indústrias e etc…). O contrato de escopo fechado promete “previsibilidade” no desenvolvimento de software, porém, esta forma de contratação parte de duas premissas muito duvidosas: 1 – o cliente sabe exatamente o que quer; e 2 – a equipe sabe estimar exatamente o esforço de construção.

Se você já trabalhou em dois ou três projetos de software você sabe perfeitamente que essas premissas são folclore. Nem o cliente sabe exatamente o que quer e nós sempre temos um grau de confiança inaceitável nas nossas estimativas de longo prazo. Essa é a maior razão para o seu gerente colocar 50%, 100% e até 150% de “gordura” ou “pulmão” no valor da proposta para o cliente. E esse é o resultado: tentar forçar a “previsibilidade” num contrato de escopo fechado gera projetos mais caros e clientes muito insatisfeitos. Na maioria das vezes isso acontece porque o cliente se envolve timidamente no projeto, tomam suas especificações funcionais como verdade absoluta e dizem: “- Eu quero tudo!!!”, não se importando se a solução vai resolver os problemas ou não.

Na verdade, um projeto de software tem uma peculiar característica de “constante investigação”. Ken Schwaber chama isso de “inspeção e adaptação”. Em termos mais práticos, o dia-a-dia de uma equipe de desenvolvimento de software é “checar se estamos no caminho certo e ajustar o rumo sempre que necessário”. Desenvolvimento de software é um processo criativo de pesquisa, então, especificações pactuais gordas que apodrecem no nosso controle de versão nos ajudam muito pouco para o sucesso do projeto. Em projetos de software bem sucedidos é comum o produto final ser bem diferente da idéia concebida inicialmente. Durante o desenvolvimento do projeto, uma sugestão de solução nos leva a novos problemas ocultos que não podem ser ignorados e a outras possibilidades de solução ou “atalhos” que devemos aproveitar. Dentro do desenvolvimento iterativo esses problemas e atalhos se tornam muito claros.

Quer ler mais? Já nas bancas…

Tive uma dúvida nos últimos tempos.

Fiquei bem surpreso como nos dois últimos eventos de Java falamos muito sobre Ruby e Rails (TDC e JustJava). Digo isso não nas palestras, mas sim nos bate-papos. Eu confesso! Nos últimos eventos gostei mais das conversas nos intervalos do que das palestras.

A minha dúvida era: “Se num evento de Java se fala muito sobre Ruby, o que se fala num evento de Ruby?”. Para minha surpresa, o que se fala muito num evento de Ruby é BUSINESS. Isso mesmo! O Rails Summit da Locaweb teve muito bate papo sobre negócios e como ganhar dinheiro com software. O que mais me chamou a atenção foi uma “certa aversão” ao termo Agile nas conversas dentro e fora das palestras. O Guilherme Chapiewski ficou meio revoltado quando eu disse que logo vão exigir “Scrum Masters Certificados” nas licitações (sim… eu ouví esse papo nas minhas andanças no Planalto Central). O Shoes foi categórico: “Não falo sobre Agile”. Já com o Vinicius Teles, batemos muito papo sobre negócios, produtos, não trocamos uma palavra sequer sobre Agile. Também estavam presentes muitos outros agilistas, railers, gujeiros, alunos da Aspercom e etc…

Leia o restante deste artigo »

É incrível como o mercado é dado a modismos. Atualmente quando falamos sobre Agilidade um monte de besteirinhas acompanham o termo. Várias vezes ví em fóruns de discussão: “estamos adotando o Scrum, mas ainda não temos o quadro de tarefas”, “ainda não conseguimos ter as histórias em cards”, “ainda não temos as cartas do Planning Poker”, “ainda não traçamos o gráfico de burndown”, “ainda não temos o quadro branco para fazer os modelos”, “ainda não estamos estimando em pontos”, ” e etc, etc, etc… às vezes ouvimos “não usamos mais casos de uso, só usamos histórias”, “não documentamos mais a arquitetura”, “banimos o RUP”, “não documentamos mais a visão”, “não usamos mais UML”, “não temos mais documentos Word, só usamos Wiki”, “não somos mais CMMI” e etc, etc, etc…

Infelizmente vejo que tem se criado um “Termômetro Agile” bem estúpido. É um AMM (Agile Maturity Model) que mede o quão Agile você é baseado na quantidade de práticas da moda que você aplica. É mais ou menos assim:

Práticas AMM	Pontos
	Sim	Não
Você tem o quadro de tarefas da iteração?	+10	-10
Você tem as histórias em Index Cards?	+10	-10
Você está usando mais de 135 post-its por mês?	+10	-10
Você tem o quadro branco com modelos?	+10	-10
O quadro branco tem modelos UML?	-5	+5
Você mantém modelos UML como artefatos?	-15	+15
Você tem as cartas do planning poker?	+5	-5
Sua reunião diária dura exatamente 15 minutos?	+5	-5
Você usa algumas práticas do RUP?	-10	+10
Sua documentação está num Wiki?	+5	-5
Você se preocupa com rastreabilidade?	-15	+15
Está usando uma ferramenta para gerenciar o projeto?	-10	+10
Sua iteração tem mais que 2 semanas?	-10	+10
Seu Gráfico Burndown está em pontos?	+5	-5
Você pode ir trabalhar de camiseta?	+15	-15
Você usa Gantt Chart?	-100	+100
Você é CMMI?	-100	+100
Você tem PMPs na equipe?	-50	+50
Você tem CSMs na equipe?	+50	-50
Você está fazendo em Rails?	+25	-25
Você já assistiu uma palestra com o Juan Bernabó?	+20	-20
Sua equipe assiste aos videos da ImproveIT?	+20	-20
Você lê o blog do Guilherme Chapiewski sobre a Globo.com?	+20	-20
Você fez o curso com o Alexandre Magno na Caelum?	+20	-20
Você lê os artigos do Rodrigo Yoshima?	+20	-20

(Juan, Vinicius, Guilherme e Magno… isso é só piadinha, OK? - espero que não tenha retaliação )

Nível	Pontos
1 - Cascateiro	até 50
2 - Discretamente ágil	51-100
3 - Ágil	100-300
4 - Bem Ágil	301-500
5 - ThoughtWorks / Google	acima de 500

Quadro referência

O objetivo aqui é exatamente falar contra isso, ou chamar a atenção para esses modismos. Usar Kanban, Index Cards, Cartas do Planning Poker, Pontos e Quadro Branco não é o que vai tornar você ágil. Dependendo do contexto é capaz que seja melhor você esquecer essas coisinhas da moda. Elas podem até te atrapalhar. Aplique desenvolvimento iterativo, trabalho em equipe, foco em resultados…

Vou dar um exemplo. Uma das coisas que me atrapalham é perder a ordem das histórias. Quando você está trabalhando iterativamente, seguindo uma ordem definida por um Product Owner, essa ordem deve ser mantida. Quem fez treinamento comigo ou trabalhou comigo em projetos sabe que sou chato para manter a ordem da fila de construção. Nesse novo projetinho Rails que estou desenvolvendo sozinho, resolví isso furando os cartões, colocando uma correntinha para manter a ordem e um durex verde para indicar a primeira história da fila:

Sim! Isso está ajudando no meu projeto. E poderíamos até evoluir a idéia: a correntinha poderia ter um cadeado que só o Product Owner tem a chave, pois só ele pode tirar, colocar ou mudar a ordem dos Index Cards. Seria mais uma prática da moda!!!!

Práticas AMM	Pontos
	Sim	Não
Você tem uma corrente amarrando os Index Cards do Backlog?	+10	-10

AMM v1.1

Francamente!!!!!

Iniciando a série perguntas e respostas, dúvida na lista scrum-brasil:

2008/7/29 Alguém wrote:
Olá pessoal,

Gostaria de tirar algumas dúvidas:

Imaginem que existe um sprint definido e iniciado, que possui 10 tarefas. Depois de passados alguns dias, o Product Owner quer trocar um item do Sprint por outro de mesmo peso, que ainda não foi iniciado. Isso poderia ser feito? Ou em Sprint iniciado não se mexe?

Essa é uma pergunta muito comum nos cursos que ministro. Na maioria das vezes não é simplesmente trocar um pelo outro. Muitas vezes o planning é um momento onde aprofundamos em requisitos, fazemos alguns modelos rascunhando, levantamos tarefas, preparamos o que for necessário e isso sempre é sobre as Stories que selecionamos para o Sprint.

Durante o Sprint é o único momento onde o escopo está fixo (escopo do Sprint). Isso faz parte do contrato Scrum. Isso garante o mínimo de segurança para a equipe trabalhar num terreno um pouco mais firme mesmo que por um curto prazo. Sou partidário do “sprint iniciado não se mexe”. Já tive cliente que o Product Owner queria toda hora mudar o Sprint Backlog. Isso gerava um estresse grande na equipe. A equipe não sabia o dia de amanhã. É muito ruim.

Um artifício que o Product Owner pode usar é cancelar o Sprint, mas isso significa parar o Sprint atual e voltar para o Planning. Não é uma coisa muito comum e nem muito agradável. O Product Owner tem que se organizar!

Segunda pergunta: se o Product Owner quiser tocar um item do sprint que ainda não foi iniciado, por outro de peso maior, o que consequentemente iria aumentar o tamanho do sprint, isso poderia ser feito? Estou considerando que o Product Owner tem consciência que essa alteração irá aumentar o tamanho do sprint e ele não se importa se o sprint tiver 1 semana a mais, se for necessário.

Antes de mais nada, leia isso aqui:

http://gc.blog.br/2008/05/05/nao-da-pra-fazer-so-mais-uma-coisinha/

O Product Owner está no comando do barco num processo Scrum. Ele está guiando o desenvolvimento. Ele tem muito controle sobre a equipe, mas esse controle é ordenado e as regras do contrato Scrum devem prevalecer sempre. O ScrumMaster não pode deixar o Product Owner fazer o que quiser.

Já disse que não é uma boa idéia mexer no escopo do Sprint corrente. E para todos os efeitos, vocês da scrum-brasil vão ficar de castigo. Escrevam 100 vezes na lousa:

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

ITERAÇÃO É TAMANHO FIXO!

O timebox é um conceito sagrado. Iterações tem tamanho fixo e todas são do mesmo tamanho. Costumo dizer para as equipes: “- Este Sprint termina na data 01/04/20XX. Quer vocês queiram, quer vocês não queiram, ele vai terminar nessa data.”

Essa regra não é uma rigidez conceitual qualquer. É só para deixar as coisas mais simples. Desenvolvimento iterativo possui um conjunto mínimo de regras que faz o processo funcionar. Abrir mão de algumas delas gera muita confusão.

Este texto foi publicado no blog do Carlos Vilella, achei tão bom que decidi traduzir.

Uma fábrica de pastas de dente tinha um problema: as vezes eles entregavam caixas vazias, sem o tubo dentro. Isso ocorria por causa da maneira que a linha de produção foi montada, e pessoas com experiência em design de linhas de produção podem confirmar como é difícil ter tudo ocorrendo no tempo certo para que cada unidade fabricada seja 100% perfeita. Pequenas variações no ambiente (que por conta do custo não podem ser controladas) obrigam que você tenha alguns pontos de checagem da qualidade inteligentemente distribuídos ao longo da linha de produção, para que os consumidores que vão até o supermercado não fiquem fulos com seu produto e comprem do concorrente.

Compreendendo que isso era importante o CEO da fábrica de pasta de dente pegou as pessoas mais importantes da companhia e eles decidiram iniciar um novo projeto. Eles contratariam uma empresa de engenharia externa para solucionar o problema “das caixas vazias”, já que o departamento de engenharia já estava abarrotado de trabalho.

O projeto iniciou como sempre: orçamento, financiamento, propostas, fornecedores selecionados e depois de 6 meses (e $8 milhões) eles tiveram uma solução fantástica - dentro do prazo, do orçamento, alta qualidade e todo mundo no projeto estava feliz. Eles resolveram o problema usando algumas balanças de alta precisão que soava uma sirene com luzes toda vez que uma caixa de pasta de dente pesasse menos do que deveria. A linha de produção pararia e alguém teria que andar até lá, retirar a caixa com defeito e pressionar um botão para a produção continuar.

(neste momento, pense com seus botões se esta solução é plausível - grifo meu)

Momentos depois o CEO decide ver o ROI do projeto: resultados incríveis! Nenhuma outra caixa vazia saiu da fábrica depois que as balanças foram colocadas. As reclamações reduziram e eles estavam ganhando mercado. “Isso sim é um dinheiro bem gasto!” - ele falou, isso antes de olhar mais de perto outras estatísticas do relatório.

(mais uma vez, neste momento avalie o resultado do projeto - é uma solução de sucesso? - grifo meu)

Ao virar a página ele vê que o número de defeitos capturados pelas balanças foi ZERO depois de 3 semanas de uso. Poxa! Elas deveriam estar capturando pelo menos uma dúzia por dia, então, deve ter algum problema com o relatório. Ele apontou um bug nesta funcionalidade. Depois de alguma análise os engenheiros voltaram dizendo que o relatório estava correto. As balanças de fato não estavam mais captando nenhuma caixa vazia. Todas as caixas que estavam chegando no ponto onde as balanças estavam na esteira tinham o tubo dentro.

Confuso o CEO vai até a fábrica e chega até o lugar aonde as balanças de precisão foram instaladas. Alguns passos antes das balanças tinha um ventilador de $20 assoprando pra fora da linha as caixas vazias para dentro de uma lixeira.

“Ah… esse ventilador? Um dos nossos colocou ele aí, pois estava com o saco cheio de andar até aqui quando a sirene tocava” - disse um dos trabalhadores.

Nesta semana eu e o Phillip Calçado compartilhamos uma coisa: nós lemos artigos numa revista fora do mundo de tecnologia (se é que existe isso hoje em dia) e achamos conceitos ágeis lá. Veja este post no blog gringo dele:

BigPharma Problems & Solutions: Have You Seen This Before?

Na edição brasileira da Harvard Business Review de junho/2008, Tim Brown escreveu um artigo apresentando o “Design Thinking”. Ao ler o artigo ví que Design Thinking é recheado de conceitos ágeis. Muito recheado! É praticamente uma abordagem ágil para a inovação em todas as esferas empresariais.

A abordagem de [Thomas] Edison é um dos primeiros exemplos do que hoje se chama design thinking - metodologia que imbui todo o espectro de atividades de inovação de um etos de concepção centrado no homem… Edison não era um cientista especializado num campo apenas - era, antes, um generalista com aguçado tino comercial. Em seu laboratório em Menlo Park, New Jersey, Edison se cercava de gente com talento para improviso e experimentação. Na prática, derrubou o mito do “inventor genial e solitário” ao criar uma abordagem de equipe à inovação.

Preste atenção nesta parte:

A idéia era justamente não corroborar hipóteses preconcebidas - mas ajudar o investigador a aprender algo a cada lance iterativo.

(grifo meu)

É interessante ver como pragmatismos estão florescendo dentro no mundo empresarial das pessoas espertas e como mais e mais rigidez e controle estão obscurecendo a vida das empresas burras. Design Thinking é uma perspectiva humana para a solução dos problemas. É o envolvimento de cada indivíduo, de cada mente, na busca de uma solução viável e criativa. Isso envolve empatia, raciocínio integrativo, otimismo, experimentação e colaboração. O Design Thinking é a dinâmica de um processo colaborativo de inovação. Relatando um caso de solução para um problema de um grupo de enfermagem da Kaiser (não é a fábrica de cervejas), Tim Brown acrescenta o que colaborou para a solução:

…as equipes de inovação exploraram soluções potenciais por meio de brainstorming e prototipagem rápida… Um teste com protótipos não precisa ser complexo e nem caro. Um protótipo deve consumir apenas a quantidade de tempo, esforço e investimento necessária à geração de um feedback útil a evolução da idéia - nada mais. Quanto mais “acabado” parecer um protótipo, menor a probabilidade de que seus criadores ouçam o feedback - e se valham dele.

Olha que engraçado! A HBR, uma revista tradicionalíssima, está dizendo que meus protótipos visuais estão certos! Quando aquele gerentinho metido torcer o nariz poderei falar: “- Você leu o artigo sobre Design Thinking na Harvard Business Review?”

…o que ocorreu na equipe de enfermagem da Kaiser não foi um avanço súbito e revolucionário, nem o estalo de um gênio - foi fruto do trabalho árduo realçado por um processo criativo de descoberta centrado no ser humano, seguido de ciclos iterativos de testes com protótipos e aperfeiçoamento.

Esta é a parte que mais gostei (comentários meus entre parênteses):

O melhor jeito de descrever o processo de design é metaforicamente (Beck?) - como um sistema de espaços, em vez de uma série predefinida de passos ordenados (Gantt?). Esses espaços delimitam tipos distintos de atividades correlatas que, juntas, formam o continuum da inovação. O Design Thinking pode parecer caótico para um marinheiro de primeira viagem (seu chefe?). Mas, no decorrer de um projeto, os participantes acabam entendendo que o processo faz sentido e produz resultados (um release?), ainda que sua arquitetura seja distinta do processo linear fundado em marcos intermediários característico de outras atividades empresariais.

Este parágrafo no artigo é uma das melhores definições que já ví a respeito da natureza de um processo de design. Desenvolver software é 100% design. Isso foi tão contundente pra mim que contactei o Tim Brown - o autor do artigo - perguntando se ele tinha sido influenciado pelas práticas do Agile Software Development. Veja a resposta dele entre outras coisas:

From: Tim Brown
Date: 2008/7/2
Subject: Re: Article about Design Thinking on Harvard Business Review
To: Rodrigo Yoshima

Hi Rodrigo,
It doesn’t surprise me to hear that software design shares many of the same characteristics as design thinking. You are right that there has not been a lot of interaction between these two communities other than through the computer human interaction folks where I think a lot of these same issues have been discussed.

Thanks for making the link.

Best regards
Tim

On 6/30/08 5:53 PM, “Rodrigo Yoshima” wrote:

> Hi Tim,
> I’ve just read your article about Design Thinking and I’m
> just very very curious about how you put Design Thinking
> pratices together. Design Thinking concepts are very close
> to Agile Software Development Practices. Have you ever
> heard about it? Take a look at www.agilemanifesto.org.
>
> I see that the values of the Agile Manifesto is our flag of
> Design Thinking on Software Development. 100% of the
> software construction is design. Agile Practices are:
>
> - Human centered / Focused on Team Work
> - Iterative / Cyclical / Feed-back based
> - Use a lot of Prototypes / Sketches
> - Empirical
>
> I guess that you can really benefit from the contents
> that our community have being studying for the last 20 years.
>
> Cheers.
>
> Rodrigo Yoshima
> ASPERCOM / MundoJava

Sim! Mais uma vez provamos que o futuro do mundo empresarial é empírico e pragmático. Mais uma vez está provado que rigidez e processos inflexíveis impedem a inovação. Quem só tem martelo na mão só vê pregos pela frente… e sai martelando tudo.

Vocês sabem que as maiores reclamações do mundo em desenvolvimento de software é a famosa correria, os atrasos e a explosão de custos no final dos projetos. Geralmente para nós agilistas o final do projeto é a coisa mais tranquila do mundo. Nós corremos nas primeiras iterações e focamos em entregar valor. Nas últimas iterações é comum sobrar as funcionalidades mais inúteis do mundo a serem desenvolvidas. Quando o cliente percebe isso é comum o projeto acabar algumas iterações antes do que foi planejado.

As maiores razões para esse correria no final do projeto é:

1. A equipe não sabe desenvolver software
2. Gestão Covarde: começar a fazer o software pelas funcionalidades inúteis.
3. Escopo mal definido (assim como as métricas)

O problema com “escopo” em software é achar que desenvolvimento em cascata (waterfall) resolve a questão. Infelizmente quando falamos de escopo dentro de qualquer metodologia de desenvolvimento (FDD, Scrum, RUP como exemplo) sempre focamos que o objetivo do projeto é RESOLVER PROBLEMAS de negócio e não implementar requisitos (isso também é uma coisa que já falei umas 10 vezes aqui).

Parando de ser repetitivo, como nós documentamos esse escopo? Como nós declaramos que problemas o projeto está focado em resolver? Qual é o nível de profundidade desse escopo?

Estabelecer a Visão de um sistema é uma arte. Para este tipo de trabalho é necessário ter um grande conjunto de conhecimentos que na maioria das vezes não é natural para uma pessoa enfiada em linhas de código. Vou colocar uma pequena lista para vocês terem uma idéia. Para estabelecer uma visão é necessário:

- Desenvoltura no ambiente empresarial
- Focar-se no problema e não na solução
- Estabelecer fronteiras claras
- Saber gerenciamento de projetos (definir envolvidos, estabelecer responsabilidades, financiamento)
- Identificar usuários
- Documentar premissas e restrições
- Compreender sobre retorno e risco
- Saber escrever bem
- Ser político (conseguir concordância de todos os envolvidos)

Essas entre outras coisas formam o conjunto de habilidades necessárias para estabelecer uma boa visão. Uma visão que deixe o escopo deslizar dentro do processo iterativo mas que ao mesmo tempo dê um objetivo claro para o propósito do projeto.

Dentre essas habilidades, estabelecer fronteiras é uma das mais importantes. Quando você está desenvolvendo um grande sistema com muitos stakeholders em um ambiente corporativo é comum que a aplicação tenha suporte de outros sistemas ou processos manuais também fora do escopo da automação. Deixar claro que essas responsabilidades externas não são escopo também é um aspecto importantíssimo da visão. Responsabilidades do processo externo e integrações com outros sistemas sempre são importantes para o refinamento do escopo, assim como premissas e restrições na avaliação dessas interfaces.

Sem essa visão clara é comum que ocorram frustrações dentro de um projeto. Uma empresa tem muitos problemas e geralmente o que estamos desenvolvendo não solucionará TODOS os problemas. O escopo delimita exatamente quais problemas serão solucionados.

O RUP é um dos processos que mais valoriza o estabelecimento dessa visão. O OpenUP também nos fornece um bom material para estudo dessa importante tarefa.

No site da Aspercom nós também temos alguns exemplos:

Visão da HotMotors (Oficina de Tunning)
Visão da KrowCorp (Rede de Hotéis)
Visão da Clínica Anna Suiter (parte integrante do curso on-line grátis, é necessário se cadastrar no site)

Esses documentos tem algumas coisas que geralmente não existem em documentos reais. No caso da KrowCorp (Curso UML & UP) e da Clínica Anna Suiter (Curso Grátis “Entendendo Casos de Uso”) as necessidades dos usuários estão detalhadas demais (estão assim para os objetivos do curso). Já a visão da HotMotors está abrangente demais. O Documento de Visão documenta mais o problema do que a solução. Ele é um resumo executivo do projeto. É o documento que você leva para aquela reunião onde o Sponsor quer cancelar o projeto. A Visão prova a necessidade do software.

É importante ressaltar que dependendo do projeto a Visão pode ser menos ou mais abrangente. Isso depende do que você considera escopo. De qualquer forma nenhuma metodologia iterativa considera que os requisitos do software detalhados são o escopo. O escopo em software sempre é mais abrangente que “requisitos de software detalhados”. Existe diferença entre o problema, as necessidades dos usuários e os requisitos de software.

Dean Leffingwell e Don Widrig explicam mais sobre essa diferença no livro “Managing Software Requirements“.

Um dos problemas do “Escopo de Alto Nível” é que na maioria das vezes o medo do gerente covarde ou a gestão de projetos tradicional não aceita este tipo de escopo como válido. Para eles “tudo tem que estar explicadinho e assinado” por conta de escopo, prazo e custo serem fixos no processo Waterfall. Isso nos leva ao anti-pattern “Big Requirements Up Front” e a uma dispendiosa e irracional Gerência de Mudancas.

O escopo focado no problema é suficiente para o controle dos objetivos do projeto. Determinados replanejamentos de custo, prazo ou funcionalidades podem ocorrer durante a execução. Isto é previsto no processo iterativo. Porém, se o seu cliente desejar que novos problemas façam parte do escopo aí sim teremos impactos maiores de escopo e um replanejamento geral do projeto pode ser necessário (talvez uma nova concepção/iniciação do projeto ocorra gerando impacto em custo e prazo). Isso sim seria uma mudança de escopo e não a inclusão de um campo a mais numa tela.

Muitos desses assuntos são explorados no nosso curso de Levantamento e Especificação de Requisitos.

Motivado pelo post do Guilherme Chapiewski (cara, como é difícil decorar este sobrenome) decidí escrever sobre mais uma adoção de Agile, especificamente de Scrum.

Imagine uma empresa que desenvolve software. Imagine ela com uma equipe de mais de 200 desenvolvedores. Nessa empresa TODOS os funcionários são CLT, com benefícios e com horário de trabalho das 8:30 às 17:30. Imagine agora que além disso a tecnologia utilizada é de ponta. Não bastando, as equipes têm liberdade, a administração é colaborativa e realmente as pessoas são valorizadas. Os projetos estão sendo guiados pelos valores ágeis, utilizando Scrum e com a participação do cliente. Além disso, o escritório é bonito, confortável, cheio de Kanbans nas paredes e máquinas Italian Coffee sempre a disposição.

Não, eu não estou falando dessa vez de Google, Microsoft, ThoughtWorks e outras. Eu estou falando do Venturus aqui mesmo no Brasil. O Venturus é um Centro de Inovação Tecnológica que desenvolve software para os setores de Telecomunicação fixa e móvel, atendendo principalmente a Sony Ericsson. Nesse mês de maio tive o prazer de treinar 120 pessoas do Venturus com o nosso Workshop Scrum e confesso que foi uma das melhores empresas que ministrei até hoje.

Desenvolver aplicações web e desktop pode ser complicado, porém, desenvolver novas aplicações e protótipos para celulares pode ser mais emocionante ainda. O crescimento forte deste setor está gerando uma grande corrida por mais e mais aplicações que rodam numa infinidade de aparelhos e conversam com um mundo de acessórios variados. Este tipo de ambiente requer uma maior maturidade pois um bug em produção nesse tipo de desenvolvimento é caríssimo.

O Venturus é uma empresa que adotou Agilidade partindo dos clientes e dos próprios colaboradores numa iniciativa conjunta e com grande suporte do corpo executivo. É mais um case de adoção “Enterprise Scrum”. A iniciativa do desenvolvimento infectou até as rotinas administrativas (que também pude auxiliá-los). Atualmente eles estão trabalhando num ciclo de 2 semanas em equipes de tamanho variado. O Scrum está em adoção desde Novembro de 2007. Como ferramenta eles adotaram o ScrumWorks.

A história do Venturus não podia ser diferente do que o Guilherme falou no post dele. Antes da Agilidade o que existia eram Gantt Charts nunca cumpridos, maiores “controles” operacionais e um processo cascata tentando ser previsível. O simples fato de tornar o processo iterativo-incremental já mostrou resultados positivos nos primeiros Sprints. Com as outras práticas do Scrum de inspeção e adaptação boas rotinas de trabalho estão emergindo das equipes e o processo segue em melhoria contínua.

Minha visão sobre um treinamento Scrum…

O treinamento Scrum da Aspercom é um Workshop de 8 horas. Nós montamos um treinamento mais curto, mais prático, mais direcionado e principalmente mais barato exatamente para acontecer o que aconteceu no Venturus. Um treinamento para TODA a equipe. Dificilmente as empresas possuem verba para pagar um treinamento caro para 120 pessoas. Nossa visão sobre um treinamento Scrum eficiente é que toda a equipe deve ser treinada e não somente o ScrumMaster. Quem está querendo adotar o Scrum sabe que cada papel do Scrum tem responsabilidade com relação ao gerenciamento do Projeto. No Scrum, não existe gerente de projeto. ScrumMaster não é Gerente de Projeto.

Um padrão que considero maléfico para a adoção do Scrum é uma empresa pegar seus Gerentes de Projeto tradicionais e treiná-los como ScrumMasters para que a implantação do Scrum ocorra. É difícil um GP tradicional se tornar um ScrumMaster logo de cara. Os valores são completamente diferentes! Tudo isso que falo aqui seria assunto para um outro artigo no blog (PMPs, esperem esse novo artigo antes de atirar as pedras).

De qualquer forma, nós da Aspercom estamos vendo que essa estratégia de treinar TODA a equipe no Scrum está dando certo para todos os nossos clientes corporativos. O convencimento deve ser geral. É comum quando estou ministrando que a equipe técnica tenha dúvidas das práticas de engenharia (que geralmente são do XP e não do Scrum). Os Product Owners querem ser desgraçados gananciosos. Essas respostas devem ser dadas e não vejo que um GP tradicional treinado para ser ScrumMaster possa dá-las de imediato. É comum que uma dúvida técnica básica da equipe possa comprometer a adoção do Scrum.

O pessoal do Venturus tiveram um treinamento diferenciado. Eu não precisei convencer eles a usar o Scrum, pois eles já estavam vivenciando as práticas. O treinamento foi mais focado em Concepção Ágil, utilização de Stories, Design Emergente e principalmente Estimativas e Métricas Ágeis. Ao final, 70% dos alunos avaliaram o treinamento como Excelente e 29% avaliaram como Bom. A Equipe Aspercom agradece!

Certo dia, em certa empresa, fui convidado para participar de um treinamento sobre SCM (Gerência de Configuração). SCM é uma das áreas de avaliação para obter a certificação CMM que a empresa estava buscando. Realmente achei que o treinamento era válido pois a empresa não tinha uma cultura muito forte em Gestão de Configuração, porém, o treinamento foi um desastre. A consultoria que “estava nos ajudando” a obter o selo não explicou o que é SCM no treinamento. Basicamente eles ensinaram quais documentos a gente precisaria preencher e quando tirar as baselines para conseguir passar no assessment. A empresa obteve o selo CMM 2 a um custo próximo de MEIO MILHÃO de reais, mas não tem internamente boas práticas de desenvolvimento.

Olhando o CMM/i não tenho muitas críticas ao modelo em sí, mas sim critico o que essa “certificação” se tornou, a motivação das empresas para obtê-la e essas consultorias “tarja-preta” que te “ajudam” a obter o selo. Isso seria assunto para um outro artigo (não postem comentários defendendo CMMi, deixe isso para o outro artigo, ok?).

O ponto que quero comentar aqui é que ter projetos ou equipes externas para obter melhoria de processos é um grande engodo. Nunca ví isso funcionar e coleciono casos onde esse tipo de prática provou ser ineficaz. Sabe aquelas pessoas “responsáveis por definir os processos”? É delas que estou falando.

Não vou mentir pra vocês. Eu já participei desses “projetos” internos e confesso que essas iniciativas de melhoria de processo falharam miseravelmente. Quando digo que falharam estou pensando no lado financeiro da coisa não importando a melhoria obtida. Pare para pensar: Numa conta rápida esses “responsáveis por definir processos” são profissionais caro$ e custam mais de R$ 15 mil por mês. Se você tiver 2 ou 3 deles o custo pode ultrapassar R$ 45 mil reais por mês. Será que as ineficiências do processo são mais caras que 500 mil reais no ano? Qual é o ROI disso?

Eu ministro treinamento de UML. O que eu ensino (e já escreví sobre isso) é que UML não é documentação e nem especificação firme. É comum empresários e alunos associarem UML com melhoria de processo não sei porque. Por conta disso, tenho muito contato com esses “responsáveis pelos processos”. Eu uso o treinamento para mudar a cabeça de muitos com relação a processos de desenvolvimento. Um depoimento de uma aluna no ano passado resume o que ocorre em geral:

“- Os caras que cuidam dos processos lá na minha empresa são muito fechados. Eles não aceitam a opinião das equipes. A visão que eles têm do processo é que qualquer pessoa poderia pegar qualquer papel, mesmo sem conhecimento, e as coisas funcionariam mecanicamente. Segundo eles, AS PESSOAS NEM PRECISARIAM CONVERSAR, as tarefas chegariam pela ferramenta de gestão, o artefato é preenchido e encaminhado para o próximo responsável…”

Essa aluna em especial ficou surpresa quando expliquei a natureza empírica de um processo de desenvolvimento de software. O processo nunca é ÚNICO para a empresa toda. Cada projeto pode necessitar de um processo diferenciado. O processo pode inclusive mudar de iteração para iteração.

Nenhuma literatura prega essa “intervenção externa” para melhoria de processos de desenvolvimento de software dentro das equipes. Isso pode funcionar para um cartório, uma linha de montagem, um supermercado e etc… Porém, o Manifesto Ágil é claro ao dizer que pessoas são mais importantes que processos. O que nos traz à solução da equação: Na minha experiência, todas as vezes que um empresário/gerente me procurou falando que o problema era falta de processos eu ví que o problema dele era falta de capacitação e não de processos. Ví que corpo técnico não sabia levantar requisitos, eleger uma arquitetura, gerenciar o projeto e ter uma cultura de teste. Se as pessoas não sabem ou fingem que sabem fazer as tarefas dificilmente o desenvolvimento do software terá qualidade e produtividade. Não adianta por arreio em cavalo chucro. Ao invés de pagar centenas de milhares de reais para melhorar o processo de “fora-para-dentro”, gastar 50 mil em bons treinamentos traz mais resultados palpáveis no curto prazo.

Bons processos surgem de boas práticas de desenvolvimento de software. Bons processos surgem de boas pessoas em constante colaboração. O processo é uma coisa que emerge da equipe e não algo que é imposto externamente. Geralmente o que esses empresários precisam é de treinamento e não de consultoria de processos. As pessoas precisam conhecer desenvolvimento de software. O primeiro valor ágil é muito sobre isso e empresas que estão tendo suce$$o (leia-se dinheiro) já aprenderam que investir em pessoas é mais vantajoso que investir em “projetos de melhoria” de processos. Exemplos:

Google
http://blog.aspercom.com.br/2008/04/10/culturaempresarialemalta/

Thoughtworks
http://www.thoughtworks.com/who-we-are/TW-history-MA.html

Ainda sobre a ThoughtWorks, o Phillip Calçado “Shoes” nos falou um pouco sobre os processos de um projeto no blog dele (aproveite os links do post e também veja a opinião do Dr. Ivar Jacobson sobre o assunto). Essa lista envolve muitas outras empresas, inclusive aqui no Brasil. Esses exemplos são mais caracterizados pois são empresas grandes com projetos grandes e lucratividade compatível (grande). Essas empresas não têm esses “departamentos” de melhoria de processos, mas sim, bons departamentos de RH e de empowerment.

É engraçado como está tendo um movimento muito grande da indústria nesse sentido. A própria nova linha de produtos da IBM Rational (veja http://jazz.net) declaradamente diz “People not Organizations build great Software”. Creio que essa segunda geração de produtos alinhe de vez a IBM com Agilidade e enterre o RUP Waterfall praticado no mercado. Por mais que alguns de nossos “gestores tupiniquins” queiram fechar os olhos, desenvolvimento de software é puramente dependente de pessoas e não de processos. A alta rotatividade que temos hoje é um problema gerencial e não um problema do desenvolvimento de software em sí. É uma ilusão enorme achar que melhorar o processo irá diminuir a dependência das pessoas.

Se você é “a pessoa responsável pelos processos” não desanime! Existe uma alternativa! O foco da melhoria dos processos deve ser treinamento e menthoring. Acredite, os resultados serão muito melhores. Ajuste o foco para as práticas e para a colaboração das pessoas. Deixe de lado as reuniões inúteis, a definição de papéis e os templates do modelo de artefatos. Todas as metodologias são fundamentadas em valores e não em modelos de artefatos.

Atualmente surgiram algumas discussões em fóruns sobre a entrada de itens técnicos no Product Backlog do Scrum. A apostila do nosso curso Scrum pode dar uma idéia sobre o que é um Product Backlog:

“Os itens que aparecem no Product Backlog são qualquer tipo de funcionalidade ou tarefa que possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner representa. Esses itens seguem um conceito do SCRUM chamado incremento de funcionalidade potencialmente implantável. Uma funcionalidade potencialmente implantável significa que quando esse item do Product Backlog for finalizado ele estará completamente funcional e resolvendo algum problema de negócio dos Stakeholders.”
Rodrigo Yoshima, Gerenciamento de Projetos com Scrum

As discussões estão listadas abaixo:

http://br.groups.yahoo.com/group/agile-brasil/message/1738
http://br.groups.yahoo.com/group/scrum-brasil/message/751

Eu particularmente sou contra enfiar coisas que não agregam valor para o PO no Product Backlog. Bem, pra falar a verdade, defendo uma outra visão. Pode ser que existam itens criados por recomendação da equipe, mas tudo lá agrega valor de negócio para o PO. Lembre-se: O Product Backlog é um importante registro de métricas como prazos, produtividade, pesos funcionais e etc… É preferível que essas métricas importantes para o negócio não sejam poluídas com problemas técnicos da equipe (apesar desses problemas interferir nas métricas, são ortogonais à visão que defendo aqui). Gerar um script do Ant não é algo que constaria nos meus product backlogs.

Débito Técnico é um problema da equipe técnica. Se existem Débitos Técnicos é culpa (responsabilidade) da equipe técnica. Agora, nenhuma aplicação que desenvolví ou qualquer outra que tive contato É 100% LIVRE DE DÉBITO TÉCNICO. Já olhei código de algumas dezenas de projetos Open Source. Todos tinham algum débito, porém, isso é natural. Como vocês todos sabem, débito técnico é comparado com inflação. Tem que ser gerenciado. Nenhum economista consegue gerenciar algo como os 100.000% de inflação do Zimbabue.

É capaz que existam itens do tipo:

- Efetuar um teste de usabilidade com os usuários finais
- Efetuar um teste de carga com 480 usuários simultâneos

Já passei por essas duas situações. Mas esses itens foram para afastar riscos do negócio e não “Débito Técnico”. Esses itens constaram no Backlog sugeridos pela Equipe pois eram “técnicos”, mas negociamos com o PO. Esses itens constaram no Backlog pois tomaram muito tempo. Como exemplo, o teste de carga tomou quase 1 Sprint para ser efetuado.

Débito Técnico, Débito Funcional, Débito do Projeto

Atualmente defendo uma tese que nossa preocupação são as 3 qualidades do software. A qualidade interna, qualidade externa e qualidade do projeto (ver artigo “Modelagem Ágil”, MundoJava #27). Só para revisar, listo as 3 qualidades do software:

1. A solução atende ao negócio (qualidade externa).
2. O software é fácil de manter e evoluir (qualidade interna).
3. Menor custo e prazo possível (qualidade do projeto).

Um ponto que não mencionei no artigo é que com essa visão das qualidades nós temos 3 “listas de débitos” para gerenciar: débitos técnicos, débitos funcionais e débitos do projeto. Exemplos:

1. Débitos Técnicos:
- Melhorar o Build
- Melhorar a Documentação Técnica
- Melhorar a cobertura de testes
- Fazer passar PMD, Checkstyle
- Código Macarrônico
- Baixa coesão, alto acoplamento
- POG

2. Débitos Funcionais:
- Bugs
- Algumas funcionalidades pequenas não implementadas
- Funcionalidades não implementadas por conta de bugs em bibliotecas de terceiros
- Melhorar usabilidade
- Melhorar a “beleza” da aplicação

3. Débitos do Projeto:
- Uma linha de burndown acima do planejado (cheiro de atraso)
- Custo acima do esperado
- Falta de comprometimento dos Stakeholders
- Falta de financiamento
- Baixo ROI
- Falta de comprometimento da Equipe

Bem, logicamente essa minha tese ainda carece de melhores fundamentos teóricos. De qualquer forma não é algo novo. Simplesmente juntei vários aspectos que já constam em outras literaturas. Essa visão fez e faz sentido nos projetos que participei. Seu processo de desenvolvimento deve focar nas 3 qualidades e os 3 débitos devem ser gerenciados.

Documentando os Débitos

Débitos Técnicos podem ser facilmente gerenciados dentro do próprio código e com suporte das IDEs atuais. A maioria deles constam como //TODO:. Nas IDEs atuais como o Eclipse temos uma boa visão dos To Dos através da View “Tasks”.

Relacionados com Débitos Técnicos temos restrições arquiteturais. Restrições arquiteturais não são débitos técnicos, mas podem se tornar um, principalmente em projetos ágeis e iterativos. Restrições arquiteturais importantes podem constar num documento de arquitetura.

Para documentar débitos funcionais podemos usar o proprio Product Backlog, porém, a granularidade desse tipo de item (débito funcional) costuma ser bem pequena (como os exemplos que citei). Eu relaciono débito funcional como uma funcionalidade pequena que não impede que os usuários dêem a história como pronta, mas não deixa de ser desejável. Vendo dessa maneira, talvez essas pequenas funcionalidades podem constar como issues do Bug Tracking.

Já o débito do projeto pode ser melhor compreendido como o sentimento dos envolvidos com relação ao projeto (vide exemplos citados). Débitos do projeto costumam surgir nos bate-papos das reuniões ou durante o cafezinho da equipe técnica. Para documentar isso de maneira iterativa uma lista de risco é uma boa opção. Essa lista pode ser revista e atualizada durante cada Retrospective ao fim das iterações.

Um alerta importante é: NÃO ADIANTA SÓ DOCUMENTAR! Débitos devem ser vencidos. Para exemplificar, é muito comum que um Gerente de Projetos tradicional encha uma lista de riscos e vire as costas para o problema que ela representa, assim como um programador que faz um código ruim e não tem preocupações com a qualidade interna.

Estude mais:

http://blog.fragmental.com.br/2008/02/17/gerenciando-debitos/

http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html