Cuidando para que o software não apodreça

Legal o post, Guilherme! Lendo as referências ainda..

Falamos bastante sobre isso no último review, e decidimos incluir também que:
* todos do time devem ter revisado aquela história (código e interface)

Como o PO não vê nenhum sinal de apodrecimento no início (talvez sinta o cheiro mais tarde..), você acha que o ScrumMaster deve ser ativo na cobrança por qualidade? (assim como o PO cobra valor de negócio entregue) Ou é o time que tem que se tocar mesmo? :p

abraço.

Nunca gostei dessa analogia com jardinagem. A meu ver, o papel do Scrum Master parece com o do Jardineiro, que fica cortando, podando, plantando mudas e jogando sementes nos locais certos para que as plantas cresçam no rumo planejado. No entanto, o resto da equipe tem uma responsabilidade maior em fazer do que em “cortar as pontas”. Como ninguém faz uma planta crescer, simplesmente espera, a analogia fica um tanto quebrada.

Não sei se você já acompanhou a construção de uma casa de classe média (não de um prédio). A analogia para a planta de uma casa não deve ser entendida como aquele monte de documentos imutáveis do rup e do desenvolvimento em cascata que as especificações nunca são alteradas, mas sim como as tuas user stories. A planta da casa representa o desejo do cliente (Imagine seus testes de aceitação). Esta planta vai mudar, porque o cliente vai ver como a casa ficou na realidade e, provavelmente, não vai gostar de algumas coisas.

Eu gosto da analogia de construção de casas porque você constrói a casa em partes, assim como o software. Primeiro o fundamento, depois as paredes, a hidráulica e elétrica, o piso e o teto. Após a pintura, colocação de piso, gesso, móveis, etc. As vezes acontecem coisas como: os operários se reunírem para começar e concluir o banheiro no mesmo dia. Isso é como nós fizemos software. Primeiro a arquitetura (fundamento), depois testa-se a principal user story para ver se funciona (paredes), depois as outras junto com a lógica de negócios que transita entre as US (redes hidráulica e elétrica), acompanhado das regalias de user interface.

@Vitor

Desculpa me meter aqui… Mas é exatamente essa analogia (construção de casas) que não queremos para o desenvolvimento de software.

Cada funcionalidade construída do software deve ser algo que possa ser usado pelo usuário final, que traga valor para ele. Não queremos fazer toda a camada de acesso ao BD para depois fazer a camada de serviços e por último a interface do usuário.

Usando a sua analogia, a forma que defendemos de construir software, seria construir, por exemplo, o banheiro inteiro, com absolutamente tudo para ele funcionar: fundamentos, instalação hidráulica, elétrica, acabamentos, decoração. Só aí partiríamos para a construção da sala e assim por diante. Obviamente sabemos que uma casa não é construída assim, por isso a analogia não valeria.

Abs.,

Guilherme Cirne

@Vitor, o @Guilherme Cirne tem razão.

Você não pode entregar uma casa toda só com paredes e sem encanamento, certo? Desse jeito só daria para usá-la no fim da construção. Da mesma forma em software, você não pode entregar somente a “arquitetura do software” sem nada funcionando porque isso não tem valor para o cliente. Em desenvolvimento iterativo e incremental (como é feito em “metodologias” de desenvolvimento ágil), entrega-se uma coisa do início ao fim. Cada história tem sua arquitetura, desenvolvimento, testes, deployment e etc.

Isso que vc propôs é desenvolvimento waterfall.

[ ]s, gc

Não concordo. O fato de eu desenvolver o banheiro (ou qualquer outra parte/feature) inteiro primeiro (se assim optar) é para deixá-lo funcionando para o cliente a pedido dele (prioridades) e já permitir o seu uso (small releases).

Você pode usar a sua casa sem o telhado (Segurança), só não pode chover (Mesma coisa que fazer um ERP sem se preocupar com Autorização de usuários) 🙂

Da mesma forma que eu software, o cliente não vai usá-lo sem o básico dos requisitos implementados (fundamentação, paredes e telhado). Depois disso, ele pode vir morar na casa a hora que quiser, só que vai se incomodar com o pessoal ainda trabalhando nela (assim como acontece com software).

Que merda… estou começando a detestar analogias. Dá muita margem a interpretações.

@GC

Realmente, se procura desenvolver um software da forma correta, seguindo o principio do KISS, boas práticas, etc, o refactoring tende a ser menos problemático.

É que eu acho que pelo menos esse passo:
“* Testar segundo os critérios de aceitação estabelecidos pelo cliente”

Tem que ser feito (também) no final, antes da ultima mexida, por menor que ela seja, para “garantir” que o projeto funciona.

Grande Guilherme, mais um excelente post.

O único risco na adoção da metáfora do jardim é que muitos programadores vão adotá-la e só vão jogar adubo como sempre fizeram.

(piadinha) 😉

Apenas adicionando ao Post do @GC. Ken Schwaber chama este software podre de “dead core”, e se vcs lerem o capitulo 9 pag.93 do livro “The Enterprise and SCRUM” onde ele descreve o que é um dead core irão se identificar imediatamente :-), pelo menos quem já passou por isso.

Além disso como vc pode adaptar a analogia da construção civil ao desenvolvimento de software no caso do refactoring? Quando Quarto, Sala, Cozinha, banheiro estiverem prontos, como vc faz para trocar a fundação? Ai é que esta, não faz! Mais um exemplo de porque é uma péssima analogia.

Falando em analogias a Mary Poppendieck faz uma analogia muito boa entre desenvolvimento e produção, usando um exemplo de um restaurante:

“Desenvolvimento é bem diferente de produção, Pense que o desenvolvimento é como criar uma receita e que a produção é como seguir (executar) esta receita. Estas são atividades muito diferentes, e elas deveriam ser resolvidas com abordagens diferentes. Desenvolver uma receita é um processo de aprendizado envolvendo tentativas e erros. Você não espera que a primeira tentativa de um Chef, de nível internacional, ao fazer um novo prato seja sua última tentativa. Na verdade, toda a idéia de desenvolver uma receita tem o objetivo de testar muitas variações e descobrir o melhor prato.
Uma vez que o Chef tenha descoberto a receita, para preparar o prato, basta seguir a receita.”

Pois é @Roger Leite.

Seria importante ouvirmos um relato/experiência ou sugestão para softwares já apodrecidos.

Abraços

Fabio Nascimento.

Quantos de nós já não passaram por isto?

“Software is not physical. It’s certainly not sexy. All I have to do is answer the question, ‘What do you do?’ at any party to learn how absolutely uninteresting my chosen profession is. I say, ‘I work with software,’ and the questioner visibly glazes over and turns to the next person. (Or worse, they grill me about using Photoshop. I’ve never used Photoshop in my life.) I’ve come to dread that question.”

As analogias citadas até aqui cobrem alguns aspectos do desenvolvimento, mas não possuem a mesma abrangência da analogia da “Construção de prédio”. Não estou dizendo que ela seja boa, mas ela se mostra muito atraente tanto por ser mais próxima de “negócios” como por cobrir muitas dimensões. Vamos assumir que queremos ilustrar as seguintes dimensões:

1) a natureza criativa e colaborativa do trabalho;
2) o caráter iterativo/incremental da construção das soluções visadas;
3) a temporalidade e a complexidade crescente dessas soluções;

Vou tentar aqui uma analogia que me agrada mais, usando um pouco da inspiração do que já ouvi falarem na comunidade Ruby. Desenvolvimento de Software parece um pouco com composição de música. Mas se o software em questão for um sistema maior e de longa duração, pode ser que a melhor analogia seja com as composições de uma Banda de música! Um disco, um show, uma carreira. Envolve arte, técnica e negócios. No caso do trabalho/obra, seria algo como um trabalho encomendado, onde essa “encomenda” lembra a forma como antigamente as óperas eram financiadas, alguém com dinheiro suficiente querendo uma peça musical que atenda suas necessidades (Um requiem? Uma homenagem? Entretenimento baseado em alguma *história* ou *tema*?). Os integrantes colaboram nas composições e por precisarem atender a um “mecena/patrocinador” faz sentindo exibirem a composição aos poucos (iterativamente) para ver se agrada/atende aos “requisitos” (muitas vezes nebulosos) e de uma forma simplificada, afinal não faz sentido orquestrar um rascunho! Enfim, é possível equiparar uma banda a uma equipe de desenvolvimento e seus trabalhos. Eis alguns pontos que me ocorrem:

– Ter que atender a um Produtor/Patrocinador (Gerentes, Analistas de negócio) e ainda por cima ao público (Usuário final) para fazer sucesso não é tarefa fácil, ou esses intermediários fazem um papel muito bom como proxy do mercado ou é melhor se aproximar mais do público para saber o que realmente desejam ou então ser alguém parecido com seu próprio público, o caso é: estar bem próximo das fontes de necessidades e/ou anseios.
– Durante os primeiros rascunhos executados nem todos os trechos/músicas precisam estar no mesmo grau de maturidade, na versão final (se o escopo/tempo permitir) as coisas podem mudar bastante até a gravação final, ou mesmo depois, se considerarmos os shows ao vivo (freqüentemente há variações).
– A unidade “música” pode ter semelhanças com uma classe ou um pacote de classes (dependendo da complexidade), ou mesmo um “tema” (no sentido usado na teoria musical) se assemelha a uma classe, uma vez que pode ser usada várias vezes numa mesma música e até em outras de uma mesma obra (disco? ópera?).
– Novas encomendas com “requisitos” semelhantes podem reutilizar partes das soluções anteriores (ou técnicas). Muitas vezes isso extrapola a própria banda. Talvez por isso vejamos tantas bandas e/ou músicas parecidas num determinado período de tempo.
– Várias coisas podem ser “acopladas” ao trabalho musical, tais como: clipes, capas de cd, coreografias, livros, etc. Outras vezes são pensadas juntas desde o começo, como ocorre às vezes em trilha de filmes, musicais ou óperas. Artistas/técnicos de outras áreas agregam valor tal qual designers aos sistemas baseados na web, daí ser importante saber trabalhar com pessoas de outras áreas.
– Treino e disciplina são importantes para dominar ferramentas, compor melhor e executar melhor em conjunto e sem erros. Não adianta crescer sozinho ou só saber tocar solos, é uma banda!
– O relacionamento da banda tem que ser cultivado e mantido sadio para a banda sobreviver e continuar criativa.
– O valor não está nos instrumentos, mas em quem os usa. De pouco serve a melhor guitarra do mundo na mão de alguém que não sabe usá-la em todo seu potencial. Ou, quão bom músico pode ser considerado quem só sabe usar aquelas Pick ups de Dj para mixar música dos outros (“apertador de parafusos de frameworks”)?
– A banda vai fazendo seus “discos” e vai precisando se renovar, se não fizer muitos sucessos novos o número de músicas “legado” (antigos sucessos) vai aumentando e deixando os shows mais complexos e chatos para os mesmos. A idéia é não ser uma banda de um sucesso só ou presa a um passado que não consegue superar. Se a Banda não se preocupar em se atualizar e melhorar corre o risco de só tocar em “Festas da Saudade”…
– Quanto mais os integrantes da Banda treinarem e comporem coisas fora de sua zona de conforto melhor músicos se tornarão.

Enfim, como toda analogia tem falhas. Mas não precisa ser mesmo perfeita, basta ser suficiente para ajudar na comunicação de algumas idéias.