Quality of Life? Does it Exist?

Today I just want to write about some thoughts that came to my head after reading the InfoQ article about Scrum adoption in China.

The article itself is very interesting, since it shows the benefits (and also problems) that companies have had when adopting Scrum. But what triggered this post was the chart shown below, provided by one of the interviewed companies, when they were asked What’s the benefit that Scrum brought to your project, your company?

What this chart shows is that Scrum improved the quality of worklife of most members of the team. And I am writing about it because I think this is one of the aspects of agile methodologies that isn’t perceived as much as it should.

When you work with agile, instead of working alone, you work in pairs, instead of holding all the problems by yourself, you share it and discuss it, instead of working as an individual, you are part of a team.

And that makes all the diference from when you work in non-agile environments, sit alone in your cubicule and interact only with your computer during all day. That makes a diference in your life.

So, if you don’t want to try agile because of the productivity aspect, at least try it for the sanity of the persons working for you.

Software (Engineering or Development?)

One thing that always interests me about software is the eternal discussion, that has been going for some years now, about the relationship between software development and other engineering disciplines.

On one side stand the traditional approach folks, claiming that software projects are the same as any other engineering projects, and because of that, should be managed as other engineering projects (the favorite one is civil engineering, with house building…)

On the other, the agile practitioners don’t accept software development to be called “engineering”, and say that this is probably one of the reasons software development is in this situation nowadays (not a good one, as you may conclude).

So, what is the right answer? In my opinion, both! To the explanation…

Martin Fowler wrote something about it in this article (everybody knows which side he is in ), where he explains why the traditional civil engineering approach can not work in software development. Quoting one of his sentences

Can you get a design that is capable of turning the coding into a predictable construction activity? And if so, is cost of doing this sufficiently small to make this approach worthwhile?

And I totally agree with him. If you look at UML models and other software design methodologies, there is no way to design a software in such detail so that the construction phase could be a less skilled activity, with predictable results. All you get in projects with long design phase is a lot of rework in the construction phase.

Ok, so software is not civil engineering, but is it not engineering at all? That’s what got clearer after reading the appendix F of the Rogers Commission Report, written by Richard Feynman, which investigated the Challenger Space Shuttle disaster, in 1986.

Now, if you are still paying attention, you should be asking: “What space shuttles have to do with software?”

Simple, it’s engineering. And not just that, it is high technology engineering.

Take a look at what Dr. Feynman said in his report about the space shuttle main engine (quoted from this other blog, where I’ve found all the material):

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes.

Anything rings a bell? How about that?

The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), …

With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood.

Well, I don’t know what are you thinking, but when I read that, it seemed to me that somebody was talking about iterative software development. And that’s the whole point about it, software development can be compared to an engineering discipline, but to an advanced engineering discipline.

If you try to compare developing software to building houses, you try to compare 2000 years of experience to something we started to do in the last century. But even in software, if you go to well known domains, with well known technologies (not easy to find projects like that… ), you can probably automate the process with different tools, making it a “less skilled task” and also a lot easier.

But in the great majority of projects, developing software is still about messing with recent discovered technologies and changing domains, and that what makes it so hard.

So, just to make a final point, software development is rocket science!

Cheers!

“Tell me how you’ll measure me…” (2)

Coincidence or not, after writing the last post, I’ve just received the InfoQ newsletter, which contains this article, about bonus distribution within agile teams. And what does it have to do with measures and incentives?

Well, if you want to have some great individuals, reward them based on individual performance, if you want a great team, don’t try to establish some weird criteria, and measure everyone’s performance based on the team result.

Like Mary Poppendieck cited on her book, distribution of bonus to an Agile team is like playing with dynamite.

Duas Cabeças Pensam Melhor Que Uma?

A fagulha necessária para a criação de um post surgiu na leitura de alguns posts por aí (como esse), que me fizeram lembrar de um assunto sobre o qual eu tenho vontade de escrever a algum tempo: programação em pares.

Uma das razões para eu escrever sobre isso é o fato de eu já ter experimentado a programação em pares em duas oportunidades, a primeira na minha empresa no Brasil, e a segunda agora na ThoughtWorks University, e nesses dois períodos eu tenho percebido muito mais vantagens do que desvantagens nessa prática.

Programar em duplas, embora possa parecer anti-econômico à primeira vista, resulta em código muito melhor, aumenta a produtividade dos desenvolvedores (que não tem tempo para ficar lendo e-mails e falando no msn) e, principalmente, propicia o compartilhamento de informações e habilidades entre todos os membros da equipe, um dos problemas abordados nesse outro post.

Por sinal, o compartilhamento de informações é auxiliado por uma outra prática, que é a troca freqüente de pares, o que é detalhado no artigo Promiscuos Pair Programming, de Arlo Belshee, que também incentiva uma terceira prática, que é de o driver da dupla (o desenvolvedor que está efetivamente teclando) , seja aquele que possui menos experiência no que está sendo feito, para que assim este aprenda novos conceitos o mais rápido possível. Citando o artigo acima:

Promiscuity, it turns out, is a good way to spread a lot of information through a group quickly. Rapid partner swapping ensures that a good idea, once envisioned, is soon practiced by every pair. Replacing individual accountability with team accountability empowers each person to do those tasks at which he excels – and allow someone else to take over for his weaknesses.

E colocando o chapéu de desenvolvedor, para mim o principal benefício da programação em pares é um ambiente de trabalho muito melhor, e uma maior integração entre todos os membros da equipe. Faz diferença trabalhar ao lado de alguém, podendo conversar, trocar idéias e criar um relacionamento, ao invés de simplesmente chegar na empresa, sentar na frente de um computador e ficar lá até a hora de sair, sem falar com ninguém, como eu já vi em alguns ambientes onde eu trabalhei.

É claro que podem também surgir problemas na programação em pares, como é ressaltado nesse post, onde a troca excessiva de pares pode ser um problema. No entanto, ainda acho que esse e outros problemas podem ser resolvidos com bom senso, e os benefícios da prática são muito maiores.

Mas o que me incomoda um pouco (e também é uma das razões desse post), é que no Brasil pouco se tem falado sobre a utilização de programação em duplas. Em todas as listas e blogs que eu acompanho, essa prática era ressaltada a algum tempo atrás, mas parece que foi perdendo força aos poucos e hoje quase não é citada. Além disso, não tenho ouvido muitas notícias de empresas no Brasil adotando essa prática, ao contrário do que acontece no exterior.

Espero que eu esteja errado, e que as empresas estejam percebendo as vantagens de programar em duplas, e de como essa prática pode ser fundamental na formação de uma boa equipe de desenvolvimento de software.

Então, o que vcs acham, duas cabeças pensam melhor do que uma?

Abraços.

Behaviour Driven Development

Para os que não sabem, atualmente eu estou em Bangalore, na Índia, participando do treinamento que a Thoughtworks oferece aos seus novos graduates, a ThoughtWorks University.

Bom, ontem, depois de assistir a uma sessão opcional do curso, apresentada pela Liz Keogh, eu finalmente posso dizer que entendo o que é Behaviour Driven Development, o famoso BDD. Essa é uma das buzzwords do mundo do software que circula ha algum tempo, mas devo confessar que nunca consegui parar para verificar o que era, e sempre imaginei que fosse mais uma metodologia ágil, tipo o FDD.

Acontece que o Behaviour Driven Development é algo talvez até mais simples, mas nao por isso menos interessante .

BDD nada mais é do que uma “otimização” do desenvolvimento orientado a testes, que tem como sua principal característica, e ainda mais importante, benefício, o fato de codificar as aplicações em uma linguagem voltada para o que é mais importante e muitas vezes esquecido, o resultado que a aplicação tem para o cliente.

Olhando por aí, uma justificativa interessante que eu achei foi a seguinte, no blog do Dan North:

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Já que todos (todos?) concordamos que entregar valor de negócio para o que cliente é o que realmente importa no desenvolvimento de uma aplicação, porque não desenvolver essa aplicação de acordo com a linguagem do cliente, de forma que até ele possa entender (mesmo que em um nível básico) o que a aplicação está fazendo, e para que serve aquele código.

É claro que não é só esse o benefício, já que muitos de vcs devem estar pensando: para que diabos o meu cliente que ver o código-fonte do software?

Mas desenvolver código-fonte de acordo com a linguagem do negócio também auxilia o desenvolvedor a entender e discutir as funcionalidades que ele está desenvolvendo, e realmente saber qual é o objetivo de ele sentar na frente do computador 8 horas por dia, o que invariavelmente resulta em código de melhor qualidade.

Comentários?

Um abraço.

Empresas x Funcionários (Round 3)

O post de hoje surgiu de uma discussão que está havendo em uma das listas em que eu participo (round 1), onde o assunto principal é como as empresas devem lidar com a questão do conhecimento, ou seja, como fazer com que o funcionário (que pode ir embora a qualquer momento) não seja detentor de tudo o que uma empresa de tecnologia tem de maior valor: seu capital intelectual.

Como a lista é de métodos ágeis, vcs podem imaginar que o tópico esteja girando em torno da documentação, e de como ela é (é mesmo?) necessária para que a empresa não seja refém (esse é o termo sendo utilizado…) dos seus funcionários.

Essa discussão já gerou um outro post (round 2), onde o Flávio comenta como isso é ainda mais preocupante em pequenas (ou micro) empresas, que realmente não têm todo esse fôlego para pensar em grandes alternativas. Citando o Flávio:

Vejam, falamos de situação em que micro-pequenas empresas precisam sobreviver dia-a-dia ao mercado burocrático e sufocante que o governo provê… são raríssimas as empresas que conseguem parar, respirar, organizar e seguir adiante. É tudo feito sob-demanda.

Então, a solução, é claro, é fazer as “vontades” dos funcionários. Tornar a empresa atrativa para que estes se sintam satisfeitos e reconhecidos, e assim, permaneçam na empresa.

Realmente, eu tenho que concordar com o Flávio. Já tive a minha micro empresa e sei como é esse cenário que ele está descrevendo. No entanto, eu acho que a solução para esse caso é o mesmo do que para as grandes empresas (claro que um pouco mais difícil… )

No meu ponto de vista, realmente a empresa não deve se preocupar em se tornar “refém” dos seus funcionários, simplesmente pelo fato de que ela sempre o é. Eu não tenho dúvidas de que qualquer grande, média ou pequena empresa (de tecnologia), se perder grande parte dos seus funcionários, não terá mais como seguir competindo no mercado. Eu acho que a preocupação que cada empresa deve ter é de não ser refém de um ou poucos funcionários, porque nesse caso sim, a perda de um funcionário específico (o que pode acontecer com certa freqüência), é um grande problema para a empresa.

É claro que o primeiro passo para que isso não aconteça, assim como alguns participantes da discussão levantaram, é fornecer um bom ambiente de trabalho para todos que estão na empresa. Não acho que se deva ser refém do funcionário, nem fazer todas as vontades dele, mas sim respeitá-lo e valorizar o trabalho que ele está fazendo, e isso não passa apenas pelo seu salário, como alguns podem entender. Se dermos uma olhada na Pirâmide de Maslow , que lista as necessidades que as pessoas desejam satisfazer, pode-se notar que a renda (ou segurança de recursos, como está na pirâmide) está apenas no segundo nível de necessidades, e que existem outros três níveis acima, sendo que esses também devem ser providos pela empresa onde essa pessoa está trabalhando (ok, intimidade sexual talvez não…).

Agora alguém deve estar pensando:

Ok, estou fazendo tudo isso, mas nada impede de alguma empresa vir aqui e oferecer um cargo muito melhor para meu funcionário, certo?

Certo. Nada impede isso, e daí que entramos no segundo ponto que eu considero importante. Conforme eu li em algum livro (não me lembro qual), há uns tempos atrás, o dono da empresa (ou gerente da equipe, como era o exemplo do livro) deve sempre saber qual é o Truck Number de sua empresa, ou seja, quantas pessoas devem ser atingidas por um caminhão para que a empresa afunde.

Se esse é um número pequeno, realmente a sua empresa tem problemas. E para resolver isso, nada melhor do que espalhar o conhecimento entre seus funcionários, ou seja, criar uma cultura de troca de conhecimento, e também exigir que os funcionários mais capacitados (os seqüestradores, seguindo a analogia.. ) passem o seu conhecimento para os demais membros da equipe.

E nesse ponto eu discordo de alguma opiniões que eu li durante a discussão, onde se afirmou que deve-se então criar documentos e documentos para armazenar o conhecimento das pessoas. É claro que talvez sejam necessários documentos, mas deve-se ter uma grande atenção na quantidade e também no tipo de documentação que se está criando, já que, assim como em projetos, escrever documentos para ficarem no armário não serve para nada.

O principal é não ter um ambiente (como alguns onde eu já trabalhei), onde cada funcionário é dono do seu nariz, detentor do seu conhecimento e não faz a mínima questão de passar isso adiante, com medo de que se torne substituível por outro. Na minha opinião não serve ter uma pessoa extremamente capacitada se ela não estiver pronta para compartilhar isso com outros.

O mais importante, é realmente criar um ambiente onde o conhecimento seja compartilhado entre os funcionários, seja através de programação em pares, seja através de reuniôes freqüentes, mini-workshops internos ou um wiki da empresa, ou qualquer outro método que se considere interessante, mas ao mesmo tempo não atrapalhe demais o andamento do trabalho, e que realmente seja útil quando aquele funcionário for embora.

Acho que era isso o que eu tinha a dizer, espero que vcs tenham opiniões a respeito!

Um abraço.

Lean no MIT

Pra quem ainda não conhece Lean, ou acha que não é serio, tem uma lista legal de artigos nesse post, que são alguns dos que fazem parte do MIT Lean Advancement Initiative (LAI).

A Fantastica Fabrica de Testes (nao seria melhor a de chocolate…?)

Ha alguns dias (ou seriam semanas?) atras, foi enviada uma noticia para uma das listas de e-mail das quais eu participo, sobre a criacao de uma fabrica de testes no Parana. So essa noticia ja eh impactante para mim (como foi para os outros membros da lista), mas alem disso ha algum tempo vem exisitindo uma tendencia de criacao de empresas especializadas em testes, tanto que eu acho interessante comentar isso por aqui.

Primeiramente, eu acredito que pelo conteudo de um meu outro post, vcs ja devem saber qual vai ser a minha opiniao a respeito da existencia de equipes especializadas em teste de software. Primeiro a gente tinha analistas especializados, agora a gente tem testadores especializados, e inclusive empresas responsaveis soh por desenvolver testes, as “fabricas” (argh) de testes. Qual sera o proximo passo? Especialistas em testes unitarios? Especialistas em analise de software usando diagramas de sequencia UML?

Pra comecar, o proprio fato de existirem especialistas em cada area, cada um tratando do seu nicho, soh traz maleficios para uma equipe, se eh que se pode chamar de equipe um grupo de pessoas onde cada uma trabalha em uma tarefa separada sem existir um foco no resultado final, que eh software rodando para o cliente. Alias, o final dessa frase eh que faz toda a diferenca, na minha opiniao. Conforme foi escrito pelo Goldratt no livro “A Meta”, “Diga-me como serei medido que eu te direi como me comportarei“. Essa afirmacao resume tudo, pq eh claro que se existir um cargo que eh medido pelos seus diagramas, teremos como resultado diagramas extremamente requintados, e se tivermos um que for medido pelos testes que gera, o que teremos? Testes, testes e mais testes, necessarios ou nao.

Mas esse eh soh o primeiro dos problemas da fabrica de testes. Eu considero particularmente a realizacao de testes umas das principais contribuicoes do movimento agil para o desenvolvimento de software, principalmente quando se falar em TDD. Mas essa validade acaba e comeca a contar pontos negativos quando os testes nao sao mais utilizados para guiar nem para verificar o desenvolvimento de software, e sim para serem criados apos o desenvolvimento e darem uma “cara” de seriedade para o codigo sendo desenvolvido.

Alias, acho que esse eh o principal motivo da existencia das equipes de testes. A impressao de seriedade que a empresa quer passar para o cliente, dizendo que seu software eh testado por uma equipe especializada, sendo que essa equipe certificou que o software esta funcionando corretamente. No meu ponto de vista, a palavra “certificou” diz tudo sobre as intencoes que existem por tras disso . Primeiro vem o CMM, depois o MpsBr, e agora os softwares saem certificados por testadores especializados.

Quero deixar claro aqui que eu nao sou contra a existencia de especialistas, e muito menos contra a existencia de testes. Acho que os especialistas sao necessarios, e todo mundo tem um assunto no qual tem mais interesse e torna-se por isso mais experiente, e tambem acho que todas equipes precisam de especialistas . O que eu nao concordo eh com a existencia de especialistas que fazem somente uma coisa, e nao estao inseridos dentro de uma equipe multidisciplinar que conta com diversos especialistas em diversas areas. Em relacao aos testes, conforme eu falei antes, acho eles vitais quando inseridos dentro do ciclo de desenvolvimento do software, na forma de testes unitarios, de aceitacao e de qualquer outro tipo que se quiser fazer. O que eu nao entendo eh desenvolver milhares de linhas de codigo e passar para uma empresa testar, e dai depois de tres semanas voltar um relatorio com milhares de erros, quando os desenvolvedores que trabalharam naquele codigo ja estao preocupados com outra coisa.

Eh tao dificil assim fazer o mais simples?

Sistemas, sistemas… quando vamos entende-los?

Então vamos ao segundo post desse blog… Como vcs podem ter notado, estou começando a escrever o meu blog, e como não tenho muito costume nisso, ainda tenho buscado inspiração em outros posts que encontro pelo caminho, acrescentando minha opinião sobre assuntos que estão sendo discutidos…

A bola da vez foi encontrada em um post do Phillip Calçado que trata sobre a existência da famigerada profissão de “analistas de sistemas”, e como essa profissão tem perdido seu valor. Só para deixar claro, concordo em gênero, numero e grau com o que o Phillip disse, e na verdade esse post é para expor mais um lado dessa situação, e explicar o porque da minha concordância.

Eu imagino que agora vcs devem estar pensando que os “sistemas” do título do post fazem referência ao “sistemas” do analista. Na verdade não. Na verdade eles fazem referência aos sistemas que são utilizados para desenvolver software, mais chamados na nossa área de processos, ou metodologias. Eu usei a palavra “sistema”, pq esse é o termo usado pelo William Deming, um dos primeiros escritores que falou sobre a visão sistêmica, tão em voga hoje em dia nos manuais de admistração, e no qual eu também me inspirei para escrever esse post.

A inspiração a qual me refiro eu tirei do livro The New Economics, no qual uma das afirmações feitas pelo autor é que se uma equipe não está fornecendo os resultados esperados, a culpa é sempre do sistema sobre o qual ela está trabalhando, e não dos seus membros.

E o que que isso tem a ver com os analistas de sistema, citados pelo Phillip? No meu ponto de vista, bastante coisa, pq eu acho q a simples existência de analistas de sistemas, é um dos grandes problemas das abordagens tradicionais de desenvolvimento.

Pq isso? Bom, vamos às explicações… Hoje em dia, todo mundo (agilistas ou não) concorda no ponto que os projetos devem ser desenvolvidos da forma mais simples possível, e que grande parte da complexidade do software é colocada nele desnecessariamente, complicando o seu desenvolvimento e principalmente sua manutenção, certo?

Mas agora, como se quer diminuir a complexidade de um projeto, se colocando uma pessoa que trabalhe especificamente para modelar um sistema? Imaginem se vcs fossem analistas de sistemas (talvez alguns o sejam…) e lhes fosse passado um projeto para vcs modelarem. Teria algum sentido vcs modelarem ele com diagramas extremamente simples, do tipo que o programador olha e diz: “Se era para fazer só isso, eu também poderia ter feito..”? Claro que não! Para manter a necessidade de existência do cargo, e até o seu status, todo analista vai propor um design que realmente mostre o seu valor, que realmente o diferencie dos seus colegas programadores, até pq essa e a grande contribuição que eles estão dando como membros da equipe, e tanto faz se aquilo vai ser extremamente dificil de implementar e manter. O melhor é enviar aquele calhamaço de folhas para impor respeito… : )

E ai que entra a sabedoria do Deming. A culpa dos analistas criarem modelos complexos não é deles, e dos gerentes e diretores que estabeleceram um processo de desenvolvimento onde o valor da contribuição que eles dão está baseada (mesmo que subconscientemente) na complexidade do que eles entregam. E esse é um dos pontos onde eu vejo grande vantagem nos métodos ágeis, justamente pq eles colocam sob responsabilidade do desenvolvedor a modelagem do sistema, e esse aí não tem nenhum compromisso com a utilização de padrões requintados, apenas com o funcionamento do software.

Que tal?

Feedback positivo,negativo e de qualquer outro jeito…

Eu faço partes de algumas listas de e-mail sobre desenvolvimento ágil (apesar de ser mais um ouvinte do que um participante : ), e recentemente foi enviado o link para um artigo bem legal sobre os 12 pontos de alavancagem sistêmica, e como isso pode ser relacionado à métodos ágeis.

Bom, é claro que achei o artigo bem interessante, já que o estou citando aqui, e não vou falar sobre como a visão sistêmica tem a ver com métodos ageis, porque isso todo mundo tá meio careca de saber, e também pq o artigo fala justamente sobre isso, entam vcs podem ler isso lá.

O motivo desse post é que enquanto estava lendo os doze pontos citados no artigo, e como eles influenciam no desenvolvimento de software, tive uma idéia que achei que valesse a pena colocar no papel (ou no blog…).

Eu nao discordo da importância de cada um dos doze pontos na organização do sistema de desenvolvimento de software, acho q todos são validos de serem citados, mas para mim existem dois pontos citados ali que são a base de todo sucesso, que são o feedback positivo e o feedback negativo.

Vamos às explicações…

Na minha opinião, toda a força dos métodos ágeis, e o motivo de eles funcionarem tão bem reside no fato de que todas as práticas adotadas visam o fornecimento de uma rápida resposta sobre o andamento do projeto. Como exemplos podemos citar a realização de testes, para ter feedback do código, as reuniões diárias, para ter feedback da equipe, as iterações curtas, para ter feedback do cliente, a programação em duplas, para ter feedback imediato sobre o código sendo escrito, e por aí vai…

Não querendo me alongar muito, acho q esse é o ponto mais importante a ser cuidado e incentivado no desenvolvimento de projetos, pois esse ponto (ou a falta dele) é que vai fazer a equipe evoluir para uma equipe de sucesso ou seguir errando. Só se ouvindo todos os participantes do processo, e se tendo uma boa visão do que está acontecendo de bom e de ruim, é que se vai ter condições de tomar qualquer atitude para mudar alguma coisa, ou incentivar a sua realização (através de qualquer um dos outros 10 pontos do artigo, por exemplo).

Isso é tão essencial que sempre quando se fala em metodos ageis, existe um consenso de que não existe o conjunto de práticas perfeito, e sim que cada equipe deve descobrir qual a metodologia que melhor se adapta a seu caso.

E como se faz isso? Bom, espero que eu tenha sido claro o suficiente para vcs saberem a resposta… : )