Gestão por Processos

Lendo o livro de David Anderson (2010 - Kanban), percebi um detalhe interessante que estava passando desapercebido por mim.

Ele diz que descobriu e ficou curioso sobre teoria das restrições, e aprendeu os conceitos iniciais desta técnica. São cinco passos para melhorar o desempenho do sistema a partir da identificação do elo mais fraco da corrente. Muito simples, muito interessante, dizem que roubado dos japoneses que não tinha tradição de publicar nada, mas já praticavam a maioria das técnicas propostas por Goldratt sem ter documentado no Sistema Toyota de Produção.

Ocorre que no trabalho em manufatura tais conceitos são claramente úteis, mas na administração de serviços administradores, gerentes de projeto, executivos mais tradicionais não percebem como ou onde aplicar tais técnicas. A administração contemporânea de serviços segue uma linha de princípios e técnicas separada da manufatura industrial.

Entretanto David Anderson explica que ao perceber os conceitos da indústria de manufatura, instintivamente percebeu como aplicá-los para o gerenciamento do desenvolvimento de software.

Ele percebeu que poderia olhar para o problema de desenvolvimento de software como um trabalho em fluxo. Desta forma a otimização do fluxo poderia utilizar a técnica de TOC (Theory of Constraints) de Goldratt, com a qual ele estava encantado.

Ele aplicou em seu trabalho como gerente de projetos na M$ e obtever resultados muito bons.

Na verdade, muitos dizem que TOC é um sistema produtivo, mas eu o considero na verdade uma filosofia para otimização de processos. Deverá existir um processo especificado para a produção que será otimizado pelos princípios da TOC.

Da mesma forma, existem outras metodologias de otimização de processo como o Pensamento enxuto com seus 5 passos, as ferramentas do STP, Six-Sigma, Sense and Respond, Sistema da Volvo, entre outros.

Ele deu continuidade em seus estudos e percebeu a amplitude de conhecimento sobre processos no Sistema Toyota de Produção e no Lean Thinking. Melhorou ainda mais os resultados para desenvolvimento de software.

Ao publicar estes resultados causou polêmica na academia, pois de fato as áreas de manufatura e serviços ainda usam princípios e teorias separadas.

Ocorre que qualquer ambiente administrativo "gerenciado" por administradores "convencionais" pode ser transformado em um processo, e como tal, irá apresentar sob este novo ponto de vista um fluxo, com lead-time, cycle-time, variação, anormalidades, sigmas, etc.

Isto se chama Gerenciamento por Processos. Pode-se manter todos os conceitos da "ciência administrativa", e seus caminhos, paradigmas e tal, porém observando o sistema delimitando-o geograficamente como um processo, limitado pelas fronteiras, entradas e saídas, e possibilitando assim trazer a cultura de processos da indústria para o ambiente de serviços.

Assim, torna-se possível melhorar 5 a 10 vezes o desempenho de qualquer departamento administrativo. As melhorias de qualidade na produção chegam a taxas superiores 90% em departamentos mal "administrados". Diminuição de erros, utilizando por exemplo six-sigma são imensas.

Ao ler o livro Lean Office, que é um dos poucos sobre Lean para Serviços, percebi que na verdade existe uma Lacuna gigantesca neste tema. A Engenharia de Produção domina perfeitamente os conceitos de administração de fluxo, conceitos sobre processos, enquanto áreas originalmente de serviços estão tateando para começar a entender sobre o assunto.

A Engenharia de Software por exemplo, ao tratar de Processos, como no CMMI, não faz idéia sobre o que significa otimização, em seu nível 5.

As referência bibliográficas utilizadas no CMMI são baseadas na década de 90 e antes. Eles descobriram Deming mas ainda usam Ford e Taylor, enquanto na Engenharia de Produção já se estuda Sistemas que Aprendem, Chaordics, e muito mais.

A distância entre a Engenharia de Software e a Engenharia de Produção pode ser medida diante das datas das referência bibliográficas sobre processo utilizadas nas últimas publicações.

FATO: ao identificar informações sobre processos e gerenciamento de processos da engenharia de software estará identificando referências ingênuas, ultrapassadas e que já tiveram sua contribuição em outra realidade que não a nossa.

CMM e CMMI não são antigos, mas pecam ao não perceberem o mundo que existe por traz do gerenciamento de processos, que não se limita a Taylor, Fordismo, e às primeiras contribuições de Deming.

Por volta de 2004 a SEI começou, timidamente a avaliar Six-Sigma, que tem muito a contribuir, mas parece não ser ainda considerada por eles uma ferramenta padrão para seu processo.

Acredito sinceramente em six-sigma e em controle estatístico de processos, porém entendo que o conjunto da obra do Sistema Toyota de Produção e o Pensamento Enxuto é muito, mas muito mais apropriado para lidar com desenvolvimento de software.

Não se trata de eliminar a variabilidade do processo, mas sim de ser reativo a variação.

Na indústria, variações como anormalidades devem ser suprimidas.
Na Engenharia de Software ainda não se percebeu que o mundo está mudando rapidamente, e que esta mudança é adaptativa. Empresas precisam se adaptar rapidamente. Fechar o escopo neste contexto, ou eliminar este tipo de variação não é o que a indústria precisa.

Existe uma diferença GRANDE entre eliminar o desvio do erro, de eliminar a variabilidade decorrente da demanda. Se a demanda for verdadeira deve haver resposta ágil do sistema.

Penso.

Variabilidade X Anormalidade

Muito tem sido dito sobre diminuição da variação no processo de desenvolvimento de software.

Infelizmente existe uma confusão de terminologia que não deve ser aceitar/mantider, sob pena de estarmos nos direcionando novamente no paradigma Fordista e ainda atual da Engenharia de Software.

Quando Ford produzia seus carros em 1904, a demanda era muito superior a sua produção, os mercados eram ávidos por seus produtos, portanto, segundo Ford: Henry Ford: "O carro é disponível em qualquer cor, contanto que seja preto..".

Isso se chama variabilidade na indústria.

Outro fenômeno paralelo é que, desde a manufatura artesanal, ocorria que as peças apresentavam imprecisões, por baixa padronização ou por erro de produção, que são consideradas anormalidades da produção.

Tais anormalidades são medidas, e em controle estatístico de processos, são identificadas como variações de medida dentro do processo.

Diz-se, matematicamente, que o desvio entre o esperado e o obtido é uma variação.
Existe ainda a propriedade estatística que define que a soma dos desvios será sempre zero.
Portanto para descobrirmos um desvio médio (erro médio) não se pode tirar a média dos desvios (erros), faz-se a média dos desvios quadrados, a que chamamos variância.

O desvio padrão, ou média dos desvios, é a raiz quadrada da variância.

Busca-se matematicamente diminuir esta variação com o objetivo de eliminar as anormalidades ou erros do processo.

Entretanto, não se busca diminuir a variação, porque a variação é inerente a demanda.
Variação significa evolução, de conceitos, de valores, da sociedade e da indústria.

Busca-se eliminar os erros e seu desvio do objetivo inicial.

Vários autores em desenvolvimento de software pregam eliminar a variação, o que é incorreto.

Devemos sim trazer o processo para a eliminação de erros, e para uma estabilidade tal que possamos conhecer e estimar o desempenho, qualidade e capacidade do processo.

É interessante dizer que existem técnicas de controle estatístico de processos que existem com esta finalidade, entretanto existem outras técnicas como o Six Sigma, que buscam otimizar processos sob a ótica do controle estatístico.

Entretanto, existe um perigo intrínseco e antigo em otimizações.

Ford, na década de 20, atingiu através da padronização das peças que utilizava o auge da velocidade de produção, quando tem início de fato a era da "Produção em Massa". O sistema então chamado Fordista, consegue diminuir drasticamente os erros e tempos de produção.

Ford atingiu o que na Toyota se chama de fluxo de produção, com a diferença que Ford levava as máquinas e pessoas ao estresse extremo, tirando a última gota de sua capacidade de produção.

A velocidade que a Toyota propõe é na verdade baseada na eliminação de desperdícios, esperas, operações ineficientes e desnecessárias. Entretanto, mesmo as paradas totais da fábrica são apoiadas e necessárias, com vistas ao trabalho consciente e a melhoria da qualidade do trabalho.

Outra dúvida/erro muito comum é achar que na Toyota tudo tem que ser feito rápido, isso é uma afirmativa errada. Não pode haver demoras e esperas, isso sim. Mas os funcionários devem poder realizar o trabalho em um rítmo sustentável e calmo para poder observar e pensar sobre o que estão fazendo, e sobre como podem mudar para atingir a resultados melhores.

Entretanto, na Ford a otimização unicamente do desempenho estava direcionada para a produção de estoques. Com este objetivo, unicamente velocidade, pode-se monitorar as estatísticas e produzir mais rápido, gerando estoques cada vez maiores e mais cheios.

De forma semelhante, o desenvolvimento de software pode ser acelerado usando técnicas estatísticas, mas será este um caminho para o processo ideal?

Por este mesmo motivo, atualmente é difícil encontrar casos de processos otimizados unicamente por SixSigma. Na verdade utiliza-se mais de uma forma de otimização associadas, como por exemplo Lean + SixSigma, ou Lean + TOC.

O Lean ( ou Pensamento Enxuto) possibilita mudar qualitativamente o processo, dando rítimo sustentável para o processo de trabalho, o que significa LEVE ou LIVRE de esperas, demoras, e outras formas de desperdício, e somente por isso mais rápido, como consequência.

A Engenharia de Software, na busca de um processo Otimizado, no CMMI em seu nível mais alto, já ouviu falar do SixSigma, e recentemente começou a ouvir falar de Lean.

Talvez, daqui a pouco tempo estejamos percebendo a Engenharia de Software se livrar dos paradígmas de processo Fordistas e da Produção em Massa.

Planejamento para Desenvolvimento de Software

Ocorre que diante de um projeto para desenvolver software, gerentes ou responsáveis se esforçam para estimar precisamente tarefas, tempos e recursos necessários para a produção do bem.

A produção do software visa gerar um bem que será entregue ao final do projeto para o cliente.

A produção de serviços é, necessariamente, uma operação na qual o cliente é agente dentro do processo, pois serviços são de consumo imediato, não se pode estoca-los ou entrega-los à posterior.

O desenvolvimento ágil, no qual se aluga a força de trabalho para o cliente, é uma prestação de serviço com bens associados. A equipe fica alocada ao cliente durante o tempo necessário à prestação do serviço. O cliente participa do trabalho, recebendo os benefícios como o aprendizado, sua garantia de qualidade pela certeza da adequação do produto e o bem produzido.

Explicar o planejamento para um prédio costuma ser o exemplo utilizado para se explicar o porque se faz planejamento exaustivo e adiantado para o desenvolvimento de software.

Entretanto, o desenvolvimento de software, em função de ser um serviço exploratório, que envolve a descoberta de conhecimentos tácitos, entrevista com os especialistas, possibilidade de atualização on-the-fly destes mesmos conhecimentos, sugere a utilização de métodos ainda mais poderosos de planejamento, do que o planejamento estático, feito no início do processo de desenvolvimento, sem conhecimento suficiente e prevendo um intervalo de tempo normalmente muito grande.

O planejamento ágil é feito de forma incremental, prevendo escopo e horizontes de tempo de cada iteração, portanto muito menores e com probabilidade de acerto muito maior.

O risco ao longo deste processo fica diluido pelo escopo simplificado e prazo menores, sendo a probabilidade de sinistros também menor.

Qual é o planejamento mais seguro?
Qual o planejamento mais preciso?

Numéricamente o planejamento incremental é mais eficiente.
A dúvida deveria ser se esta forma de planejamento é viável para o processo de desenvolvimento de software, entretanto as críticas ou a auxência delas, segue no espaço do desconhecimento e desconsideração de sua existência e forma.

Segundo Jeff Patton (2008), conhecer o problema mas não saber desde o início o que se quer, é comum, é normal, é o suficiente.

Eu humildimente complementaria que é inclusive melhor sob o ponto de vista de obter algo de qualidade.

Workshop ScrumBan com Alisson Vale

Caros Colegas,

Neste final de ano participei de um encontro muito bom onde discutimos sobre a técnica de Kanban para otimização do processo de Desenvolvimento de Software.
O workshop ScrumBan foi organizado e ministrado pelo professor Rodrigo de Toledo (Tecgraf PUC-Rio, atualmente Prof. UFRJ) e por Alisson Vale, ganhador do premio de Excelência em Engenharia de Software Enxuto.
A qualidade deste workshop e dos participantes foi fantástica.
Foram abordadas as diferenças entre as técnicas XP, Scrum e Kanban, esclarecendo os conceitos de Lean que podem auxiliar no desenvolvimento de software, dando enfase no Kanban segundo Alisson Vale e David Anderson.
Comentarei melhor sobre o evento ainda esta semana.
A página do evento foi http://scrumban.com.br

Palestra sobre XP (Programação Extrema) e Framework Ágil - TDC 2008

Este vídeo é uma aula sobre o assunto.
Infelizmente já conversei com amigos não tiveram paciência para assistir até o final, mas realmente é *muito boa*.
É importante observar que esta palestra foi planejada pensando em uma audiência em que poucas pessoas realmente conheciam métodos ágeis. Notadamente ao se discutir o assunto, ainda hoje é novidade e ainda existem muitos mal entendidos, mesmo entre os praticantes.
Gosto desta palestra principalmente porque nela existem explicações muito boas, e exemplos práticos.
Recomendo para praticantes e mais ainda como introdução.
Obrigado ao Mestre (UFRJ) Vinícius Manhães Teles.



Fonte:

Viddler - Extreme Programming na TDC 2008


Palestrante:
MSc. Vinícius Teles

Análise de Requisitos para não desenvolvedores

Aconteceu hoje a primeira aula sobre Análise de Requisitos de Sistemas, na Pós-Graduação em Produção e Sistemas do IFF, ministrada pelo Prof. Dr. Rogerio Atem de Carvalho.

O objetivo desta disciplina é dar ao pós-graduando noções sobre requisitos de software. Cabe esclarecer que o curso não é exclusivo para profissionais de informática, pelo contrário, seu corpo discente é bem diversificado, contendo engenheiros, administradores, etc.

Existe uma dificuldade natural de comunicação entre quem conhece desenvolvimento de software e quem precisa de software. É muito comum que pessoas que precisam de software não saibam bem como o software deva se comportar. Isso é natural. Esta disciplina vem auxiliar neste ponto. Pretende-se capacitar o pós-graduando de Produção e Sistemas a entender, participar e interferir no processo de elicitação dos requisitos. Para tanto, deve-se familiariza-los com um mínimo das linguagens e técnicas de modelagem. Foi discutida, além da abordagem tradicional, uma visão ágil de requisitos e contratos.

É interessante observar que por trás de quase tudo nos frameworks ágeis pode-se encontrar fundamentos do Lean. Tais princípios são muito importantes para a compreensão do contexto de sua aplicação sob a ótica das empresas.

Apesar de parecer, para outros leitores, um óbvio ululante, é preciso ser dito que um software será utilizado com um objetivo (razão de existência), e provavelmente estará integrado dentro do processo produtivo de uma empresa, senão será mais um caso de fracasso.

Neste caso, o software precisa agregar valor à empresa (cliente), sob pena de ser um monte de bits e bytes, bonitinhos somente para quem o construiu. Houve época em que construía-se software usando técnica "A", ou "B", linguagem "C" ou "D", porque estava na moda ou porque se achava bonito. Para tal software o melhor lugar é um quadro na parede.

O Desenvolvimento enxuto propõe princípios para que o software agregue valor ao cliente, seja produzido com qualidade, na hora e momentos certos, alinhado com os interesses e a dinâmica de quem precisa do software. Vale ressaltar: a utilização de técnicas quaisquer sem bom senso, adequação, pode levar ao fracasso.

Foi discutida também "a Regra da Privada". Esta regra foi criada pelo Prof. Rogerio Atem com objetivo didático de discutir sobre o momento certo (mais oportuno/adequado) para mudança de requisitos. Segundo esta regra a mudança de um vaso sanitário de lugar tem um custo baixo enquanto ainda estiver na planta da engenharia civil, porém é muito mais cara após a instalação e o acabamento terminados. Assim também é o software desenvolvido sob o modelo cascata.

Neste ponto entra em discussão o modelo cascata de software, onde a iteração demora a acontecer, e o modelo ágil/lean que propõem iterações rápidas e contato mais próximo ao usuário. No modelo ágil de desenvolvimento as iterações são pequenas e freqüentes, tornando mais prática e tranqüila a identificação e alteração destes problemas.

Continuando neste exemplo, poderíamos imaginar que todos os proprietários de um prédio (stakeholders) pudessem fazer uma visita virtual ao prédio e discutir mudanças antes do construção e acabamento do prédio (produto).

Neste novo modelo, o objetivo é agregar valor ao usuário, portanto é necessário as iterações mais freqüentes para se poder realizar mudanças de escopo.

O escopo precisa ser aberto sob pena de algum dos fatores que alteram constantemente tal escopo tornem o software menos importante do que se desejava inicialmente.
- O escopo pode ser alterado ao se descobrir uma forma mais eficiente, rápida, barata, correta de se fazer algo.
- A legislação pode mudar e obrigar mudanças no escopo.
- A concorrência, os clientes ou mesmo os fornecedores podem obrigar mudanças no escopo.
- O aprendizado do cliente pode suscitar novo pensamento sobre o que foi solicitado inicialmente, e a partir daí surgirem novas regras, novas prioridades, novas soluções, novos requisitos, etc.

Quem trabalha ou já trabalhou sabe como é importante sempre melhorar sua maneira de trabalhar. Possibilidades de melhoria sempre aparecem. Portanto, o escopo do software não pode ser engessado, sob pena de se produzir algo sabendo-se que não é tão eficiente quanto o possível.

O escopo aberto é uma abordagem mais adequada ao aprendizado do cliente e da equipe de desenvolvimento.

Livros

Lean Software Development: An Agile Toolkit
By Mary Poppendieck, Tom Poppendieck

Implementing Lean Software Development From Concept to Cash
by Mary Poppendieck; Tom Poppendieck

Agile Estimating and Planning
by Mike Cohn

Agile Project Management with Scrum
by Ken Schwaber

User Stories Applied: For Agile Software Development
by Mike Cohn

Agile Project Management with Scrum
by Ken Schwaber

User Stories Applied: For Agile Software Development
by Mike Cohn

Agile Estimating and Planning
by Mike Cohn

Agile Testing: A Practical Guide for Testers and Agile Teams
by Lisa Crispin; Janet Gregory

The Art of Agile Development, 1st Edition
by James Shore; Shane Warden